[Webpush] comments on latest draft-thomson-webpush-protocol-00

[Benjamin Bangert <[e-mail]>]

-Sec 3: Subscribing
What should be done if a client has subscribed to as many subscriptions as
a server will allow per authenticated-client?

"The push server MUST provide a URI for the push resource corresponding to
the push message subscription using a link relation of type
"urn:ietf:params:push"."

Can this be the same push resource for a single authenticated client?
Explanation for this in next bit.

-Sec 6: Receiving Push Messages

This section appears to require a GET for every single subscription. If you
have 80 subscriptions, upon connect, you will send 80 GET's. Also, for the
server to maintain all your subscriptions, and optionally subscription
expiration information, can make a significant impact on the per-connection
memory overhead as all this state will need to be maintained on the server
handling all these subscriptions.

Just as the receipt subscription URL is likely to be the same for the
service as a whole, I would propose allowing a Push Service to provide an
authenticated client a single push subscription URL for all subscriptions
for that client (the Location handed to App-Servers would of course vary
for each subscription). The Push Promise path would then need to be the
Location given out, so that the client could determine which subscription
each message is for.

This would allow for a single GET on connect, to begin receiving all
notifications, for all subscriptions the client has setup previously. The
client would need to realize that if it is already monitoring a
subscription for notifications, and subscribes to another that has the same
URL, then it should start expecting those notifications to be associated
with the existing http2 stream.

As this section currently stands, its quite a bit of data to resume
subscription flow on a disconnect, which would be very expensive for mobile
clients.

Having a per-client subscription resource for *all subscriptions* would
allow clients to resume notification flow faster on disconnect, with lower
server resource overhead as the entire flow of notifications can resume on
a reconnect without waiting for all the individual subscription GET's. It
would also help avoid server overloading when large batches of clients come
online/offline at once (1k clients at 80 subscriptions each connecting at
once is a quick 80k hits, etc.).

This change would require 7.3 to be updated, so that expiration of
subscriptions can be communicated in some other manner, and the client
could DELETE them in some other manner.


"A 204 (No Content) status code with no associated server pushes indicates
that no messages are presently available. This could be because push
messages have expired."

This seems to indicate that a response will be returned for a GET to a push
subscription if there are no messages, once a response has been returned
though, no push promise frames for that GET can be sent (as far as I
understand http2 stream semantics at least). If there's no messages for a
push subscription, is the intention that a 204 is sent, or that its kept
open for push promise frames for eventual notifications?

-Sec 6.2: Receiving Push Message Receipts

If an application server has sent substantial quantities of notifications,
all with push receipts, and has failed to take any action to clear its
receipt queue, what should be done to indicate to the App-Server that it
isn't allowed to send any more until it clears out its receipt queue?

It feels like there should be some way to indicate this, as its possible
the App-Server is malfunctioning rather than is being a bad actor.

Cheers,
Ben