Re: RE-VERSION

My previous response to this thread may have been a little too
flip.  There is a serious issue here which has been discussed
before but maybe not really resolved.  It deserves our attention.

There are two distinct pieces of information that might be
communicated by a version header.  First there is the SENDER VERSION
(SV) which is the highest version the sender is capable of supporting.
Second there is the ENTITY VERSION (EV) which is the lowest version
for which a receiver supporting only that version can still
successfully receive the entity.  Of course EV <= SV.

With the current spec the version header is hop-by-hop so the receiver
of a transaction can compute EV = min { SV(sender), SV(receiver)}.
This complicates life for proxies, though.  It means that a 1.m proxy
must be capable of translating an entity with EV == 1.m to an entity
with EV == 1.n for all n <= m.  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.

This seems to put a heavy burden on proxies.  The current spec precudes
the possibility of a proxy pushing this burden onto the server where
it would be easier to deal with (in general it will be easier to
*generate* an entity with EV == 1.n for all n <= m than it is to
*translate* an entity from EV == 1.k to EV == 1.j for all j <= k <= m).

Of course, at present we only have versions 1.0 and 1.1 so the proxy
need only be able to translate an entity with EV == 1.1 to one with EV
== 1.0.  This requires removing any chunking, but Josh Cohen asks if
it requires anything else.  I don't know.  We need to understand and
document exactly what is required for this translation.

A concern that I have is that, if the version header is hop-by-hop and
must contain SV, then we have precluded a proxy design that would
allow a proxy to request a lower EV than its SV.  There are many
reasons a proxy might want to do this including separate caching of
versions with different EV's instead of translating.

This discussion is relevant even for HTTP/1.1.  A 1.1 proxy between a
1.0 client and a 1.1 server will always have to unchunk the server's
response even if it is uncacheable and just being passed through.
There is no real reason for requiring the proxy to accept this burden
and refusing to let it request an unchunked version from the server if
it knows it needs one.

It seems to me that one way to remedy this is to somehow communicate
(up to) three version numbers: The SV of the sender, the EV of the
current transaction, and, for requests, an RV or Requested Version to
be used in the response.  It would also be reasonable so say that
the EV of a request is the requested version for the response and
that would simplify things somewhat.


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

Received on Friday, 8 August 1997 08:31:54 UTC