[Webpush] Time to live for push messages

[Martin Thomson <[e-mail]>]

A common problem with push message delivery services looks like this:

1. A push is requested by an application server.
2. The user agent is offline temporarily, so the push service stores
the message.
3. The user agent returns long after the event is interesting, but the
message is delivered anyway.
4. The user agent acts on a message that is now useless, and which
could be harmful.

This is particularly annoying for something like a call notification,
which might be delivered well after the caller gives up on the call.
For these, an application can add its own suppression mechanisms.
Though manual suppression introduces a trade-off between risk of
showing a dead alert and added latency.  Also, there isn't anything
that can be done about the battery power that was spent in delivering
the useless message.

So, most systems implement a suppression system at the push service,
where an application server can indicate that a message should not be
delivered after some point in time.  (I've seen one with suppression
that occurs only at the client, but that was spectacularly
unsuccessful.)

The trick here is in working out how to express this.  I see a few options:

A. RFC 4918 describes a Timeout header field, which has semantics that
apply only to the LOCK method.  That could be extended to apply to
PUT.

B. A new header field could be defined to carry the information.  This
would have the same semantics as the above.

C. We could start to explore message payloads.

I prefer the header field options, with a slight preference for
reusing Timeout (even if that means updating RFC 4918).   The precise
semantics would need a little work, but here's a straw man outline:

   The Timeout header field applies to unsafe requests only.  The
client indicates that changes to the state of a resource as a result
of processing the request are to be reset after the described interval
elapses.  The state that the resource is reset *to* is undefined, for
a number of reasons: not all resources will know and support this
header field, some changes might be irreversible, servers are always
free to set the state of a resource to whatever they like, and it
would be nice to avoid the complexity of having multiple interacting
layers of timeout.

You will note that this is compatible with the definition of Timeout
as defined in RFC 4918, including the fact that the server can do
nothing with the lock at the timeout expiration time.

The final consideration here is whether this is something that needs
to enter the core specification, or whether it would be better as a
separate specification.  I have no opinion on that.