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

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.

Received on Tuesday, 11 December 2012 00:32:11 UTC