Re: RE-VERSION

Roy, 

The version number design which you have promulgated since 1993 gets
rehashed every six months because:

  1) It is counterintuitive to the point of being confusing,
  2) It is flawed,
  3) It greatly complicates some kinds of proxy design, and 
  4) It has no  discernible function.

We can probably live with these problems, but one price we will pay
is that this aspect of the protocol will get rehashed at least every
six months as new people wrestle with what ought to be a trivial part
of the protocol.

On Sat, 9 Aug 1997, Roy T. Fielding wrote:

> John Franks wrote
> 
> > This is because hop-by-hop implies a
> > 1.m proxy talking to a 1.m server can only ask for a response with 
> > EV == 1.m, even though it may acting on behalf of a 1.n client with
> > n < m.
> 
> Yes, that is the cost of progress.  In order to take advantage of more
> advanced protocol features, a proxy must make up for its weaker clients.
> There is no way around it.  In fact, that should be considered a valuable
> feature by anyone who purchases a proxy.
> 

But later you say the opposite:
> 
> In general, there is no requirement that a client (including a proxy)
> send a 1.1 request instead of 1.0.  There can't be, since then the
> client would be using the 1.0 protocol and not HTTP/1.1.  Thus, the
> concern you mention is unfounded.
> 

It is specious to say that a 1.1 proxy can send a 1.0 version number
because then it becomes a 1.0 proxy.  What is really happening is that
the proxy is lying in its version header because that is the only way
it can request the response it wants from the server.  This is one
example of a flaw in the version header design: a proxy may sometimes
need to lie about its capabilities in order to get the response it
wants.

The reason that the version header comes up again and again is not
that difficult to understand.  What implementors NEED to know in
processing a transaction is the *version of that entity*, i.e. the
lowest version number such that a client or proxy of that version can
handle this entity.  The current version header gives only an upper
bound estimate for this number. It is a non-trivial (and potentially
error-prone) task to calculate this entity version.  If versions 1.x
with x > 1 come into being this problem will get harder.

Apparently the original design intent was that the major version
number would be the "entity version" and the minor number would
indicate capability.  This is manifestly no longer the case.

There is substantial evidence that new implementors *expect* the
version header of a response to contain the entity version (which they
need and which the origin server knows) rather than a statement of
capability.  When they discover this is not the case (either by
reading the spec or when something breaks) they are annoyed by the
extra work, seemingly gratuitously created for them, and they come
here to complain.  This is unlikely to change anytime soon.

I do not believe that statements like "this is the cost of progress"
or "this is the way we have done it since 1993" are responsive.  The
fact that the archive is full of such statements does not constitute
a resolution of the issue.

On the other hand RFC 2145 by Mogul et al. was a big step forward, in
that it at least specified precisely what the current spec says.

The bottom line, though, is that there are three pieces of version
information related to an HTTP transaction: 1) the capability version
of the sender, 2) the entity version of the transaction, and, for
requests, 3) the requested version of the response.  We have specified
that the capability version goes in the header, but it is actually the
other two which are required for interoperability.  Often, but not
always, some of the numbers coincide.  Often, but not always, it is
possible to derive all three numbers from the collection of all
headers.  However, even when this is possible, there is no simple
algorithm for doing so.  Even RFC 2145 suggests that in certain,
(perhaps exceptional) circumstances clients and servers can lie about
their capabilities and send an incorrect version header.  Though it is
not explained, the purpose is presumably to correctly communicate the
entity or request version when the correspondent will otherwise compute
them incorrectly.

The current specification is workable, but problematic.  All the
issues mentioned above have, indeed, been raised before and are in
the archives.  Emphatically denying their existence may temporarily
silence the topic on the mailing list, but doesn't help implementors.
The fact that the issue gets rehashed every six months might be taken
as prima facie evidence that the design could be improved.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Saturday, 9 August 1997 11:36:41 UTC