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

[Brian Raymor <[e-mail]>]

On Thursday, June 2, 2016 12:02 AM, Kit Cambridge <[e-mail]> wrote:

> 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.

To be clear, you're requesting a new example for subsequent POSTS that pass the push:receipt which would be similar to the example for subscription sets in section 4.1.1?

Something like:

For subsequent receipt requests to the same origin [RFC6454], the
application server SHOULD include the returned receipt subscription
in a link relation of type "urn:ietf:params:push:receipt". This
gives the push service an option to aggregate the receipts.

POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
Prefer: respond-async
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB


The push service SHOULD return the same receipt subscription in its response,
although it MAY return a new receipt subscription if it is unable to
reuse the one provided by the application server.

HTTP/1.1 202 Accepted
Date: Thu, 11 Dec 2014 24:56:55 GMT
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
rel="urn:ietf:params:push:receipt"
Location: https://push.example.net/message/xDIYHNcfAIPP_5ITvURr-d6BGt


> * I agree with Peter that clarifying whether receipts are sent for TTL=0 messages would be nice.

See the discussion in https://github.com/webpush-wg/webpush-protocol/pull/91

We've iterated on zero TTL quite a bit. Do you have any suggestions on how to further clarify:

A Push message with a zero TTL is immediately delivered if the user
agent is available to receive the message. After delivery, the push
service is permitted to immediately remove a push message with a zero
TTL. This might occur before the user agent acknowledges receipt of
the message by performing a HTTP DELETE on the push message resource.
Consequently, an application server cannot rely on receiving
acknowledgement receipts for zero TTL push messages.