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

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 <Brian.Raymor@microsoft.com>
wrote:

> On Fri, Feb 19, 2016 at 3:53 PM, Martin Thomson < martin.thomson@gmail.com
> > 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
>
>
>
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>