Re: alpn identifiers (not again!)

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

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.

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:

* <???>
* "h2c"
* "http/1.1"
* "h2"

Note that the tokens don't exactly define a "protocol stack", so much as:
the distinction between 'real' tokens and 'reserved indefinitely' shadow
tokens allows us to infer one extra layer below the identified protocol
(i.e. TLS, or not). As long as the stacks we want to identify only go as
deep as TLS/TCP, the stars remain aligned, and the registry exactly serves
our purposes.

Actually at this point I should be clear with what I'm saying: I'm only
considering protocol stacks looking downwards. Nothing stops the tokens
from identifying stacks that go *up* from TLS. For example, someone could
mint a token for "foobar-over-websockets-over-h2". Is that one of the
problems people are having? (That, by creating that token, proxies that are
happy with websockets-over-h2 have to learn a new magic word to know that
this also counts?)

Looking down again: if, in the future, we de-ossify the web and are able to
introduce a new lower-level protocol and use that to carry HTTP (is that
QUIC?), we'll have to add new tokens to the ALPN shadow registry (no big
deal?), but we'll also have to be sure to remember that "not TLS" in that
registry no longer necessarily just means "TCP".

I think that just means we're expanding the definition of the registry. I
don't know if that counts as a layering violation.

Have I missed anything?
Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/