Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00

From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
Date: Sat, 20 Jun 2015 01:04:48 +0000

On Thursday, Jun 18, 2015, Darshak Thakore <[email-masked]> wrote:

> Section 5.1 - Would be useful to give an example of where/when the Push-Receipt header is sent and what the value looks like.
> I'm guessing the example value should be 
> "https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" but it would help to just explicitly show it.

Note that I'm opening issues in our github repo to track responses to your feedback.

We could include the Push-Receipt header field in the earlier Section 5 example and then explain its use in Section 5.1. To be consistent with the other examples, its value would be the example URI returned in Section 4:

  https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN

> Also, as I understand it, if the application server does not want a 
> push message receipt, it would not do anything that is specified in Section 4 and so will also not send the Push-Receipt header. Is that correct?

That is correct.

> If so, does the Push Server still need to send back a 201 Created (with the Location header populated) or should it send back a 200 OK instead.

I'm uncertain which operation or section is being referenced. Can you clarify?

> To take an example of a push message for a call notification, the AS 
> is expecting the notification to be delivered immediately and its going to get an inherent acknowledgement
> by the mere fact that the actual app was woken up to receive the call.

There's no guarantee that the message would be delivered immediately due to intermittent connectivity.
How does the application server know that the app has woken up and received the call?

> If stuff in Section 4 and Section 6.2 does not happen, can the 
> interaction between the UA and the PS be simplified (the PS can itself 
> delete the push message resource)

This is a great question. It demonstrates that we need to clarify the relationship between Acknowledgements and Receipts
and their related scenarios.

As outlined in https://tools.ietf.org/html/draft-thomson-webpush-protocol-00#section-6.1, the intent for Acknowledgements:

   To ensure that a push message is properly delivered to the user agent
   at least once, the user agent MUST acknowledge receipt of the message
   by performing a HTTP DELETE on the push message resource.

What's missing in this description is the requirement for the user agent to receive AND process
the message before acknowledging receipt. The device may have been interrupted after receiving 
the message with resulting loss of state.

Push Message Receipts can be configured when the Application Server also wants to track the status. 

There was more background on the motivation for the feature in the
Introduction of https://tools.ietf.org/id/draft-damaggio-webpush-http2-00.txt :

   A push server that does not support reliable delivery over
   intermittent network connections or failing applications on devices,
   forces the device to acknowledge receipt directly to the application
   server, incurring additional power drain in order to establish
   (usually secure) connections to the individual application servers.

   While reliability is not required for messages that expire in few
   seconds (e.g. an incoming call) or collapsible ones (e.g. the current
   number of unread emails), it is more important when messages contain
   information that is longer lasting, e.g. a command to update a
   configuration value, or the acknowledgement of a financial
   transaction or workflow step.  In particular, in the case of power-
   constrained devices, it is preferable to transmit the actual
   information in the "pushed" message reliably, instead of forcing them
   to reconnect periodically to get the current state.

---

From: Darshak Thakore <[email-masked]>
Date: Mon, 22 Jun 2015 18:47:27 +0000

Comments inline.

On 6/19/15, 7:04 PM, "Brian Raymor (MS OPEN TECH)"
<[email-masked]> wrote:

>> Section 5.1 - Would be useful to give an example of where/when the
>>Push-Receipt header is sent and what the value looks like.

DT> Thanks, I did see the issues in the github repo and have it on my
watch list.

>
>We could include the Push-Receipt header field in the earlier Section 5
>example and then explain its use in Section 5.1. To be consistent with
>the other examples, its value would be the example URI returned in
>Section 4:
>

DT> Yes that would be helpful to the readers.

>> push message receipt, it would not do anything that is specified in
>>Section 4 and so will also not send the Push-Receipt header. Is that
>>correct?
>
>That is correct.
>
>> If so, does the Push Server still need to send back a 201 Created (with
>>the Location header populated) or should it send back a 200 OK instead.
>

DT> I¹m referring to the exchange in Section 5 (POST
/p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1). In response to this post,
the PS sends back a 201 Created with the URI of the push message resource
(Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk).
The only reason for this URI to be provided to the application server is
so that it can get a receipt for it later (with the synthesized GET
request and the 410 GONE response code). However, if the application
server doesn¹t what receipts of messages, then the PS can send back a 200
OK instead of the 201 with Location. In this case, the PS can also
immediately clear out the state of the push message resource as soon as
its delivered to the UA and does not need to maintain it till the
application server asks for the receipt.

>How does the application server know that the app has woken up and

DT> In this particular example, the application server doesn¹t necessarily
care if the user didn¹t pick up a call because they wanted to or because
the notification didn¹t reach the app (for whatever reason). It would
automatically know that there was no response since the app didn¹t
actually establish the call session and that¹s enough for the application
server to do whatever it needs to do (direct the other end-point to
voicemail and/or send an actual confirmable notification to the app that
there was a missed call etc). This is just one example, there are other
IoT cases where the application server itself might be a constrained
device and all its doing is sending some reading every so often (like a
thermometer) and if one of the readings is missed, it wouldn¹t matter so
the application server doesn¹t necessarily need to care for notification
receipts.

