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

The version string in SPDY frames was never successfully used (and can be
considered a failed part of that protocol).
The initial idea was that a proxy may have clients with two different
versions and that it could simply forward them onwards.
In practice, this didn't happen-- it was cheaper to have another connection
for the different version, or to simply upgrade for the next hop.

Some kind of up-front version negotiation (thusfar NPN or
Alternate-Protocol) has been sufficient for all versioning thusfar in SPDY.

-=R


On Tue, Dec 11, 2012 at 11:23 PM, Amos Jeffries <squid3@treenet.co.nz>wrote:

> 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<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
>
>