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

["Spencer Dawkins" <[e-mail]>]

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