Change:
As discussed on the , requiring the TTL header field will simplify implementations and avoid potential errors. A 400 (Bad Request) MUST be returned by the push service if the TTL header field is missing.
NAME notes that prioritization can be important. This is true. Maybe look at somehow integrating URL
First, we need to clarify whether there are scenarios that require priorities to be included in the base specification: NAME : As I went through the draft I wasn't able to understand how the push service will handle message prioritization (for the same subscription). Is the expectation that the app server will send them in the right sequence and the push server will use a FIFO (first in first out) queue? The scenario I have in mind is a social network application that can push news alerts and incoming chat notifications. I would expect the chat notification to have a higher priority than other notifications. If the app server sends notifications as they happen, it is only the push service that will be able to act based on some form of prioritization indicator. Priority is a fairly basic requirement and I hope it can get handled in a header so it can be consistently enforced by the push service. NAME : Prioritization is a concern if there are multiple messages to deliver at the same time. This happens most often when a device comes back from a short nap (as mobile devices do all the time). With a small number of messages, this might not be a big deal, but if there is a backlog to clear, it could be. I have a draft on signaling priorities that could be used in this context: URL
Once we have clarity on scenarios and requirements and evaluated the importance of this feature, then we can consider designs. NAME has proposed nice-02 for the scenario above. NAME : 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. NAME : Generally speaking, I believe Prefer to be better suited to requesting variations in request handling; whereas this is an example of information that describes the resource itself. That said, I'm not wed to the idea of a new header; Prefer: ttl=10 would work._
Discussed in Yokohama: we will leave this out of the core document; we will await a proposal that we can use as the basis for further discussion.
Priority is too overloaded a term, since it may refer to: Message Ordering Urgency ("Niceness") as in "Is it urgent enough to wake the device and burn the battery?" Updating this issue to be specific to urgency. I plan to adapt and integrate Martin's as a proposed solution. For example: Nice 0 - send urgent message immediately and wake up the user agent Nice 1 - send opportunistically – send prior to expiration if no urgent messages are queued Nice 2 - send opportunistically – allow to expire if no urgent messages are queued
We plan to include the Nice header in an upcoming version of our implementation with the following deliberate violation: Requests not bearing the Nice header will be treated as messages of default priority (similar to Nice: 1 in Brian's description). The issue of defaulting to high priority is that the consequences of forgetting to include the header (waking up the UA) are disproportionate to the error - especially for more active users or users using a lower end device, this can have a very negative effect on the device's battery life. There's definite value in allowing the push service to optimize for the default case. The application server can then supply the Nice header to clarify the intent and urgency of the message.
NAME this is interesting. I'd like to reach some sort of consensus on how to present priority, especially defaults. Would recasting the header field into a three-valued enumeration of high/normal/low be a better fit for your use case? Webpush might interpret high as needing an urgent wakeup and low as being something that could wait until there were other messages to send. At that point, we might as well call it Priority it's no longer really appropriate to call it :( That suggests values of urgent, normal and non-urgent such as are used in the mail header field, which might be a better choice.
I have to admit, I have a few concerns about this proposal. 1) Priority - Push notifications are already pretty much temporal and priority, right? Essentially, this would offer a two state option of "Deliver this to my app NOW!" or "Deliver this whenever." My concern and complaint would be that the low priority messages probably shouldn't go through the web push channel. Instead, the app could spin up on it's own and check for outstanding messages that it might have, rather than use a complicated mechanism like push to do it. 2) Privacy - I like to think of the Push system as being like a mailman who's a jerk. A priority flag on a message would be delivered in the clear and would tell all the world, "Hey, if you're going to spend any time trying to break into a message, this would be a really good candidate." You could bury the flag inside the encrypted body, of course, but then you'd either have to make the UA far smarter about dealing with the body content of a push notification and that's probably not a great idea either. 3) Management - Doing distribution control on the server doesn't really make a lot of sense. For one, the connection between the server and the UA is always open, so the message should get distributed. This also means that if the UA is queuing these messages, it will have to determine when to toss messages when it runs low on resources, making low priority messages even more lossy. Plus, I'm willing to bet that apps will want to replace or recall low priority messages, meaning that there will eventually be some queue management system the UA will require, and I can see whatever battery savings that low priority messages might bring being eaten by the UA dealing with them. tl;dr: have the app pull low priority messages when it likes. Push is a "high priority" system.
I think both your messages present good arguments for reasoning about this as urgency rather than priority. NAME Having thought about this more, I do agree that probably is not the best term. I certainly subscribe to Brian's mapping of the {0, 1, 2} values to their interpretation in context of Web Push, but those would work with {high, normal, low} urgency as well. NAME Let me reply to each of your points individually. (1) An incoming phone call (real-time messaging) is more urgent than a received e-mail or social media invite, while you'd still like to know about the latter prior to the next use of your e-mail client. We'd like to avoid apps spinning up on their own to effectively poll for information, that could have a very negative impact on battery life. (2) My goal is to avoid waking the UA up if there is no need to, so embedding this in the encrypted payload would not work. Does reasoning about this as urgency rather than priority help in regards to the attack vector? Several kinds of urgent messages tend to be more ephemeral as well. (3) Distribution control on the server allows non-urgent message transmissions to be intelligently grouped together if the user isn't using their device, e.g. when they're asleep. This allows the open connection to remain in a lower activity state (e.g. PCH) for longer, using significantly less energy, while still allowing for the immediate delivery of urgent messages. Furthermore, doing distribution control on your server allows the deletion and replacement of non-urgent messages to be done without informing the UA at all, for example following URL for message collapsing.
I suppose I'm still not really seeing the value of this. As you note, a highly urgent message would require the UA to do work, the app to be woken and all the various things that should be required. It's a significant action. I'm not really sure I'd find it useful to be woken up at 3AM to be told that a server is down, oh, and that four of my old high school friends killed snakes in Farmville. It may be that my server manages Farmville's virtual snake generation and both sets of information are equally useful, but probably not. Messages are still noted as being "special" and therefore there's user meta data potentially being exposed, there's additional management and storage work that the server would need to do( particularly if a large partner were to start using this function) just to keep the app from doing a HTTP request. I feel that we're adding a fair bit of complexity for little real gain. An app can still gather "low priority" messages from it's own server according to that app's specific logic. If there are additional complexities around those low priority messages, we can remain gleefully unaware of them and remain focused on ensuring that a message of import gets through our system as quickly and reliably as we can afford. Of course, there's absolutely nothing preventing a push provider from offering this as a proprietary feature as well. I'd just rather this protocol not be made a magnificent hammer to use on every nail.
Having had a conversation with Ben about this, let me also clarify a few things. 1) An app could start for any reason. User activity, timer, etc. There is nothing preventing or discouraging that app from checking it's server for outstanding messages right now. 2) I understand the appeal of having extra information handed to an app that is being woken by a high priority message may bring. I feel that perhaps it would be better for app developers to understand that sending messages incurs a device cost. Instead of trying to fix the protocol (where only a small population may set a flag indicating "This message isn't urgent"), we instead make sure that app developers simply only send messages via our system that may cause folks to uninstall their app. 3) The idea of "low priority" messages bother me because any messages that are undelivered will bring complexity. If you have a message that reflects state (like 50 unread mail) do we deliver 50 messages? Perhaps it might make sense to consider "collapse" messages as low priority by default, as I believe you're suggesting, and deliver those to the UA only when a high priority "normal" notification is sent. Sorry if I seem overly dense or antagonistic. I'll blame a head cold.
NAME So far this only seems to cover the header sent to the Push Service, I assume there's some corresponding change to how a UA asks a Push Service for notifications such that it can do a one-off poll that indicates if there's any Nice 0 messages? I'm somewhat concerned that Nice 2 messages increase database load for a Push Service, since accepting those notifications requires a database hit to see if they should even be stored. Speaking of collapse keys, how do they go with urgency levels? Are topics unique to the urgency level? It would be weird for a Nice 0 message to replace a Nice 1 message with the same topic. I would expect topics with different urgency to be separate, or undefined improper behavior. Edit: Not worried about the Nice 2 db read, since in cases there's no Nice 0 it'd avoid a db write which is generally more expensive than a read anyways.
NAME Part of the efficiency advantage of a push service is its ability to coalesce multiple messages into a single message to a user agent. That means delaying some messages. Urgency indicators help the push service decide how much delay is acceptable. (And as NAME notes, if the user agent can indicate an urgency on its polling request, that might govern push service behaviour as well. For instance, a mobile device that is on battery power overnight might want the push service to treat "normal" requests as "non-urgent" for that period.) NAME for simplicity, I would expect that the urgency of an updated push message will simply update the urgency of the topic. If it was previously non-urgent and becomes urgent, then it should be delivered urgently. (I can't imagine the opposite happening very often, but there you are).
NAME my main thought was that it could cause some odd results, since if its a Nice 2 topic, and there were no Nice 0 stored, it wouldn't collapse but actually just delete the existing one. Why a topic would go from Nice 1 -> Nice 2, I don't know offhand but I guess someone could dream up a case for that.
The headers should provide enough information to enable the push service to optimize for network and battery usage. "Urgent" is clear - deliver ASAP, no matter what. A push service may look for abuse of "urgent", and I don't think it should be default. If the device is offline: urgent may still be affected by expiration and collapse, but as soon as the device gets connected urgent will be delivered. The main issue is what kind of optimizations we can do for the others - and how to provide the right information in the headers so it's clear for both sender and push service what actions can be taken if a message is not urgent. One problem is how long can the push service delay a non-urgent message, if the device is connected. Expiration is not a good indicator - for "mail messages waiting" you may want a large expiry ( 1 day ) but you want to limit the delay for 15 min. If user is connected, message will be delayed up to 15 min, if not - it'll still be held for 1 day, and collapsed with more recent messages. If a device is 'charging' and on wifi ( desktop browser ) - the push service may choose to just send all messages immediately - there are costs for delaying the messages. The spec shouldn't require that "nice=2" messages will be delayed - the nice should be an indication that some delay is acceptable. It's up to the app to notify or not notify you in the middle of the night that you got some unimportant notification. If the device is on battery - and maybe hasn't been used for some time ( for example screen off, didn't move) - it makes a lot of sense to delay all messages until device is active. Keep in mind that on some devices when this mode is detected, apps may also be restricted on what they can do with incoming messages for battery saving. And the device itself may have some update windows when it can process the messages. IMHO this is the most important use of Nice - saving user's battery and making sure the apps can handle the messages. TTL=0 ( or very short expiration ) is another factor - not clear how it should interact with niceness. The main use is to not save the storage costs, if device is not connected.
The WebPush spec covers how the client asks for notifications. When we talk of how the Push server has urgency values attached to notifications, I assume this means by necessity we will be talking about how the Push server knows all these various things about the client to make these determinations? NAME Do you plan on introducing additional flags for the client when making a notification request that conveys all this additional knowledge (on wifi, 'charging', etc) to the Push service? Is it the right place for the Push service to choose how to optimize delivery, or should the client flag indicate what level of urgency it wants notifications for?
GCM uses a binary protocol for UA-push service, which already has the flags ( it wouldn't work otherwise for the deep sleep for example ). I think common ones could be added to webpush spec, but with lots of care - we don't want the UA to send notifications too often (for example on state change). A start would be to define a header for the 'monitor' request, with a list of flags, and define common ones ( charging, network type ).
Noting earlier httpbis discussion on the use of instead of a custom header
PushSubsctiption has two parameter: endpoint and subscriptionId. ReceiptEndpoint should be added. I leave comment here and not in webpush api until this draft is close to be final regarding this.
This is not actionable in the protocol draft. Please open an issue in the W3C repo if appropriate.
This is just for the request from the application server to the push service. Can we require a TTL value for web-push notifications? The current behavior is not obvious to an implementer and likely to lead them to think they've successfully sent messages when they're actually dropped. If you omit the TTL, then the value is assumed to be 0. This results in the message being dropped, but the 201 status is still returned. An astute implementer will notice in this case that no Location header is present, since no resource was actually created. Regarding the resource creation, the spec does not clearly state whether a Location header should be returned for a TTL of 0 since its intended that the message is only delivered to an online user. If so, it would be useful to mention. In the past 2 days, out of approximately 76k webpush notifications to our service, 23k of them were dropped due to a missing TTL header, but a 201 status was returned. Defaulting a missing TTL header seems ripe for implementer issues (I have a hard time believing this many dropped notifications was intentional). If it was a required header, we could return a 401 which would very quickly alert developers about the problem. Cheers, Ben
Brian, Martin and Elio, Thanks for the offline coordination and for putting this version together. I finally managed to get to review the draft and it looks good for the most part. I made a few comments on the issues in github so I won't repeat them here. A couple topics came to mind and I would like to throw them here for further clarification from the authors: Prioritization As I went through the draft I wasn't able to understand how the push service will handle message prioritization (for the same subscription). Is the expectation that the app server will send them in the right sequence and the push server will use a FIFO (first in first out) queue? The scenario I have in mind is a social network application that can push news alerts and incoming chat notifications. I would expect the chat notification to have a higher priority than other notifications. If the app server sends notifications as they happen, it is only the push service that will be able to act based on some form of prioritization indicator. Priority is a fairly basic requirement and I hope it can get handled in a header so it can be consistently enforced by the push service. Message deduplication and retries. Section 6.1 talks about acknowledging push messages and that the user agent must acknowledge with an HTTP DELETE if the message was delivered at least once. Should we have a mechanism in place to account for message deduplication? I might be wrong but I can see situations where the three parties (AS, PS, UA) end up in some race conditions and the AS ends up retrying. It would be good to clarify that the push messages for the same application event instance (e.g. call from Bob) MUST have the same identifier so they can be duplicated at the PS so they don't get sent multiple times to the UE. Regards, Dan -----Original Message----- From: Webpush [mailto:EMAIL] On Behalf Of Brian Raymor (MS OPEN TECH) Sent: Wednesday, April 15, 2015 5:43 PM To: EMAIL Subject: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-URL As requested at the last WebPush meeting in Dallas, Martin, Elio, and I have merged our proposals into a straw-man for review. During that process, we've captured issues at: URL but will now migrate those discussions to the WebPush mailing list in the next few days. ...Brian -----Original Message----- A new version of I-D, draft-thomson-webpush-protocol-URL has been successfully submitted by Brian Raymor and posted to the IETF repository. Name: draft-thomson-webpush-protocol Revision: 00 Title: Generic Event Delivery Using HTTP Push Document date: 2015-04-15 Group: Individual Submission Pages: 21 URL: URL Status: URL Htmlized: URL Abstract: A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at URL The IETF Secretariat Webpush mailing list EMAIL URL
Generally speaking, I believe Prefer to be better suited to requesting variations in request handling; whereas this is an example of information that describes the resource itself. That said, I'm not wed to the idea of a new header; Prefer: ttl=10 would work.
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: URL 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 "URL" 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 "URL" 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
[...] The draft really doesn't say, partly because we didn't discuss it much, partly because I think that we'd want some flexibility. I've opened an issue on this in our issue tracker so that we don't forget this. Prioritization is a concern if there are multiple messages to deliver at the same time. This happens most often when a device comes back from a short nap (as mobile devices do all the time). With a small number of messages, this might not be a big deal, but if there is a backlog to clear, it could be. I have a draft on signaling priorities that could be used in this context: URL Do you think that we need to address this in a basic protocol specification, or can it rely on other specifications. Yes, reliability is hard. The intent is to have the application mark messages and perform deduplication if it does resending, especially within the TTL period that the push service promises. In terms of the protocol, there is a proposal for message replacement that might reduce the need for some of this, but Brian, Elio and I decided that we'd let this draft stabilize before talking about that feature: URL

Discussion:
call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert. <del> An application server can use the TTL header field to limit the time that a push message is retained by a push service.  The TTL header field contains a value in seconds that describes how long a push message is retained by the push service. Once the Time-To-Live (TTL) period elapses, the push service MUST NOT attempt to deliver the push message to the user agent.  A push service might adjust the TTL value to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays. </del> <ins> An application server MUST include the TTL (Time-To-Live) header field in its request for push message delivery.  The TTL header field contains a value in seconds that suggests how long a push message is retained by the push service. A push service MUST return a 400 (Bad Request) status code in response to requests that omit the TTL header field. A push service MAY retain a push message for a shorter duration than requested.  It indicates this by returning a TTL header field in its response with the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. Once the TTL period elapses, the push service MUST NOT attempt to deliver the push message to the user agent.  A push service might adjust the TTL value to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock skew or propagation delays. </ins> A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or

application server needs to account for transit delays in selecting a TTL header field value. <del> Absence of the TTL header field is interpreted as equivalent to a zero value.  A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message.  After delivery, the push service is permitted to immediately remove a push message with a zero TTL.  This might occur before the user agent acknowledges receipt of the message by performing a HTTP DELETE on the push message resource.  Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages. </del> <ins> A Push message with a zero TTL is immediately delivered if the user agent is available to receive the message.  After delivery, the push service is permitted to immediately remove a push message with a zero TTL.  This might occur before the user agent acknowledges receipt of the message by performing a HTTP DELETE on the push message resource. Consequently, an application server cannot rely on receiving acknowledgement receipts for zero TTL push messages. </ins> If the user agent is unavailable, a push message with a zero TTL expires and is never delivered. <del> A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL header field in the response that includes the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. </del> 6.3. A push message that has been stored by the push service can be

For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64 alphabet RFC4648.  A push service that receives a request with a <del> Topic header field that does not meet these constraints MUST return an HTTP 400 (Bad Request) status code to the application server. </del> <ins> Topic header field that does not meet these constraints MUST return a 400 (Bad Request) status code to the application server. </ins> A push message update request creates a new push message resource and simultaneously deletes any existing message resource that has a