Re: Our ALPN protocol IDs

On 6/12/2013 3:40 p.m., Adrien de Croy wrote:
> 
> 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"
> 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
>>>


We do have the Connection Header magic which is transmitted on all
connections regardless of mechanism used to start the protocol. This
contains the "HTTP/2.0" moniker embeded, so it would seem we do already
have the version transmitted in some form already. It is just not
transmitted per-message like HTTP/1.

** all version 3.0 need do is change the magic

** version 2.x are supposed to be binary capable, so I would think these
are all limited to extensions adding new frames types and mechanism
semantics.

No train wreck or problems there. *provided* we get a clear consensus
and definition of what 2.0 proxies etc is to do with those
unknown/future frame types.

Amos