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

From: "Brian Raymor (MS OPEN TECH)" <[email-masked]>
Date: Fri, 13 Feb 2015 02:46:23 +0000

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Feb 2015 18:04:04 +1100

Thanks Brian,

I'll see if I can address specific cases here, though I'll break out a
new thread for larger issues.

>         > "the device creates a registration resource"

Yep, that's plain sloppy on my part.  Fixed in [e74ef81]

> 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 th…

I think that's fair.  Do you have text that you would like to see, or
should I just throw something together and iterate?

[...]
>   Location: https://push.example.net/monitor/1G_GIPMorg_n-IrQvqZr6g

Good catch.  I think that Daniel already pointed it out, because I've
already fixed it.

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

Those are definitely important features.

I always imagined that the Expires header field would suffice for TTL,
but after reviewing RFC 7234, I don't think that's quite right.

Multicast is interesting, depending of course on what you intend to do
with it (see https://tools.ietf.org/html/draft-thomson-webpush-aggregate
for a potential take on the problem).

I have had some ideas for how to handle delivery receipt
notifications, but haven't got anything concrete.  I'd be happy to see
a proposal.

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

Ignore or reset should work.  I've noted that in [adf9374].

> Could details of the response be further clarified?

Sounds reasonable.  This is just more server pushes.  I've added
something, though I note that this might change or interact with any
delivery receipt feature that you might propose.  [79fee57]

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

The way that this is structured, each subscription effectively has a
single "collapse key".  Depending on how long a server is willing to
retain data, a request to the subscription URI should return the data
that was pushed.

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

Indeed.  I've opened an issue to track this:
https://github.com/martinthomson/drafts/issues/21

I'll follow up with a separate thread too.

> Why is a SHOULD preferred rather than a MUST?

Because it's not clear to me that all the various push services can
provide this information.  If the working group thinks that a MUST is
OK, then I'd certainly prefer a MUST.  I'll follow up on this
separately.

https://github.com/martinthomson/drafts/issues/22

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

That's definitely an oversight.  Fixed in [223d0bb].

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

Yep, fixed with the above.

> 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 deliv…

This sort of state retention wasn't particularly onerous for the
applications that I've worked on, since we needed for other reasons
anyway.  That said, we would have definitely preferred to receive
application-level acknowledgements.  That is generally the best
reliability mechanism.

> Section 8.1 Confidentiality from Push Server Access
[...]
> This should include the [API] informative reference? Is the W3C consensus still pending:

Yeah, well, I've pre-empted the decision there a little.  I think that
the main hold-up on that end is the absence of anything in the IETF
that can be referenced.  Bootstrapping is hard.  I hope to have
something to announce here soon.