Re: alpn identifiers (not again!)

I think that you've summarized the situation well.  At least from my
perspective.

As for x-over-thing-we-already-know-about, that's a tough deal, and I
suspect that if we take this seriously, we need to consider whether
that gets a token or not.  That proxies will be affected is now a
consideration that needs to play into that.

Websockets was a good choice of example by the way.  Websocket
"sub-protocols", such as they are, aren't especially interesting
currently, and I wouldn't consider it worth adding new tokens for that
purpose.  But who can say if new uses of websockets might turn out to
be interesting.

On 10 June 2015 at 19:30, Matthew Kerwin <matthew@kerwin.net.au> 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 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/

Received on Thursday, 11 June 2015 02:44:21 UTC