Re: alpn identifiers (not again!)

The confusion is maybe in my head. I read an alt-svc with "h2c" as an advertisement that a client may connect via tcp, talk http in order to upgrade to h2. (or, outside the spec but implemented by many, as directly sending the PRIamble and switch to h2 that way.)

Similar "h2" in alt-svc seems to be the same with the addition of TLS in the stack and an additional way, ALPN, to upgrade.

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



> Am 09.06.2015 um 19:05 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
>> On 9 June 2015 at 02:44, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>> schemes are needed.
> 
> This is the part I'm not convinced of.  I think that it might be more
> harmful in fact, but I'm not sure that I completely follow your logic.
> 
>> URI schemes denote protocol stacks.
> 
> This is something I disagree with, so maybe that's where we have a
> disconnect.  URIs with a https scheme clearly do not describe a
> protocol stack.
>

Received on Tuesday, 9 June 2015 17:40:06 UTC