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

On 2014-03-19 19:54, William Chan (陈智昌) wrote:
> There was some discussion about this at the IETF89 httpbis session, and
> I see that there's an altsvc branch in the github http2 repo
> (https://github.com/http2/http2-spec/commits/altsvc) with a commit
> (https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99)
> that marks this draft as a normative reference.
>
> I wanted to doublecheck what peoples' thoughts on this matter were. I
> feel like there was some form of rough consensus assessed in the
> session, although the exact details were very ambiguous to me. Currently
> the alt-svc draft lists 4 use cases that could be addressed with various
> proposals:
>
> (1) Upgrading HTTP/1 (" The first use case for Alternate Services is
> upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e., without
> the use of SSL or TLS).") as an alternative to HTTP Upgrade.
> (2) Using TLS with http:// URIs
> (3) Mitigating Load Asymmetry
> (4) Segmenting Clients that Support TLS SNI
>
> There are two mechanisms proposed for addressing these use cases. They
> are the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.
>
> My personal gauge of the rough consensus at the IETF89 httpbis session
> was there was rough consensus for meeting use cases (3) and (4), both of
> which require the ALTSVC frame, but not the Alt-Svc response header.
> Furthermore, I think there was rough consensus around incorporating the
> ALTSVC frame directly into the core HTTP/2 spec, although I remember
> Rob's disagreement here (thinking that we should bring back extensible
> frames, and if that doesn't get in, we use should MAY rather than SHOULD
> in the spec as to how clients should handle this advisory frame).
>
> I think that use case (1) did not get discussed at all, and (2) got
> raised very briefly by Pat, but tabled due to lack of time. Both these
> use cases rely on the Alt-Svc HTTP response header. I therefore do not
> believe there's a rough consensus on including the Alt-Svc HTTP response
> header. But perhaps further discussion will reach such a consensus.

I recall that we discussed it, both at the meeting and here on the 
mailing list. The response header field is advisory; no client will be 
required to honor it.

> I'd like to hear thoughts from folks on, what parts of the alt-svc draft
> would be acceptable for inclusion in the HTTP/2 core spec or as a
> normative reference.
>
> FWIW, my thought would be to include the ALTSVC frame in the core spec,
> with a normative reference to a standalone specification of section 3.1
> in the alt-svc draft.

I believe we had reached rough consensus to include the header field as 
well; but it's good that you are bringing this up now.

Best regards, Julian

Received on Wednesday, 19 March 2014 19:53:30 UTC