Re: [Webpush] Spencer Dawkins' No Objection on draft-ietf-webpush-protocol-11: (with COMMENT)

[Brian Raymor <[e-mail]>]

Hi Spencer,

> I noticed that 
>
>  push message subscription:  This resource provides read and delete
>     access for a message subscription.  A user agent receives push
>      messages (Section 6) using a push message subscription.  Every
>     push message subscription has exactly one push resource associated
>     with it.
      
> and

>   push message:  The push service creates a push message resource to
>      identify push messages that have been accepted for delivery
>      (Section 5).  The push message resource is also deleted by the
>      user agent to acknowledge receipt (Section 6.2) of a push message.
      
> don't say "A link relation of type ..." about the resource being defined,
> but 

>   push message subscription set:  This resource provides read and
>      delete access for a collection of push message subscriptions.  A
>     user agent receives push messages (Section 6.1) for all the push
>      message subscriptions in the set.  A link relation of type
>      "urn:ietf:params:push:set" identifies a push message subscription
>      set.

>   push:  An application server requests the delivery (Section 5) of a
>      push message using a push resource.  A link relation of type
>      "urn:ietf:params:push" identifies a push resource.
      
> and 

>   receipt subscription:  An application server receives delivery
>      confirmations (Section 5.1) for push messages using a receipt
>     subscription.  A link relation of type
>      "urn:ietf:params:push:receipt" identifies a receipt subscription.
      
> do. Is that intentional? Or would link relation indentification not be
> useful for these resources (if you told me that, I'd believe you).

It is intentional. Both the push message subscription and the push message
resources are returned in the Location: header in the 201 (Created) response
and don't require a redundant link relation.

For example:

https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-4

   A 201 (Created) response indicates that the push subscription was
   created.  A URI for the push message subscription resource that was
   created in response to the request MUST be returned in the Location
   header field.

> I see that Topic: has no semantics, but I wonder if the example use of
> Topic in Section 5.4 might be clearer if a different Topic was used -
> "Topic: upd" looks like "upd" would have semantic meaning, on first
> reading.

I'm open to suggestions, but I don't know that a change would enhance
clarity. 

> I wondered why the use of subscription sets in

>   There are minor differences between receiving push messages for a
>   subscription and a subscription set.  If a subscription set is
>   available, the user agent SHOULD use the subscription set to monitor
>   for push messages rather than individual push message subscriptions.
   
> was a SHOULD, and not a MUST. Is this just an efficiency thing, or is it
> something else? It would be helpful to explain this.

Subscription sets evolved over time as we explored appropriate models
such as "push service decides" or "user agent decides". In the end, we needed to
ensure that the subscription set design was flexible enough to address a
broad range of scenarios, including a late-breaking one from Canon:

https://www.ietf.org/mail-archive/web/webpush/current/msg00357.html

which resulted in "user agent decides" + "push service encourages".

Subscription sets are included for efficiency as described:

    https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-4.1

   Collecting multiple push message subscriptions into a subscription
   set can represent a significant efficiency improvement for push
   services and user agents.  The push service MAY provide a URI for a
   subscription set resource in a link relation of type
   "urn:ietf:params:push:set".

   When a subscription set is returned in a push message subscription
   response, the user agent SHOULD include this subscription set in a
   link relation of type "urn:ietf:params:push:set" in subsequent
   requests to create new push message subscriptions.

This was added for Herve's scenario:

   A user agent MAY omit the subscription set if it is unable to receive
   push messages in an aggregated way for the lifetime of the
   subscription.  This might be necessary if the user agent is
   monitoring subscriptions on behalf of other push message receivers.

> Is there any guidance you could give about the retry mechanism described
> in this text? How many times, how often, etc. 

>   If the push service does not receive the acknowledgement within a
>   reasonable amount of time, then the message is considered to be not
>   yet delivered.  The push service SHOULD continue to retry delivery of
>   the message until its advertised expiration.

There's no general guidance. The policy would be specific to a push service.

> I'm guessing that

>   A push service that does not support reliable delivery over
>   intermittent network connections or failing applications on devices,
>   forces the device to acknowledge receipt directly to the application
>   server, incurring additional power drain in order to establish
>   (usually secure) connections to the individual application servers.
   
> isn't just about "establish", but "establish and maintain"?

That would be more precise. Updating.