- 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>
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 UTC