Subject: Re: [Webpush] TTL of 0

From: Brian Raymor <[email-masked]>
Date: Wed, 5 Aug 2015 23:37:10 +0000

On Tues, Jul 28, 2015 at 5:31 PM, Benjamin Bangert <[email-masked]> wrote:

> The spec indicates a TTL of 0 should result in the message not being delivered if the client is not connected.
> However, it doesn't indicate whether the Push server is still under the same obligation to provide a Location
> header in the response in this case (I assume its still a 201, even though a resource was not created?).

> Should a Location still be returned? What kind of receipt is assumed in this case (or no receipt and no Location)?

I've created https://github.com/webpush-wg/webpush-protocol/issues/38 to track this issue.

Obviously, the lack of clarity is related to the phrase "storage is not needed" which suggests that a resource might
not be created:

	Absence of the TTL header field is interpreted as equivalent to a
	zero value.  Push messages with a zero TTL indicate that storage is
	not needed and that the message can be dropped if the user agent
	isn't immediately available to receive the message.

(I also appreciate that GCM 'time_to_live' (https://developers.google.com/cloud-messaging/downstream#ttl)
and APNS 'expiration date' offer similar statements regarding storage.)

I think that the scenario focus for TTL 0 should be more on 'now or never' delivery than on the storage implications.

The message resource is always created and subsequently appears as the :path of the synthesized GET in the PUSH_PROMISE:

   PUSH_PROMISE [stream 7; promised stream 4] +END_HEADERS
     :method        = GET
     :path          = /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk
     :authority     = push.example.net

For TTL 0, the message resource does not need to be stored for additional retries, but should exist
long enough for a 'prompt' UA to acknowledge receipt (DELETE the resource) if the message was 
delivered.  Of course, the UA must be able to handle 404(s) in response to DELETE(s) in any case.

I'd propose to rewrite the original text along the lines of:

	Absence of the TTL header field is interpreted as equivalent to a
	zero value.  Push messages with a zero TTL indicate that the
	application server is requesting 'now or never' message delivery 
	to the user agent.  

If the message is not delivered and/or acknowledged and a receipt was requested, then existing language covers this case:

   The push server MUST push a response with a status code of 5XX (TBD)
   if the user agent fails to acknowledge the receipt of the push
   message or the push server fails to deliver the message prior to its
   expiration.

Comments?

...Brian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Aug 2015 19:33:55 -0700

>         application server is requesting 'now or never' message delivery

I think that your answer is good, but I think that this wording could
be improved.  "now or never" is a little imprecise.

I think that the intent is fine in the original, but in addition to
your changes, I think that a second paragraph might be a good idea, if
just to answer questions like Ben's:

If the user agent isn't available to receive the message, then a push
message with a zero TTL will not be delivered.  Furthermore,
acknowledgments for zero TTL push messages could be lost: the push
service is permitted to remove the push message resource immediately,
which might occur before receiving the acknowledgment DELETE from the
user agent.  An application server consequently cannot rely on
receiving receipt for zero TTL push messages.