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

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Dec 2012 16:31:42 -0800

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.

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 can see how, if we were to use DNS RRs, it might become
operationally unwieldy to rely solely on the primary label for minor
changes that need to be signaled using version numbers.  SPDY still
defines a version field, which can be used for this if it becomes
clear that it is necessary; if not, the bits can be recycled.  I'm
sure we can find a use for a couple of bits.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Dec 2012 11:28:22 +0100

On 2012-12-11 01:31, Martin Thomson wrote:
> ...

Sounds good to me!

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 12 Dec 2012 20:23:26 +1300

> maintain a version number manually, though this might become necessary

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

> 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

---

From: Roberto Peon <[email-masked]>
Date: Tue, 11 Dec 2012 23:38:35 -0800

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 <[email-masked]>wrote:

>> http://tools.ietf.org/html/**rfc2616#section-3.1<http://tools.ietf.org/html/rfc2616#section-3.1>intentionally.  This is
> Agreed. Sounds good. Also helps to prevents the software checking only for
> "HTTP/1." doing just "HTTP/2." instead of the full version.
>
>
> 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
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2012 14:36:13 -0800

> Alternate-Protocol) has been sufficient for all versioning thusfar in SPDY.

This is useful information.  I'm not proposing that we close the door
entirely on forward compatibility features in-protocol, just that we
don't have a clear enough story yet.  I don't find "might want to make
progressive improvements" to be compelling enough to justify the
bit-expenditure.  For instance, new features that rely on new message
types could operate happily just using the extension points we
establish for message types.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 12 Dec 2012 15:10:05 -0800

yup.
-=R