[Webpush] 202 (Accepted) and simplifying acknowledgements

[Brian Raymor <[e-mail]>]

I've thought a bit more about the 202 discussion with Ben, Costin, and Martin. I have a small proposal that I've run past Martin and Elio for a sanity check. 

Currently - when an application server requests push message delivery, there are separate flows for message creation and message delivery:

1. Message Creation - The push service returns a 201 (Created) returned by the POST with a Location resource
2. Subsequent notification of delivery success or failure using Receipt Acknowledgements.

Receipt Acknowledgements also has many moving parts:

1. The PS returns :push and :push:receipts to the UA during its message subscription process.
2. The UA distributes :push and :push:receipts to its AS.
3. The AS requests a receipts subscription (:push:receipt) from the PS using :push:receipts.
4. The AS requests message delivery from the PS using :push and includes :push:receipt.
5. The PS returns a 201 (Created) on success for the message delivery request from the AS. It also includes a Location.
6. The AS monitors :push:receipt for success (acknowledgements) or failure (expiration or delivery attempts ceased).

A more natural flow could use 202 (Accepted) with the :push:receipt as the "status monitor". As Costin noted:

> This is pretty much what webpush is doing - accepts the request, and some other 
> process ( the connection side ) may deliver it later :-)

1. The PS returns :push to the UA during its message subscription process.
2. The UA distributes :push to its AS.
3. The AS requests message delivery from the PS using :push.
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.
5. The AS monitors :push:receipt for success (acknowledgements) or failure (expiration or delivery attempts ceased).

This eliminates the need for the :push:receipts link relation and its "machinery" and simplifies the flow a bit. 

Another difference is that the current design allows the AS to request acknowledgements by including :push:receipt with its message delivery request to the PS.  If we want to maintain this optional behavior, then we would need a header - perhaps reusing Prefer: respond-async as a hint - http://tools.ietf.org/html/rfc7240#section-4.1 - that would be included when the AS requests message delivery.

If a pull request would offer more clarity, please let me know.

Thoughts?

...Brian