Darshak

---

From: Elio Damaggio <[email-masked]>
Date: Wed, 24 Jun 2015 23:13:10 +0000

Hi Darshak,

Comments inline.

-----Original Message-----
From: Webpush [mailto:[email-masked]] On Behalf Of Darshak Thakore
Sent: Monday, June 22, 2015 11:47 AM
To: Brian Raymor (MS OPEN TECH); [email-masked]
Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00

Comments inline.

>> If so, does the Push Server still need to send back a 201 Created 
>>(with the Location header populated) or should it send back a 200 OK instead.
>

DT> I¹m referring to the exchange in Section 5 (POST
/p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1). In response to this post, the PS sends back a 201 Created with the URI of the push message resource
(Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk).
The only reason for this URI to be provided to the application server is so that it can get a receipt for it later (with the synthesized GET request and the 410 GONE response code). However, if the application server doesn¹t what receipts of messages, then the PS can send back a 200 OK instead of the 201 with Location. In this case, the PS can also immediately clear out the state of the push message resource as soon as its delivered to the UA and does not need to maintain it till the application server asks for the receipt.

Elio> The PS will not have to maintain any information regarding the state of a notification. The reason is that the PS (as per proposal) does not support a GET https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk call to receive the receipts. The receipts are delivered as PUSH_PROMISEs to the AS only if the AS wants to (as detailed in Section 6.2).

>>is expecting the notification to be delivered immediately and its 
>>going to get an inherent acknowledgement  by the mere fact that the 
>>actual app was woken up to receive the call.
>

DT> In this particular example, the application server doesn¹t 
DT> necessarily
care if the user didn¹t pick up a call because they wanted to or because the notification didn¹t reach the app (for whatever reason). It would automatically know that there was no response since the app didn¹t actually establish the call session and that¹s enough for the application server to do whatever it needs to do (direct the other end-point to voicemail and/or send an actual confirmable notification to the app that there was a missed call etc). This is just one example, there are other IoT cases where the application server itself might be a constrained device and all its doing is sending some reading every so often (like a
thermometer) and if one of the readings is missed, it wouldn¹t matter so the application server doesn¹t necessarily need to care for notification receipts.

Elio> I agree that there might be cases where an explicit ack is not required. Adding a flag to an incoming notification is a possible solution to avoid sending the ack from the device for each notification. At this time we do not know the impact this will have on power consumption (having just received a notification the antenna is already in high gain) or the percentage of notifications that will be affected.

Darshak

_______________________________________________
Webpush mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webpush

---

From: Darshak Thakore <[email-masked]>
Date: Tue, 30 Jun 2015 23:15:15 +0000

Hi Elio,
Thanks for the comments. I do have a follow up comment mentioned below..

On 6/24/15, 5:13 PM, "Elio Damaggio" <[email-masked]> wrote:

>Elio> The PS will not have to maintain any information regarding the
>state of a notification. The reason is that the PS (as per proposal) does
>not support a GET 
>https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk call to
>receive the receipts. The receipts are delivered as PUSH_PROMISEs to the
>AS only if the AS wants to (as detailed in Section 6.2).

DT>> Thanks for the correction on the GET. I was referring to the 410 GONE
PUSH_PROMISE 
message that is sent by the PS. Section 6.2 explains how an AS requests
push receipts. 
However it is possible that the AS may not request push receipts
immediately,
specifically in IoT like scenarios where the AS itself may goes to sleep
intermittently.
In such cases, the PS would atleast need to store the information that a
particular
Message was delivered and even though the message itself got deleted (by
the DELETE
Operation in Section 6.1), it has to store the URI and other meta info
till it sends 
the PUSH_PROMISE to the AS. For the situations where the AS has requested
the push receipt, the PS
has not choice but to store that information till it sends the PP. However
if the AS
Is not looking to get a receipt (which should be flagged by the lack of
the Push-Receipt header when
Requesting push message delivery as per Section 5), the PS can completely
“forget” the message
That was delivered.

>Elio> I agree that there might be cases where an explicit ack is not
>required. Adding a flag to an incoming notification is a possible
>solution to avoid sending the ack from the device for each notification.
>At this time we do not know the impact this will have on power
>consumption (having just received a notification the antenna is already
>in high gain) or the percentage of notifications that will be affected.

DT>> I agree that when the UA/apps are already up and getting the
notifications,
Sending the ack from the UA to the PS (I.e the explicit DELETE operation)
is not a
Huge burden. As mentioned above, I was referring more the amount of work
that the PS
Has to do and the amount of metadata it has to store.