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

[Costin Manolache <[e-mail]>]

Sounds good.

The optional "push:receipt" is very important for everyone, and we should
add some info about the additional
costs of requesting a receipt.

At least in some implementation the push receipts can be more expensive
than the actual messages, and in
most cases the UA will make some http requests to the AS - so the ACK is
redundant.

I assume the rest of the receipt will be the same: AS will connect to the
URL, make a GET and get push promises,
like in the case of UA getting messages ?

Costin

On Fri, Feb 19, 2016 at 12:26 PM, Brian Raymor <[e-mail]>
wrote:

>
> 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
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>