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

On Wed, Mar 19, 2014 at 1:09 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:

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

I hadn't thought it through to be honest. I was mostly trusting y'all in
your draft:
http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-2.4says

"This use case can be met if Section 3.1 and Section 3.3 are accepted"

Note that Section 3.3 is the ALTSVC frame. Section 3.2, which was not
mentioned here, is the HTTP Alt-Svc response header.


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