Re: HTTP/2, "h2t" and protocol identifiers in general

What I'd like to see is the following.
h2 means that we're using the HTTP/2 protocol, and it implies at minimum
that the server supports accepting whatever is the default protocol for the
port, typically HTTPS if using ALPN.
The scheme defines the application-layer semantics of any particular stream.

That h2 implied acceptance of HTTPS on :443 or HTTP on :80 would not
preclude using another scheme.


S
I am really not interested in seeing a combinatorial explosion of ALPN
identifiers-- if I thought we were identifying everything about the
protocol stack, etc. then I'd push for a structured identifier for ALPN
instead of the opaque tokens we currently have.
In fact, we may want to impose a minimal escape-hatch ALPN token
identifiers today to ensure that we can impose such in the future, i.e. if
we fail to anticipate how ALPN will be used in the future.
This could be as simple as saying that everything that doesn't begin with
'_' is unstructured), and thus indicate that tokens must not be registered
with '_'.


-=R




On Wed, Feb 26, 2014 at 7:49 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> I re-read this a few times and still don't grok. I think I'm missing
> something. Can someone point out the error in my understanding?
>
> Martin says the ALPN identifier should identify the full protocol stack.
> Why is this necessary? When you're doing ALPN, you know you're on TLS
> already. AFAICT, it looks like the reason that this is stated here is
> because Alt-Svc also uses ALPN tokens, and it wants to identify what
> protocol to use for the alternate service. In Alternate-Protocol, we don't
> use the same identifier as we did in NPN. We specifically used stuff like
> npn-spdy/2 or npn-spdy/3 (npn implies tls).
>
> I'm also confused why "h2t" is used to identify a TLS service that is
> willing to accept requests for http:// resources. Is that so we can
> discover it during the ALPN negotiation itself? Otherwise, I would think
> that discovery of http:// acceptance comes from the advertisement
> mechanism in Alt-Svc or DNS or whatever.
>
> Is the proposed redundancy in ALPN tokens there because we want to use the
> exact same token in Alt-Svc too?
>
> Just to be clear, my confusion and questioning is not disagreement. I'm
> simply trying to grok the discussion here.
>
> On Wed, Feb 26, 2014 at 5:14 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> On 26 Feb 2014, at 7:12 am, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>
>> > One of the proposals in Mark's Alt-Svc draft [1] is the creation of a
>> > new ALPN token "h2t" that is used to identify a TLS service that is
>> > willing to accept requests for http: resources.
>> >
>> > This made me think that perhaps we have this all backwards.  I think
>> > that we instead need an identifier for the cleartext variant of
>> > HTTP/2, and the identifier that Alt-Svc wants to use in this case
>> > already exists: "h2”.
>>
>> My intent was always to use one protocol identifier for TCP+HTTP/2, and
>> another for TCP+TLS+HTTP/2. The idea being that eventually you might have
>> identifiers for QUIC+HTTP/2 or TCP Minion + TLS + HTTP/2 or whatever as
>> well.
>>
>> So,
>>
>> HTTPS URI = always h2t
>> HTTP URI as we know it = h2
>> HTTP URI w/ TLS = h2t
>>
>> > It's much more consistent if ALPN identifiers are used to identify a
>> > protocol stack, top-to-bottom.
>>
>> Exactly.
>>
>> >  That means that "h2" identifies HTTP/2
>> > + TLS + TCP.  If we define "h2t" as Alt-Svc proposes, we change the
>> > meaning of ALPN identifiers to include the type of thing that the
>> > protocol carries.
>>
>> Er? The intent was to identify the stack, and constrain what stacks
>> different URI schemes could run on (especially HTTPS). That may have been
>> lost in rewrites, etc. but it’s always been the intent.
>>
>> > To make this a clean distinction, we have to stop using "h2" to also
>> > identify HTTP/2 + TCP (without TLS).  Instead, I propose that we use
>> > "h2t" for this.
>>
>> Backwards but yes in spirit.
>>
>> >
>> > It's also the case that I don't want to create a special case for
>> > http:// URIs here.  We've taken steps toward being able to carry other
>> > forms of URI in HTTP/2.  Singling http: out for special treatment as
>> > Alt-Svc proposes seems like a mistake.
>> >
>> > I'll note that this leaves HTTP/1.1 in a little bit of a bind.  ALPN
>> > defines "http/1.1".  That seems to be what people are using to
>> > identify HTTP/1.1 + TLS + TCP.  Maybe, just maybe, we can exploit the
>> > fact that this is lowercase in ALPN and uppercase in RFC 2817 and
>> > pretend that this isn't an issue.  "http/1.1" is HTTP/1.1 + TLS + TCP;
>> > "HTTP/1.1" is HTTP/1.1 + TCP.
>> >
>> > [1] http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03
>> >
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>