Re: alpn identifiers (not again!)

> Am 10.06.2015 um 00:08 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
> On 9 June 2015 at 10:39, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>> Now, if I want to advertise that clients may connect via DTLS or maybe ssh to an endpoint that talks h2 (or h1 with upgrade), one would need a new ALPN identifier. Ok. But that id will never be meaningful in ALPN.
> 
> Right.  Though it might be used in ALPN.  Say that HTTP/3 runs over
> DTLS.  That does ALPN.

There is what I do not understand. If we ever make HTTP/2 work over DTLS, we would - in the current Alt-Svc spec - need a new ALPN identifier for that. So that a server can advertise this like:

  Alt-Svc: h2dtls=":443"

The server may offer ALPN with DTLS and what will the client send? "h2". Never will "h2dtls" be send as a protocol identifier over ALPN. Because "h2dtls" is not a single protocol but a stack.

  Alt-Svc: dtls.h2=":443", tls.h2=":443", ssh.h2=":1234", tcp.h2=":80"

If Alt-Svc would allow for a hierarchical notation, it would allow for a mix of a smaller set of identifiers that more readably state what they mean. (IMHO, etc.)

> Or maybe there is a new protocol that decides to negotiate protocols
> using exactly the same mechanism and identifiers as ALPN, just not in
> TLS.  Is that ALPN?
> 
>> That gives me the feeling that something is not right.
>> All that is specified will work. I am just looking for a way to do this better.
> 
> Sure.  I understand.  Sometimes, to make a specification, you have to
> break some abstractions.

Yes, but you need to make a case for it. Currently, I do not see that.

mod_h2 needs, to be fully compliant, to make checks that "h2" and "h2c" are used on the correct connections (have TLS or not) and some code paths are not supposed to work in some combinations. This ties the h2 code to exactly the two cases defined in the specification. Should *ever* someone use a secure connection protected by something other than TLS, these parts need to be rewritten. There is a price to breaking abstractions.

Cheers,

  Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Wednesday, 10 June 2015 09:41:10 UTC