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

From: Idel Pivnitskiy <[email-masked]>
Date: Thu, 9 Jun 2016 02:07:01 +0300

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 <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Jun 2016 11:06:38 +1000

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

---

From: Idel Pivnitskiy <[email-masked]>
Date: Thu, 9 Jun 2016 05:12:08 +0300

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

On Thu, Jun 9, 2016 at 4:06 AM, Martin Thomson <[email-masked]>
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.
>

---

From: Brian Raymor <[email-masked]>
Date: Fri, 10 Jun 2016 22:05:40 +0000

We recently reached consensus on the simplified design for receipts as Martin notes below (and as I noted in the issue). I don’t see strong interest in reverting that change.

Part of the complexity you’re seeing is related to our consistent use of hard-to-guess capability URI(s).

Regarding 201 vs 202 – See also - http://www.ietf.org/mail-archive/web/webpush/current/msg00439.html -

Closed https://github.com/webpush-wg/webpush-protocol/issues/115

From: Webpush [mailto:[email-masked]] On Behalf Of Idel Pivnitskiy
Sent: Wednesday, June 8, 2016 7:12 PM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Webpush] Delivery receipt may be sent before AS request delivery

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<http://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.

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 <[email-masked]<mailto:[email-masked]>> wrote:

On 9 June 2016 at 09:07, Idel Pivnitskiy <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>