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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Oct 2016 13:46:27 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-webpush-protocol-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alexey on the "well-written document" part, but do have some
minor questions.

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

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

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

---

From: Brian Raymor <[email-masked]>
Date: Thu, 13 Oct 2016 04:02:33 +0000

Hi Spencer,

      

      

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

> "Topic: upd" looks like "upd" would have semantic meaning, on first

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

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

>   the message until its advertised expiration.

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

   
> isn't just about "establish", but "establish and maintain"?

That would be more precise. Updating.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Oct 2016 23:13:07 -0500

Hi, Brian,

Thanks for the helpful explanation, and thanks for considering my comments.

Spencer