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

From: Brian Raymor <[email-masked]>
Date: Fri, 19 Feb 2016 20:26:12 +0000

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

---

From: Costin Manolache <[email-masked]>
Date: Fri, 19 Feb 2016 14:22:41 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Feb 2016 16:53:25 -0700

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

---

From: Brian Raymor <[email-masked]>
Date: Sat, 20 Feb 2016 00:04:07 +0000

On Fri, Feb 19, 2016 at 2:23 PM, Costin Manolache < [email-masked] > wrote:

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

Correct. That section is unchanged.

---

From: Brian Raymor <[email-masked]>
Date: Sat, 20 Feb 2016 00:52:28 +0000

On Fri, Feb 19, 2016 at 3:53 PM, Martin Thomson < [email-masked] > wrote:

> The question is: what would the :receipt link identify? 
<big snip>

Beyond reducing moving parts, there is really no substantial behavioral difference from the current :push:receipt design. But it's been a long week and I may be missing the obvious.

The PS has the same amount of information when returning a :push:receipt as before, since it has the ability to maintain the relationships (implicit or explicit) between an individual subscription and/or a subscription set, and its corresponding :push resource. It could return the appropriate :push:receipt for all responses related to a specific :push resource.

That's why we've always had language to provide a way for the AS to discern between receipts associated with different messages:

   Each receipt is pushed as the response to a synthesized GET request
   sent in a PUSH_PROMISE.  This GET request is made to the same push
   message resource that was created by the push service when the
   application server requested message delivery.  

Or are you proposing a new feature and I've missed the point?

...Brian

---

From: Costin Manolache <[email-masked]>
Date: Sat, 20 Feb 2016 02:41:18 +0000

Let me try to describe the problem:
1. AS1 sends 100 push messages
2. AS2 sends another 100 push messages
3. PS returns 100 push receipt URLs for each.

The question is contained in the receipt URL. The PS has no way to know
which message is
from AS1 and which is from AS2 - all sent messages look the same. So it
must return 200
distinct push receipts.

If a PS requires sender authentication - it's pretty easy, PS knows public
key of AS1 and AS2, and
it returns only 2 URLs, one for AS1 and one for AS2, than 2 GET requests
are made and AS1
and AS2 each get their 100 receipts. So in GCM case - everything looks
great.

If a PS doesn't require authentication - you need some other way to know
that messages are sent from
AS1 or AS2. This is similar with the subscription set on the UA side -
where the UA starts by creating
a subscription set, and than each subscription is associated with the set.
We could be symmetrical, and just
let AS create a 'subscription set' for itself, and have each send include
the set. This would act like the
public key - but have shorter life and be more private.

Costin

On Sat, Feb 20, 2016 at 12:52 AM, Brian Raymor <[email-masked]>
wrote:

> On Fri, Feb 19, 2016 at 3:53 PM, Martin Thomson < [email-masked]
> > wrote:
>
> Beyond reducing moving parts, there is really no substantial behavioral
> difference from the current :push:receipt design. But it's been a long week
> and I may be missing the obvious.
>
> The PS has the same amount of information when returning a :push:receipt
> as before, since it has the ability to maintain the relationships (implicit
> or explicit) between an individual subscription and/or a subscription set,
> and its corresponding :push resource. It could return the appropriate
> :push:receipt for all responses related to a specific :push resource.
>
> That's why we've always had language to provide a way for the AS to
> discern between receipts associated with different messages:
>

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Feb 2016 12:03:37 -0800

On 19 February 2016 at 12:26, Brian Raymor <[email-masked]> wrote:
> A more natural flow could use 202 (Accepted) with the :push:receipt as the "status monitor".

I realize that I forgot one of the original reasons for the existing
design.  A design like you propose was considered, but not adopted
because it creates a race condition.  The acknowledgment races the
request that the application server makes to the receipt resource.

However, if your assertion is that TTL:0 messages will not be
acknowledged, and that all other messages require that the push
service persist the acknowledgments as well as the messages
themselves, I think that this is probably OK.  TTL:1 and maybe other
small values are probably a little risky, but a simple caveat might
suffice.