W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: RE-VERSION

From: John Franks <john@math.nwu.edu>
Date: Sun, 10 Aug 1997 11:15:52 -0500 (CDT)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.96.970810105701.6439A-100000@hopf.math.nwu.edu>

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

 <snip>

> 
> >  4) It has no  discernible function.

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

When the version number is really representing the "capability of the
server" and is not equal to the version of the response, I have yet to
see a concrete example of how it might be used, if neither client nor
server is buggy and RFC 2145 is complied with.

I would like to hear of a SINGLE hypothetical or real example of how
the response version header can be used when it is really representing
"capability of the sender", that is, when the minor version number of
the response is strictly greater than the minor version number of the
request (so the response is of a version lower than the server is
capable).  Such an example should assume any clients, servers and
proxies involved are not buggy and are unconditionally compliant with
RFC 2145.

It is because I know of no such examples that I claimed that making
the version header of a response represent capability rather 
than the version of the response has "no discernible function."
I am ready to withdraw that statement if someone can provide examples
of the functionality of a "capability" semantics.


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Sunday, 10 August 1997 09:16:53 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:51 EDT