Re: Working Group Last Call: draft-ietf-httpbis-http2-encryption-04

Thanks Julian,

You can find this all on
https://github.com/httpwg/http-extensions/pull/164.  Feel free to
merge if you are happy and we can continue with the remaining changes.

On 31 March 2016 at 00:19, Julian Reschke <julian.reschke@gmx.de> wrote:
>    When the client has a valid http-opportunistic response for an
>    origin, it MAY consider there to be reasonable assurances when:
>
> Q: I assume that refers to the response to a GET on the well-known URI? (the
> example supports that, but then, it's just an example...)

Yes, done.

>    alternative service.  This is done by including the optional "commit"
>    member in the http-opportunistic well-known resource (see Section 6).
>    This feature is optional due to the requirement for server
>    authentication and the potential risk entailed (see Section 5.3).
>
> s/optional/OPTIONAL/?

I think that I've learned to hate RFC 2119.

> 6.  The "http-opportunistic" well-known URI
[...]
>    o  That response has the media type "application/json", and
>
> Q: maybe this should use a custom media type.

I'm not sure what that buys us.

>    o  That response's payload, when parsed as JSON [RFC7159], contains
>       an object as the root.
>    o  The "origins" member of the root object has a value of an array of
>       strings, one of which is a case-insensitive character-for-
>       character match for the origin in question, serialised into
>       Unicode as per [RFC6454], Section 6.1, and
>
> Q: list truncated?

I don't think so.  Mark can you confirm?

>    no prior information (see Section 8.3), or when persisted commitments
>    have expired.
>
>
> 8.3.  Privacy Considerations
>
>    Cached alternative services can be used to track clients over time;
>    e.g., using a user-specific hostname.  Clearing the cache reduces the
>    ability of servers to track clients; therefore clients MUST clear
>    cached alternative service information when clearing other origin-
>    based state (i.e., cookies).
>
> Q: is this a new normative requirement, or does it just restate what alt-svc
> says?

Yes, it is repetition.  I think that we can remove this, Mark?

> 8.4.  Confusion Regarding Request Scheme
> This section looks a bit unstructured. Paragraph 3 seems to restate what
> Paragraph 1 already says.
>
> Paragraph 2 IMHO needs to be clearer: it refers to the protocol used to
> perform the opp-sec-ed request, not the original one, right? FWIW, I still
> think that the reasoning for this is weak (an HTTP/2 server stack might
> suffer from the same problem), and thus should either be relaxed, or better
> explained.

I've restructured this and explained the distinction between discovery
and use a little better, but I'm not going to change the fundamentals
here.  We've gone over that point a fair number of times already and I
thought that we had reach some sort of pseudo-acceptable (if weak)
compromise position on it.

Received on Thursday, 31 March 2016 00:43:07 UTC