Re: [Webpush] Time to live for push messages

[Costin Manolache <[e-mail]>]

On Sat, Feb 21, 2015 at 2:33 PM, Martin Thomson <[e-mail]>
wrote:

> 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.
>

I agree - my comment was more on the slightly strange syntax - "Second-"
prefix and "Infinite" constant are a bit odd compared with other ways
to represent time.


>
> 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.
>

Server can include 'max ttl' in the response if it rejects too long time,
so client can use max ttl. Or accept it with a shorter ttl, but include the
shorter ttl in response.


>
> > 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.
>

Another benefit of having ttl as URL param - or in payload - is for the
case message needs to go trough multiple servers.


>
> > "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.
>

Agreed - relative time in seconds sounds good, just
URL param vs Header vs payload.




>
> > 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.
>

One use case is a message that goes trough multiple servers - and may
be gated on the client as well. For example message is for a multi-profile
UA - and it gets delivered to the client machine but it can't be delivered
to
the intended profile ( stopped users on android for example ). Or in
some cases the UA may display a notification before delivering the message
to the app - if TTL expires it may drop the notification and message.

The sender would include ttl=60, push server stores the
message and delivers it after 20 seconds - than the forwarded message would
have the remaining ttl=40 (or ttl=60, 'delay=20'). The message may have
to wait on either client or intermediary  server.

>
> > 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.
>

That's easy if it's internal forwarding, I was thinking of the case of
forwarding to
a different push provider. We should consider the case - given the
complicated
world of mobile.

Costin