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

[Kit Cambridge <[e-mail]>]

Hi all,

First, I'd like to echo Peter's "thank you". I'm very grateful for all your work in putting this standard together and marshaling feedback, here and on GitHub! In addition to the comments from Peter, JR, and Hervé, I have a few questions and suggestions. None of them block the WGLC.

In section 4.1, I'm not clear what "unable to receive push messages that are aggregated for the lifetime of the subscription" means. If the UA is forwarding requests, could it still disaggregate messages sent to a subscription set before delivering them to the other clients?

In section 5.1...

* It might help to include the `Link: </r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>; rel="urn:ietf:params:push:receipt"` header in the `POST` example. The prose suggests a symmetry with subscription sets, but I was confused how the app server specifies the receipt subscription URL on the first reading.
* I agree with Peter that clarifying whether receipts are sent for TTL=0 messages would be nice.
* Does it make sense for the push server to use a 400-class status code in a receipt to report a nack? For example, if the UA failed to decrypt the message, or the app threw an exception. IIUC, the spec allows 204 for successful deliveries and 410 for expired messages, but it's not clear if the PS can send other statuses in receipts.

* I'm also curious to hear implementer feedback about receipts in general.

In section 5.4...

* Could we restrict the `Topic` grammar to just `token`? ISTM base64url already fits this definition.
* If the replaced and new message specify TTLs, and the new TTL is shorter...does it just replace the old TTL? (This is implied by "the information that is stored for the push message is updated", as well as the restriction that the response TTL must be <= request TTL, but I wanted to double-check).

In section 6, are non-zero `wait` values allowed? (I'm assuming not, since the UA can disconnect at any time).

In section 6.2...

* Is there a way for the push server to indicate to the UA how long it's willing to wait for acks before re-delivering? (For instance, so that the UA can batch acks for a burst of incoming messages. Or does this not make sense with H2?)
* Can a UA "nack" a message, or would this be implementation-specific? (Related to my note above about reporting nacks to the AS in the receipt subscription).

In section 7.2, could we consider allowing push servers to reject messages < 4k? If the PS is proxying the message to a third-party server, which Mozilla's server does on iOS and Android, it might not be able to control the size limit.

In section 7.3.1, if the UA deletes a subscription that belongs to a subscription set, does it receive a 410 for the deleted subscription on the subscription set stream?

Cheers,
- kit