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). >> >> > >
Received on Friday, 6 December 2013 02:36:57 UTC