Subject: Re: [Webpush] Message update PR

From: Brian Raymor <[email-masked]>
Date: Sat, 9 Jan 2016 01:10:56 +0000

Is there any further feedback for Martin's pull request below?

Thanks,
...Brian

-----Original Message-----
From: Webpush [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Thursday, November 12, 2015 1:00 PM
To: [email-masked]
Subject: [Webpush] Message update PR

https://github.com/webpush-wg/webpush-protocol/pull/62

The above pull request and commit is the substance of what we
discussed in Yokohama regarding push message updates.  This proposes a
new header field, Topic, which can be added to a push message.

This doesn't really replace messages in the same way that the last one
does.  Instead, it causes the old message to be acknowledged/deleted
at the same time that the new message is created.  This avoids all the
nasty race conditions we discussed at the meeting.  If the old message
is being delivered, then this causes it to be acknowledged early;
since acknowledgment is idempotent, there are no race conditions.

--Martin

_______________________________________________
Webpush mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webpush

---

From: Costin Manolache <[email-masked]>
Date: Mon, 11 Jan 2016 17:00:42 +0000

- +1 in general

- Doubts about the name "Topic" - many pubsub users will be confused, it is
not really a topic,
just a key

-  We may relax the '4 collapse keys' limit for GCM, shouldn't be a problem
for webpush.

Can we change a bit the wording to allow some optimizations we do: a
message with topic (collapse
key) may be optimized for 'sync usage' - i.e. even if the device is online,
if push service detects
frequent messages in a topic (for example user receives lots of email) it
may delay and collapse
messages. I.e. not only " If the user agent is offline".

Also I would prefer (for implementation purpose) a simpler ID syntax
instead of quoted string.
It's going to be a database key, short an unambiguous seems better. URI
path component would
be nice.

Finally, a more generic approach would be to allow the sender to specify a
MessageID - than
multiple messages with the same ID could override each other ( identical
with topic ), but the main
benefit is that senders will avoid a lookup and mapping push-service IDs to
their internal IDs in
acks. Push service can internally combine the subscription ID with the
sender-provided message ID.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jan 2016 10:57:21 +1100

> - Doubts about the name "Topic" - many pubsub users will be confused, it is

I'm happy to take suggestions on the name, it's just a name :)

>From my perspective however, the pubsub use fits almost perfectly with
this use, so I think that the name is a bit of an advantage.

> -  We may relax the '4 collapse keys' limit for GCM, shouldn't be a problem

That would be awesome (I hear that collapse keys are very heavily used
by some big sites, I wonder if you aren't already feeling the pressure
there).

> Can we change a bit the wording to allow some optimizations we do: a message
> with topic (collapse

That should always be possible.  If the text implies otherwise, then
we should correct that.

> Also I would prefer (for implementation purpose) a simpler ID syntax instead
> of quoted string.
> It's going to be a database key, short an unambiguous seems better. URI path
> component would
> be nice.

Would the base64(url) alphabet suit you well enough?  I didn't add
that restriction.

What about a length restriction?  I think that Ben and I discussed
just rejecting push messages with ridiculously long topic names.

> sender-provided message ID.

Maybe I'm not understanding you here, but isn't that exactly what this
change does?

---

From: Costin Manolache <[email-masked]>
Date: Mon, 11 Jan 2016 17:04:31 -0800

> I'm happy to take suggestions on the name, it's just a name :)

'collapse_key' is what is used in GCM, I think having 'collapse' or
'override' or
'replace' or 'update' in the name would describe what happens.

> this use, so I think that the name is a bit of an advantage.

I don't think it fits so well.
If you publish 3 messages on a pubsub topic, you expect subscribers to get
3 messages,
not to have them all collapsed. And the topic is mapped to a list of
receivers, etc.

I know broadcast is not in scope for this release - but if/when we add it,
it will make things
more confusing with topic.

> by some big sites, I wonder if you aren't already feeling the pressure

The intent of having just 4 keys was to encourage senders to use 'collapse'
just for sync,
and not attempt too much granularity. You tell the device to sync, with
some info (10 mails and 7 spams),
this gets updated while device is offline - and results in one sync that
fetches everything.

A single collapse key may have been better, to avoid confusion :-). At that
time it was not yet
clear how well things will work, and sync was the main use case. Most
senders with collapse
seem to be using a single key.

> instead
> path
Agreed, base64(url) with a reasonable size is good.

A 64-bit long or UUID would be great too. AFAIK most collapse keys are 2..4
letters ( mail, cl,
all, sync ...)

> Maybe I'm not understanding you here, but isn't that exactly what this

Not sure :-)

Current patch requires the messages to include the topic header, and it
still
generates 3 message IDs ( "creates a new push message resource")

Alternative would be to just allow updating the original resource, if it was
not sent.

BTW - there is one important change in the patch, allowing push senders to
DELETE
the resource. Allowing update would be consistent with that.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 15:32:49 +1100

Sorry about the much-belated response.  I'm updating the PR with a
length restriction.  Still not sure about the

> more confusing with topic.

Hmm, that may be right.  But a short name that isn't already taken is
hard to find.  Collapse-Key is highly application-specific and I know
that HTTP have a problem with single-purpose header fields.  I was
tempted to suggest "Subject" actually as being similar, but not the
same.

> Agreed, base64(url) with a reasonable size is good.

UUID runs to quite a few characters, so how about 32 characters from
the base64 URL-safe alphabet.  I'll put that in the PR.

> generates 3 message IDs ( "creates a new push message resource")

Yes, you are right.  Though I think that you only need a single message ID here.

> Alternative would be to just allow updating the original resource, if it was

Yes, but that requires knowing the identity of the original resource,
something that requires additional state at the application server.
The discussion at the last meeting revealed that many application
servers don't like this as it imposes restrictions on how they operate
and a bunch of extra state.

> the resource. Allowing update would be consistent with that.

Yes, DELETE is very useful, though it does require some state.  This
isn't really new though.

Note that you can also push with the same topic and a very short TTL
to in-effect reduce the TTL of an existing message.  I struggled to
explain that clearly in the PR as Brian will tell you, but it's an
option for those who don't like maintaining the extra state.