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

I think you may be conflating scheme and protocol, which are possibly
different?

-=R
On Feb 26, 2014 3:42 AM, "Salvatore Loreto" <salvatore.loreto@ericsson.com>
wrote:

>
> On Feb 25, 2014, at 9:12 PM, 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".
> >
> > It's much more consistent if ALPN identifiers are used to identify a
> > protocol stack, top-to-bottom.  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.
>
>
> I don't see why you think the meaning of ALPN identifier is changing with
> this proposal.
>
> ALPN is a mechanism to negotiate between client and server
> when multiple application protocols are supported over a single
> server-side port number (i.e. 443 port).
>
> Nowadays (i.e. in HTTP/1.1) http:// is over port 80, while https:// is
> over port 443
> therefore are then "two" application protocols transported over two
> different ports,
> and so we need to have two different ALPN tokens.
>
>
>
> >
> > 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.
> >
> > 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
> >
>
>
>