Re: alpn identifiers (not again!)

Some responses inline...


On 11/06/2015 2:30 p.m., Matthew Kerwin wrote:
> On 11 June 2015 at 10:11, Adrien de Croy <adrien@qbik.com> wrote:
> 
>>
>> We shouldn't have to change TCP to put HTTP over it.  We didn't change
>> HTTP to put it over TLS over TCP
>>
>>
> ​Not the protocol part of HTTP, but the identification part certainly
> changed. (By minting the "https" URI scheme.)

I've been thinking in the last few days that the problem may be that
there was never an "https" ALPN token minted to match it. At the time it
seemed okay since there was also never a HTTPS protocol name and nobody
hit problems. Now not so much.

This draft is possibly not the right place to do that minting, or maybe
it is.


> 
> I've written three drafts of this email, trying to keep it on-point, but
> I'm having trouble working out exactly what problem is being discussed.
> Here's my summary:
> 
> 
> In places like HTTP Upgrade or Alt-Svc, I think the alternative service
> types are:
> 
> * HTTP/1.x over TCP,
> * HTTP2 over TCP, or
> * TLS over TCP.

* SPDY/.. over TLS

(adding SPDY to the mix since it has ALPN registered to make it a little
more obvious later where the odd-one-out is).

>
> Here I use "TLS" to mean: open a TLS connection, if you both support ALPN
> do that dance, otherwise it's old-school https
> 
> Since "TLS" isn't particularly informative (e.g if you care about the
> differences between HTTP/1.1 and h2 transports), it would be nice to
> further describe what gets carried within that TLS pipe. I.e. we're
> identifying a protocol stack. So, you can enrich the options to:
> 
> * HTTP/1.x over TCP,
> * HTTP2 over TCP,
> * HTTP/1.x over TLS over TCP,
> * HTTP2 over TLS over TCP.

* HTTP/1 over SPDY/1 over TLS over TCP
* HTTP/1 over SPDY/2 over TLS over TCP
* HTTP/1 over SPDY/3 over TLS over TCP

> 
> Since the ALPN registry contains tokens for protocols carried within TLS,
> and has a "shadow registry" of tokens that cannot be registered because
> they apply to things that are never in TLS (like 'h2c'), we can write the
> list as:
> 

RFC 7301 did not specify non-TLS usage for these tokens. The initial
seeded registrations just got a reference to the protocol being used
over-TLS irregardless of whether it existed *only* over TLS or not.

The SPDY documents exlicitly forbid over-TCP usage. So we can make clean
assumptions there.

RFC 7230 defines two usages for over-TCP and over-TLS. Making RFC 7301
imply by omission that there is one ALPN token for both.

RFC 7540 defines the same, but with clear ALPN distinction between
over-TCP and over-TLS.

Leading to the list actually being this:

* "http/1.1"
* "h2c"
* "http/1.1"
* "h2"
* "spdy/1"
* "spdy/2"
* "spdy/3"

Spot the oddity.

And that is where a big part of the problem lies today. IMHO, what
happens in future tokens is secondary so long as it does not re-add this
problem.

Amos

Received on Friday, 12 June 2015 00:00:44 UTC