[Webpush] Feedback on draft-thomson-webpush-http2-02

["Brian Raymor (MS OPEN TECH)" <[e-mail]>]

We plan to attend the IETF 92 meeting and to share proposals prior to the March 9th cut-off date.


1.1.  Conventions and Terminology

Minor - recommend consistent use of "user agent" throughout the draft. There are also references to "client" or "device". For example:
	> "the device creates a registration resource"
              >  "A client sends a POST"


Section 2. Overview

The diagram illustrates "Provide Subscription" between the UA and its Application Server, but there are no further details in the draft. While the expectation is that this is left unspecified by the protocol, further details could be outlined - similar to the text for Push Server discovery and authorization?


Section 3. Subscription

    > The push server includes the "registration" link relation in a Location header field.

    > HTTP/1.1 201 Created
    > ....
    >   Link: </monitor/1G_GIPMorg_n-IrQvqZr6g>;
    >       rel="urn:ietf:params:push:reg"
    > Location: https://push.example.net/reg/1G_GIPMorg_n-IrQvqZr6g

In the sample response, should the Location header and the Registration Link paths correspond:

  Link: </monitor/1G_GIPMorg_n-IrQvqZr6g>;
    ...
  Location: https://push.example.net/monitor/1G_GIPMorg_n-IrQvqZr6g


Section 5. Requesting Push Message Delivery

This could be removed since it is simply implementation guidance?

    > A push service that does not store messages can stream the payload of
    > push messages to the user agent.  Flow control SHOULD be used to
    > limit the state commitment for delivery of large messages.

We plan to propose an optional payload to support parameters such as:

  * time-to-live 
  * multicast
  * delivery receipt


Section 6. Receiving Push Messages

No error conditions/behaviors are defined for cases such as an invalid :path in the PUSH_PROMISE?

    > ... This request also triggers the delivery
    > of all push messages that the push service has stored but not yet
    > delivered.

Could details of the response be further clarified?

    > A user agent can request the last push message for a "subscription"
    > resource by sending GET requests to its URI.

What is the scenario for this case? Is it related to collapsible messages?


Section 7.2 Push Message expiration

It would be useful for the Application Server to be able to send a hint to the Push Server for time-to-live. This is a common feature in existing implementations.

    > ... Stored push messages
    > SHOULD include a Last-Modified header field (see Section 2.2 of
    > [RFC7232]) indicating when delivery was requested by an application
    > server.

Why is a SHOULD preferred rather than a MUST?


Section 7.3 Registration and Subscription Expiration

    > If a user agent has an outstanding request to the
    > "registration" resource (see Section 6), this can be signaled by
    > returning a 400-series response code, such as 410 (Gone).  A push
    > service uses server push to indicate that a subscription has expired;
    > a pushed 400-series status code for the subscription resource signals
    > the termination of a subscription.

What status code does an Application Server receive for expirations and terminations?

    > A user agent can request that a registration or subscription be
    > removed by sending a DELETE request to the corresponding URI.

If the registration is deleted, then are the related subscriptions also deleted?


Section 7.4 Implications for Application reliability

    > An application developer might find it tempting to create alternative
    > mechanisms for message delivery in case the push service fails to
    > deliver a critical message.
    > ...
    > Applications are encouraged to instead provide a means to detect
    > situations where push messages were not delivered and recover
    > gracefully.  For instance, an application server might include a
    > sequence number in push messages; a gap in the sequence can then be
    > used to trigger some form of state resynchronization.

It may be difficult to maintain a per-application sequence counter at scale. This also introduces complexity into the user agent. As noted above, our preference is for the protocol to support delivery receipts.

Section 8.1 Confidentiality from Push Server Access

    > The Web Push API codifies this practice by requiring that each push
    > subscription created by the browser be bound to a browser generated
    > encryption key.

This should include the [API] informative reference? Is the W3C consensus still pending:
 
* Force confidentiality and integrity protection (encryption) #55 (https://github.com/w3c/push-api/issues/55)

* Add an Encryption Key array to the PushRegistration interface #89
(https://github.com/w3c/push-api/pull/89)

and is it useful to reference in the protocol?

8.4.  Denial of Service Considerations

    > End-to-end confidentiality mechanisms, such as those in [API],

Similar comment as in Section 8.1.


Brian Raymor
Senior Program Manager
Microsoft Open Technologies, Inc. 
A subsidiary of Microsoft Corporation