Draft: draft-ietf-webpush-protocol

Commentary: clarification on TTL of 0 : The spec indicates a TTL of 0 should result in the message not being delivered if the client is not connected . However , it does n't indicate whether the  server is still under the same obligation to provide a Location header in the response in this case ( I assume its still a 201 , even though a resource was not created ? ) . Should a Location still be returned ? What kind of receipt is assumed in this case ( or no receipt and no Location ) ? 
 notes that the requirement to delete immediately after TTL expires ( or at least soon after ) is not compatible with certain push service implementation strategies . We should allow for these designs . Since the data is encrypted , the implications of retention are less , but we should probably still require some upper bound on this time . 
 As by the spec should certainly require that expired messages are not delivered , but not how it is implemented . Best time bound would be ' maximum TTL ' - it 's cheapest in some databases . 
 Tracking   feedback . There 's some confusion about the relationship between UA acknowledgements and AS receipts . For example : 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 ) The draft should clarify the scenarios motivating the feature and discuss appropriate behavior in the face of acknowledgement failures . There were more details about the motivation in the Introduction of : 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 . 
 I believe that this was addressed in the previous set of editorial changes - . Please re - open if further clarifications are required .
Paragraph (version A):
Once the Time-To-Live (TTL) period elapses, the push service MUST
remove the push message and cease any attempt to deliver it to the
user agent.  A push service might retain values for a short duration
after the TTL period to account for time accounting errors in
processing.  For instance, distributing a push message within a
server cluster might accrue errors due to clock variation, or
processing and transit delays.
Paragraph (version B):
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 A):
Absence of the TTL header field is interpreted as equivalent to a
zero value.  Push messages with a zero TTL indicate that storage is
not needed and that the message can be dropped if the user agent
isn't immediately available to receive the message.  Push messages
with a zero TTL can be delivered very efficiently.
Paragraph (version B):
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 B):
If the user agent is unavailable, a push message with a zero TTL
expires and is never delivered.