Draft: draft-ietf-webpush-protocol

Commentary: 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 . 
 notes that prioritization can be important . This is true . Maybe look at somehow integrating 
 First , we need to clarify whether there are scenarios that require priorities to be included in the base specification : : As I went through the draft I was n'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 . : 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 : 
 Once we have clarity on scenarios and requirements and evaluated the importance of this feature , then we can consider designs . has proposed nice-02 for the scenario above . : Would it make sense to use the  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  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 . : 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 we d 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     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  '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 . 
 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 should n'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  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 does n'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  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 .  is a " high priority " system . 
 I think both your messages present good arguments for reasoning about this as urgency rather than priority . Having thought about this more , I do agree that probably is not the best term . I certainly subscribe to  '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 . 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 is n'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 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  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 is n'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 . 
 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 . 
 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 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 . ) 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 ca n't imagine the opposite happening very often , but there you are ) . 
 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 would n't collapse but actually just delete the existing one . Why a topic would go from Nice 1 -Nice 2 , I do n'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 do n'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 should n'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 has n't been used for some time ( for example screen off , did n'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 ,  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  spec covers how the client asks for notifications . When we talk of how the  server has urgency values attached to notifications , I assume this means by necessity we will be talking about how the  server knows all these various things about the client to make these determinations ? 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  service ? Is it the right place for the  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 would n't work otherwise for the deep sleep for example ) . I think common ones could be to webpush spec , but with lots of care - we do n'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 . 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 .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
A push service MUST return a 400 (Bad Request) status code in
response to requests that omit the TTL header field.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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
Topic header field that does not meet these constraints MUST return
an HTTP 400 (Bad Request) status code to the application server.
Paragraph (version B):
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
Topic header field that does not meet these constraints MUST return a
400 (Bad Request) status code to the application server.