Re: [Webpush] Non-blocking comments on -05

[RUELLAN Herve <[e-mail]>]

Hello everyone,

I also have some comments on the spec, none of which are blocking for the WGLC.

I also generated a pull-request for editorial things:
https://github.com/webpush-wg/webpush-protocol/pull/93

And another one for changing the URIs used in the examples and making them more explicit (which I think is helpful for a first-time reader of the spec):
https://github.com/webpush-wg/webpush-protocol/pull/94


1. Some of the URNs used may be confusing. Renaming them could help make things clearer.

The push message subscription set URN, "urn:ietf:params:push:set", could be changed to "urn:ietf:params:push:sub:set", to better show it is related to push message subscription resources and not directly to push resources.

The receipt subscription URN, "urn:ietf:params:push:receipt", could be changed to "urn:ietf:param:push:receipt:sub", to better show it corresponds to a receipt *subscription* resource and not to a receipt resource (even if these don't exist).


2. What does a push server that receives a request for a push message with "Prefer: respond-async" but doesn't want to provide a receipt subscription, or doesn't support providing receipts? Is this allowed in the first place?


3. Adds in 5.1 a paragraph similar to the third one of 4.1 (containing some modifications from my editorial pull-request):

An application server MAY omit the receipt subscription if it is unable to receive receipts in an aggregated way for the lifetime of the push messages. This might be necessary if the application server is forwarding push messages from other servers.


4. In 5.4, replace:

A 201 (Created) response indicates...

with:

A 201 (Created) response or a 202 (Accepted) response indicates...


5. In 6, in the last paragraph (and similarly in 6.1), replace:

A 204 (No Content) status code with no associated server pushes...

with:

A 204 (No Content) status code sent in response to the initial request with no associated server pushes...


6. In 6.1, maybe emphasize the difference on the location of the link header (PUSH_PROMISE vs response) and give some reason for this difference.


7. In 6.3, what is the status code for a message not successfully delivered at its expiration time?


8. The draft is not clear on how GET to subscription resources (or subscription set) are handled. It is stated that the push service does not respond to this request. However the last paragraph of 6 tells about using a 204 (No Content) status code when no messages are available, and this is stated again by paragraph 4 of 7.2. Is it only for the case when "Prefer: wait=0" header field is used? Or can the push server use it to close the connection?


9. In 7.5, add a paragraph for the client proxying scenario:

It should be noted that some user agent might need to use several subscription sets if they are forwarding subscription requests from other servers.



Thanks for all the work on the spec,

Hervé