Re: [Webpush] Time to live for push messages

[Martin Thomson <[e-mail]>]

On 22 February 2015 at 06:53, Costin Manolache <[e-mail]> wrote:
> For option A: the format in RFC4918 is "Infinite | Second-1234".
> Unless 'infinite' is defined to be few weeks - it is going to be hard to
> support.
> I think using seconds instead of absolute value is very good.

It is customary for the server to have the ultimate authority on what
the timeout actually is.  A requested timeout of Infinite is always
going to be shorter anyway, and if the client asks for a month and the
server can only do a minute, then it will be a minute.

The only question there is how much value there is in having the
server notify the client about the actual timeout.  I guess if a
server refuses to store for a particular duration, a client could be
forced to retry for that duration.

> RFC3261 (SIP) uses ';ttl=12' as a URI parameter - without the constant
> "Second-".
> I would personally prefer this option.

The format is unnecessarily clunky, I agree.

> "Expires" header is another option.

I considered that at some length and rejected it for two reasons:

Expires only has defined semantics related to the cacheability of HTTP
responses.  Using Expires in a request context, even for a PUT (maybe
even especially for a PUT) is well outside its original definition.

Also, Expires uses an absolute time and clock skew has proven to be a
major issue.  In theory, an absolute time can be more precise, but
most uses for a TTL are on short timescales where clock skew can
dominate.  At least with a relative time, transit times can be
accounted for.

> An important decision is if the ttl (and other timestamps)
> need to be sent to the device and authenticated or it is going to
> be dropped or modified during transport.

As I alluded to in my first email, I think that the primary value of a
TTL parameter is where the push service uses the value.  Once the push
hits the user agent, it's value is greatly diminished.

Of course, there is nothing wrong with having the push message itself
contain time-based information that is consumed by the application.

> Another complication may be the case the message is
> forwarded multiple times, there are few cases where
> this may become necessary.

If you are required to forward the message, that's an internal detail
of the push service and I'd expect that you would account for any
elapsed time there.  You could, for instance, convert a relative time
into an absolute time for internal consumption, knowing that your
servers have good time synchronization.