Subject: [Webpush] SHOULD return subscription expiration

From: Brian Raymor <[email-masked]>
Date: Fri, 9 Oct 2015 23:35:42 +0000

This is related to editorial changes for - https://github.com/webpush-wg/webpush-protocol/issues/32 - There was some discussion on Subscription Expiration back in October 2014 on this topic - the thread starts - https://mailarchive.ietf.org/arch/msg/webpush/GVLOvIIY-GD7vHEUJRoqg_wPdWE - and in that thread, Martin was prescient in noting "but I realize that the push channel expiration is going to get confused with message expiry" ;-)

Reviewing webpush-00:

https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-7.3
   ...
   A push service might choose to set a fixed expiration time.  If a
   resource has a known expiration time, expiration information is
   included in responses to requests that create the resource, or in
   requests that retrieve a representation of the resource.

   Expiration is indicated using either the Expires header field, or by
   setting a "max-age" parameter on a Cache-Control header field (see
   [RFC7234]).  The Cache-Control header field MUST also include the
   "private" directive.

   A push service can remove a subscription at any time ...

https://tools.ietf.org/html/draft-ietf-webpush-protocol-00#section-6
   ...
   In response to this request, the push server MUST generate a server
   push for all push messages that have not yet been delivered.  In
   addition, the push service SHOULD return ... expiration information for the
   subscription.

With more experience from prototypes, is the WG finding the optional Subscription Expiration header to be valuable? Or - should we deprecate the Expiration header and just rely on the 400-series status code to signal expiration? Especially since the push server is permitted to expire subscriptions at will?

If we decide to retain the Expiration header, then guidance must be added for when a user agent or application server learns that a subscription is near expiration. Currently, the behavior is unstated in the protocol, although there is related guidance in the W3C Push API which notes that expiration time is a MAY - https://w3c.github.io/push-api/#the-pushsubscriptionchange-event - 

    The pushsubscriptionchange event indicates that a push subscription has been invalidated, or will soon be     
    invalidated. For example, the push service MAY set an expiration time. A webapp SHOULD attempt to 
    resubscribe while handling this event, in order to continue receiving push messages.

For consistency, the subscription expiration for receipts should also be added to 6.2.  Receiving Push Message Receipts.

...Brian

---

From: Martin Thomson <[email-masked]>
Date: Sat, 10 Oct 2015 09:56:54 +0200

Our implementation is currently only reactive when it comes to
subscription expiration.  That means that we tolerate a break if the
server is forced to expire a subscription.

Note that the discussion from before was all predicated on a different
design, one where individual subscriptions were subjugate to a larger
"registration".  The current design, even the with the addition of
subscription sets, doesn't suffer from the ambiguity problem you
described.

However, after reviewing the HTTP cache control stuff in more detail,
I think that it might be best to remove this feature.  The use case
(graceful replacement of a subscription), might be important, but I
don't think that using response freshness as a proxy for subscription
lifetime is correct.  If we discover that there is a need, I think
that an alternative mechanism will be required.  A more direct signal
- an explicit "refresh now" message - might be a superior option.

The consequence of that is that we will rely on the 4xx responses to
inform user agents of when the push service has expired a
subscription.  For the moment, that's probably OK.  The consequential
drop in reliability should be low.

On 10 October 2015 at 01:35, Brian Raymor <[email-masked]> wrote:
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush

---

From: Brian Raymor <[email-masked]>
Date: Tue, 13 Oct 2015 03:12:04 +0000

On October 10, 2015 12:57 AM, Martin Thomson <[email-masked]> wrote:

> lifetime is correct.

Since there were no further concerns raised, I submitted a pull request :
    https://github.com/webpush-wg/webpush-protocol/pull/47
for the design change.