Original text:
field contains a value in seconds that describes how long a push message is retained by the push service. <del> 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. </del>  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 TTL header field value. Absence of the TTL header field is interpreted as equivalent to a <del> 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. </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

Reviewer comments:
NAME 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 doesn't indicate whether the Push 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)?
NAME 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 NAME 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 Darshak Thakore 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 URL : 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. GCM is doing lazy cleanup - and checks before delivering any message. The cost to delete each expired message at the time it expired would be quite big - 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. Costin , Martin Thomson wrote: >
The spec indicates a TTL of 0 should result in the message not being delivered if the client is not connected. However, it doesn't indicate whether the Push 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)? Cheers, Ben

Revised text:
field contains a value in seconds that describes how long a push message is retained by the push service.  <ins> 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. </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 TTL header field value. Absence of the TTL header field is interpreted as equivalent to a  <ins> 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. If the user agent is unavailable, a push message with a zero TTL expires and is never delivered. </ins> A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL