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:15 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> 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.
>>
>
Oops, I missed responding to this part. My understanding is that Rob was
the main person looking to upgrading from HTTP/1.1 to HTTP/2 in cleartext,
and that they prefer HTTP Upgrade. So if you're including this for his
benefit, I think that may have been a mistake. But I should let Rob speak
for himself.


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