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

From: Darshak Thakore <[email-masked]>
Date: Thu, 18 Jun 2015 09:09:16 +0000

Hi all,
At the Dallas meeting, I had volunteered to review the draft and provide some feedback and comments. I’m a little behind on that but here’s the first installment

I tried to capture the example end to end webpush flow (just to make sure I understand it correctly) in the following diagram:

https://raw.githubusercontent.com/darshakthakore/ietf-work/master/webpush/review/webpush-flow.png

There were a couple of places where I didn’t quite get the intent of the spec (they are marked in red in the diagram above and referenced below)

Section 4 – The first sentence in the last paragraph
“A push service SHOULD provide the same receipt subscribe URI to user agents”.
I’m trying to understand what this means. If we are referring to the "https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" URI in the example in Section 4, how exactly does the push service provide this URI to the user-agent. Is the intent to say that it should provide the same URI to a given application server? (I’ve marked this with the red arrow in the diagram)

Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL?
Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1
Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1

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.
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?
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.
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.
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)

Section 6 - Sentence in second last paragraph –
"In response to this request, the push service SHOULD return link references to the push and receipt subscribe resources, plus expiration information"
Are these the original URL's generated by the PS (i.e. /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV and /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ) or are these the corresponding uri's generated in response to the application server's messages (i.e. r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN and /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk). Also I'm assuming here that the "expiration information" refers to the expiration info of the push messages (i.e their TTL), correct?

Push message prioritization - Would it make sense to use the Prefer header instead of the TTL header. This would allow carrying prioritization info for messages (the prioritization is only relative to the application server's own set of messages) to be carried in the Prefer header (e.g. Prefer: priority=5, wait=10). Also the wait 0 can be used to indicate the equivalent of TTL 0 or we can even define a new preference token.

Darshak

---

From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
Date: Fri, 19 Jun 2015 05:32:38 +0000

> Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1

Nice catch. The current example is incorrect. It should match the urn:ietf:params:push link relation
returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed
to the application server.

This was probably introduced when we made the changes for the "Subscription split"
http://www.ietf.org/mail-archive/web/webpush/current/msg00130.html