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

Hey Will -

My understanding of consensus was that the frame was to be done in the core
document and the header/error code would be referred to separately and
Julian would edit that document. The split is mostly because the
header/error-code are not wire protocol bits for http/2. There are not MUST
requirements around honoring them other than not SESSION-ERRORing when you
parse them.

I think you'll find you need the header to adequately address the SNI case
if you'd like to do that discovery from plaintext http/1 - a likely case if
SNI is the blocker to effectively hosting https://.

More pertinent of course is the fact that this is one plan for
bootstrapping http/2 - and if its going to be used, like upgrade which I
consider far messier, it should be documented to get consistency among
those parties that wish to use it.

-P

On Wed, Mar 19, 2014 at 2:54 PM, William Chan (陈智昌)
<willchan@chromium.org>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'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.
>