Re: [Webpush] Delivery receipt may be sent before AS request delivery

[Idel Pivnitskiy <[e-mail]>]

I implemented the design which describes as "Before" in this presentation
[1] last year. And I agree that interaction of UA in this process
is inconvenient. It should be something like this [2], but instead of using
token-URI like /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ, introduce
something more simple, like:

POST /subscribe-for-receipt HTTP/1.1
Host: push.example.net

Benefits:

   1. subscription may be created and receiving Push Message Receipts may
   be requested before sending a new push message => no delivery receipts will
   be lost;
   2. no need to send a push message to get receipt subscription resource;
   3. easy receipt subscription management and receiving receipts (AS may
   have a separate thread or service for this purpose);
   4. simplifying registration of a new push message on PS side: just one
   new object will be created (a push message), no need to think about
   management of receipt subscriptions (what it needs to do? return the same
   receipt subscription or a new one).

Even if the 1st issue is not a big deal, because we may increase TTL value,
the 4th will simplify a PS and the 3rd will be more appropriate for an AS.

I'm also a little bit confused, when reading the draft and see the same
sentence, but with different status codes:

   - Section 5: A 201 (Created) response indicates that the push message
   was accepted.
   - Section 5.1: A 202 (Accepted) response indicates that the push message
   was accepted.
   - Section 5.4: A 201 (Created) response indicates that the push message
   replacement was accepted.

What will be for replacing Push Message with requesting delivery receipt:
"A 202 (Accepted) response indicates that the push message replacement was
accepted"?

Another advantage: just one status code will be returned when AS requests
Push Message delivery.

[1] https://www.ietf.org/proceedings/95/slides/slides-95-webpush-1.pdf
[2] https://tools.ietf.org/html/draft-ietf-webpush-protocol-04#section-5

Best regards,
Idel Pivnitskiy
--
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>

On Thu, Jun 9, 2016 at 4:06 AM, Martin Thomson <[e-mail]>
wrote:

> For context:
>
> > Here may be a problem with push messages with a little value of TTL.
> Message may be sent to a UA and ack may be received from the UA before the
> AS will send a HTTP GET request to the receipt subscription resource. PS
> will retry delivering of receipt, but TTL may expire before this.
> >
> > To eliminate this problem it would be better to introduce separate
> resource for an AS: something like /subscribe for a UA, where AS may create
> a receipt subscription.
>
> We originally had the design you describe, but @brianraymor proposed a
> simpler design that accomplishes the same goals, providing that you
> recognize that a TTL shorter than the time it takes to poll the
> receipt subscription resource can result in losing the receipt.
>
> The only good solution to this general problem is to have a longer TTL.
>
> Even if you fix the "bug" you identified, a short TTL can expire
> between the time that the message is delivered to the user agent and
> before the acknowledgment can reach the push service.
>
>
> On 9 June 2016 at 09:07, Idel Pivnitskiy <[e-mail]>
> wrote:
> > Found out a problem with lost of delivery receipts for push messages with
> > little TTL, an issue was created:
> >
> > https://github.com/webpush-wg/webpush-protocol/issues/115
> >
> > Best regards,
> > Idel Pivnitskiy
> > --
> > Twitter: @idelpivnitskiy
> > GitHub: @idelpivnitskiy
> >
> > _______________________________________________
> > Webpush mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/webpush
> >
>