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

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:webpush-bounces@ietf.org] On Behalf Of Idel Pivnitskiy
Sent: Wednesday, June 8, 2016 7:12 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: webpush@ietf.org
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.

[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 <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> 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 <idel.pivnitskiy@gmail.com<mailto:idel.pivnitskiy@gmail.com>> 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
> Webpush@ietf.org<mailto:Webpush@ietf.org>
> https://www.ietf.org/mailman/listinfo/webpush
>