[Webpush] Message expiration (TTL) and Negative Acknowledgements

[Brian Raymor <[e-mail]>]

At IETF 93, we agreed to limit negative acknowledgements to message delivery failures and not message expiration:

https://github.com/webpush-wg/webpush-protocol/issues/17

The thought was that the application server can maintain its own clock for the message expiration based on the TTL exchange where the application server requests a TTL and the push server is allowed to "advertise" a shorter TTL:

Section 6:

   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.

I was finishing up my editorial changes and noticed one potential exception. In Section 7.2, we have some operations guidance:

   Push services might need to limit the size and number of stored push
   messages to avoid overloading.  In addition to using the 413 (Payload
   Too Large) status code for too large push messages, a push service
   MAY expire push messages prior to any advertised expiration time.  A
   push service can reduce the impact [of] push message retention by reducing
   the time-to-live of push messages.

This would be a case where the application server should still receive a negative acknowledgement for expiration because it has no awareness that the push server could not honor its advertised TTL.  It's closer to the failure case where a push server ceases to retry delivery of a message prior to its expiration perhaps due to an unresponsive user agent.

Comments?

...Brian