[Webpush] Non-blocking comments on -05

[Peter Beverloo <[e-mail]>]

Hi Martin, Brian, Elio,

As an implementer I can only express my gratitude for the fantastic
creating and editing of the standard you have done - thank you *so* much!

I have a few last-minute comments, none of which have to be blocking for
the WGLC. I'll acknowledge agreement in Shida's thread momentarily.

    1) Page 11, "A push message with zero TTL...push messages."

This section is very loose in defining whether or not delivery receipts
should be send for messages with TTL 0. In effect, behaviour of the Web
Push services out there today may strong-arm future services by
establishing developer expectations.

Have we considered not sending receipts for messages with TTL=0 at all?

    2) Page 21, "this can be signaled by returning a 400-series status
       code, such as 410 (Gone)."

This is the only ambiguous status code reference in the standard. What is
the reason for not settling on 404 or 410?

The example of 410 for expiring subscriptions here is different from the
404 mentioned in 7.1 (Page 20), it would be good to make that consistent.


I also have a few editorial comments:

    - Page 3, "Requesting the delivery of events is particularly important
      for the W3C Push API."

It is not explained why it is particularly important. Is this assumed
knowledge of the reader? I would suggest the following addition:

"...for the W3C Push API as the developer may have to request push message
delivery from any number of push services."

    - Page 4, definition of "application server"

Nothing precludes an application from not needing a server side at all. I
don't think we should change the term, but perhaps we can consider
slightly rephrasing the definition as:

"The component of an application that *usually* runs on a server and
requests the delivery of a push message."

    - Page 7, "Confidentiality protection and application server
      authentication MUST be used to ensure that this URI is not disclosed
      to unauthorized recipients (Section 8.3)."

Is it appropriate for the standard to dictate a MUST here when the
distribution method is defined to be application-specific? (I do agree
with the premise.)

    - Page 7, "[subscription sets] can represent a significant efficiency
      improvement for a push service."

There are significant improvements for many types of user agents as well,
so I would suggest rephrasing as "... improvements for push services and
user agents."

    - Page 8, "The push message is included in the body of the request."

While covered by Section 8.1 in the Operational Considerations, given the
strong focus on security and privacy considerations throughout the rest
of the standard I think it would be appropriate to mention the strong
preference for encryption here?

    - Page 11, page 13: s/acknowledgement receipts/delivery receipts/.

    - Page 12, 13: Both "update" and "replace" are used to describe the
      same operation. I don't think that consistently using "replace"
      would change the meaning of this section- could we?


One final thing that I'm on the fence about is that the push service MUST
NOT forward the Urgency value to the user agent. I can see uses, but also
concerns in the scenario of a compromised or malicious push service. Is
this the reason behind the strong language?

Thanks,
Peter