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

[Martin Thomson <[e-mail]>]

Thanks Brian,

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

On 13 February 2015 at 13:46, Brian Raymor (MS OPEN TECH)
<[e-mail]> wrote:
> 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"

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

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

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

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

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

> 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

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.


> Section 6. Receiving Push Messages
>
> 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].

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

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]

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

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.

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

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.

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

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

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

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.

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

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.