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

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