Re: alpn identifiers (not again!)

On 12 June 2015 at 09:59, Amos Jeffries <squid3@treenet.co.nz> wrote:

> 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.
>
>
​Is that not what "http/1.1" is? Note that in my ​final list of tokens, I
left "HTTP/1.x over TCP" as "<???>" because, as I read it, there is no
token for that. That's the one we'd need to mint, if people want it, *not*
the HTTPS one.

​​

>
> 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.
>
>
Yes, the registry only identifies protocols negotiated/carried inside TLS.
Therefore everything in the registry is inside the TLS stack.​



> ​<...>​
>
>
> 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.
>
>
​Actually I can't find any definitions of the "http/1.1" token except in
7301. Since the initial registry, as defined by RFC 7301, only contains
in-TLS protocols, the only implication is that the "http/1.1" token means
"HTTP/1.1 over TLS". "HTTP/1.1 over TCP" remains unspecified.



> 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.
>
>
​I write that list differently:

* <???>
* "h2c"
* "http/1.1"
* ..etc



> 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.
>
>
I think the problem is, of course, manyfold but boils down to two key
things:

1. The registry includes an entry for "HTTP/2 over TLS", which seems to
imply that any row that doesn't say "over X" means "over anything", instead
of "over TLS." (If the H2 entries were "HTTP/2" and "reserved" I think
there'd be less confusion.)

2. We're missing an equivalent 'reserved' token slot for "HTTP/1.1 over TCP"

That second point is easy to solve, and would allow us to move forward,
yeah? Assuming we actually need that token?

The confusion could be cleared up in a number of ways, which would reduce
the likelihood of future problems. (An informational RFC, a new column in
the registry table, maybe even just renaming the existing entries...)

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/