W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: Title (and Identifier) for final and in-progress versions of HTTP version 2

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 12 Dec 2012 20:23:26 +1300
Message-ID: <50C830EE.2060104@treenet.co.nz>
To: ietf-http-wg@w3.org
On 11/12/2012 1:31 p.m., Martin Thomson wrote:
> I think that there has been clear consensus that this protocol will be
> identified as a new major version of HTTP.  To that end, it seems
> likely that the *final* identifier for the new version will be:
> "HTTP/2.0".
>
> This is compatible with the grammar defined in RFC2616.
>
> A number of questions arise:
>
> 1. In the meantime,
>      a. what do we call the protocol in specifications?
>      b. how do we identify draft or experimental versions?
> 2. Is there a need to identify the protocol version in this way in the
> optimized binary protocol?
>
> These are the answers I would like to proceed with, but it would be
> good to hear objections if there are any:
>
> 1a. the protocol can be labelled as "HTTP/2.0" in specifications, as
> long as it is clear that this is a title, not a protocol label (yet).
>
> 1b. I'd like to propose that we identity draft/experimental versions
> using: "HTTP-01/2.0", "HTTP-02/2.0" etc... where the number identifies
> the draft revision that it is based on.  Experiments based on
> individual drafts can add another -suffix, like "HTTP-01-sctp/2.0".
>
> This is not compatible with the grammar in
> http://tools.ietf.org/html/rfc2616#section-3.1 intentionally.  This is
> not HTTP.  Yet.  It's a completely different protocol until we're
> done.
>
> Note: the websockets approach of having a version header wont work for
> NPN, DNS RR, and other places.  I would also prefer not to have to
> maintain a version number manually, though this might become necessary
> as we near publication.

Agreed. Sounds good. Also helps to prevents the software checking only 
for "HTTP/1." doing just "HTTP/2." instead of the full version.

> 2. I don't believe that we need to identify versions in the binary
> protocol.  The jump to the version requires the protocol identifier;
> the target protocol does not need further version negotiation.
> Whether that be in the Upgrade header, NPN, DNS RR, or elsewhere, the
> protocol version label is present in every upgrade.

I disagree. There is very likely to be progressive feature developments 
in the binary protocol just as there were in the ASCII protocol. Which 
in turn means a jump to some additional version. _somehow_.

I agree though, the old form of tag "HTTP/2.0" is not appropriate to 
keep. But some equivalent replacement is just as useful.


Amos
Received on Wednesday, 12 December 2012 07:23:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 December 2012 07:24:01 GMT