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

[RUELLAN Herve <[e-mail]>]

On Wed, 2016-06-01 at 23:34 +0000, Brian Raymor wrote:
> 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?
> 
> The push service is required to support receipt subscriptions. 
> 
>    The push service MUST also provide a URI for the receipt 
>     subscription resource in a link relation of type 
>   "urn:ietf:params:push:receipt". 
> 

This sentence could be interpreted either as making support for receipt
subscriptions mandatory or as being a mandatory part of the 202
(Accepted) response, implying that the push service can also respond
with a 201 (Created) even when the Prefer header field is present.

On Thu, 2016-06-02 at 12:13 +1000, Martin Thomson wrote:
> On 1 June 2016 at 21:46, RUELLAN Herve <[e-mail]> wrote:
> > 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?
> 
> This is handled in RFC7240.  It ignores the Prefer header.  I believe
> that existing implementations do this very well :)

As two authors of the spec have divergent opinions, I think that a clear
statement would be helpful ;-).
I've created a pull request stating that support for push receipts is
not mandatory, but I've not strong opinion on the subject.

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

Hervé