Re: Our ALPN protocol IDs

right, so if we decide that HTTP/2.0 won't be forced to go over TLS, 
then we can't rely on ALPN even being there.

At that point it would be problematic to assume a mapping between port 
and version.  Much easier and more deterministic to put a version field 
back into (at least) the initial message(s).

Adrien


------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Carsten Bormann" <cabo@tzi.org>; "Mark Nottingham" <mnot@mnot.net>; 
"HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 6/12/2013 1:27:17 p.m.
Subject: Re: Our ALPN protocol IDs
>On 5 December 2013 15:31, Adrien de Croy <adrien@qbik.com> wrote:
>>
>>  is there no version transmitted anywhere (outside of ALPN).... or are 
>>we
>>  going to rely on ALPN to communicate that?
>
>ALPN carries all the important and relevant version information, yes.
>
>Version information is all carried in the identifier string (currently
>"HTTP/2.0"). This same identifier is used in ALPN and Upgrade (and
>Alt-Svc and DNS and whatever other places we choose to signal support
>of HTTP/2.0).
>
>Note that this is all outside of the protocol, and is always required
>to be present, though we acknowledge that the presence of the
>identifier might be implicit (as it would be in the port 100
>proposal).
>

Received on Friday, 6 December 2013 02:27:11 UTC