RE: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> On 03/20/2014 02:39 AM, William Chan (陈智昌) wrote:
> >  If everyone else says they believe that the working group consensus
> > indeed is to document http:// over TLS in the core HTTP/2 spec,
> 
> With no hats, I'd like to be on the record as saying that documenting how to
> do http:// URIs via TLS as part of HTTP/2.0 would be a really good thing to do.
> Especially in the light of recent reports of cleartext HTTP being used to trigger
> other attacks. And defining that at the same time as we are defining
> HTTP/2.0 seems like the perfect time to me. (Adding it later would be far less
> good IMO.)
> 
> I don't have a very strong position about which 2119 keywords are used to
> talk about whether that MAY, SHOULD or MUST be implemented or used,
> but one could argue that both BCP 61 and the new perpass-attack BCP will be
> far more clearly satisfied the more that feature is implemented. The main
> thing for me however is that it be well-defined now so that those who want
> to use that feature can do so and get interop and be in a position to mitigate
> attacks such as those referred to above without requiring changes to web
> content.
> 
> And yes, I do get that this is not entirely a slam-dunk, but from the discussion
> I've heard and the evidence that it can be done from Patrick and I think Will,
> it seems to me that defining how to do it ought not be something that'd add
> significant (or any) delay.

[Gab] I think there was agreement in London to go ahead and document it. The issue is of a different nature. If the base spec adds a normative reference to the alt-svc spec, it adds a blocker from the point of view of the RFC editing/publication process. We did not discuss informative vs normative reference in London, but we also agreed in London (very clearly, per my recollection) that alt-svc would not be a blocker for HTTP/2. 

Documenting and having an informational reference is non-blocking, and appropriate as well, since one does not need to understand all the alt-svc scenarios in order to implement the ALTSVC frame. This is analogous to how PUSH and flow control also have the low-level mechanisms in the spec, but how to actually use them (PUSH strategies, flow control algorithms) are left out.

Received on Thursday, 20 March 2014 15:47:25 UTC