Re: [Webpush] 202 (Accepted) and simplifying acknowledgements

[Martin Thomson <[e-mail]>]

On 19 February 2016 at 13:26, Brian Raymor <[e-mail]> wrote:
> 4. The PS returns a 202 (Accepted) on success for the message delivery request from the AS. It also includes a Location and :push:receipt as the "status monitor" suggested for a 202.


I think that:

a) this change in design is generally good, but I have one question
and maybe a suggestion
b) we should use 201 still, since a resource is created (even if it is
purely ephemeral, as it is in the case of TTL: 0)


The question is: what would the :receipt link identify?  This is a
resource that the application server would monitor for receipts.  But
that has the same problem we had with subscriptions that led to the
creation of subscription sets, namely that the application server has
to make a request for every push message it wants to track.

Is that your intention?  Because if it is, that's a lot of GET
requests, which could lead to scaling issues.  I have a suggestion.

If this were to act like a subscription *set* rather than a
subscription (see Costin's question), I think that this would be
better.  The only question then is how an application server causes
its receipts to be correlated.  The obvious answer is to create the
subscription set in an initial request and use the inclusion of the
link relation in the push message request as an indication that the
application server wants to link receipts to an existing subscription.

A less good, but probably OK possibility is to hook into the voluntary
identification and have application servers get a subscription set
based on their offered identity.