Re: Our ALPN protocol IDs

I'd still advertise the highest supported version.  The receiver can 
then at least decide what to do.

Any protocol I ever had the misfortune to work with that didn't have a 
version field was a train wreck when it came to extending or changing 
it.




------ Original Message ------
From: "Patrick McManus" <mcmanus@ducksong.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>; "Carsten Bormann" 
<cabo@tzi.org>; "Mark Nottingham" <mnot@mnot.net>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 6/12/2013 3:36:28 p.m.
Subject: Re: Our ALPN protocol IDs
>there is no requirement on which peer sends first, so there really 
>can't be a handshake even as part of the initial settings and/or magic 
>bits.. an upgrade of a running session perhaps, but not a negotiation. 
>*PN ftw.
>
>
>On Thu, Dec 5, 2013 at 9:26 PM, Adrien de Croy <adrien@qbik.com> wrote:
>>
>>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).
>>>
>>
>>
>