- From: Scott Lawrence <lawrence@agranat.com>
- Date: Sat, 09 Aug 1997 21:56:19 -0400
- To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
>>>>> "JF" == John Franks <john@math.nwu.edu> writes: JF> The version number design which you have promulgated since 1993 gets JF> rehashed every six months because: JF> 1) It is counterintuitive to the point of being confusing, That is a particularly subjective statement. I find the version numbering rules as they stand now to be so obvious and intuitive that they hardly need discussion at all. Reasonable people differ, but in this case the 'intuitive'ness is not (IMHO) a usefull criteria. JF> It is specious to say that a 1.1 proxy can send a 1.0 version number JF> because then it becomes a 1.0 proxy. What is really happening is that JF> the proxy is lying in its version header because that is the only way JF> it can request the response it wants from the server. I fail to see the problem - if it wants a 1.0 response, it can send a 1.0 request; if it wants a 1.1 response it can send a 1.1 request. JF> The reason that the version header comes up again and again is not JF> that difficult to understand. What implementors NEED to know in JF> processing a transaction is the *version of that entity*, i.e. the JF> lowest version number such that a client or proxy of that version can JF> handle this entity. The current version header gives only an upper JF> bound estimate for this number. It is a non-trivial (and potentially JF> error-prone) task to calculate this entity version. If versions 1.x JF> with x > 1 come into being this problem will get harder. This is simply not true by the specification - the responder is required to send a response which may be correctly interpreted by an implementation of the protocol version _in the request_. The requestor need not use the version number in the response for _anything_; it knows what version it requested and can interpret the response by those rules. JF> Apparently the original design intent was that the major version JF> number would be the "entity version" and the minor number would JF> indicate capability. This is manifestly no longer the case. The intent was plainly nothing of the kind, as has been spelled out in this forum and various IETF documents repeatedly. JF> There is substantial evidence that new implementors *expect* the JF> version header of a response to contain the entity version (which they JF> need and which the origin server knows) rather than a statement of JF> capability. When they discover this is not the case (either by JF> reading the spec or when something breaks) they are annoyed by the JF> extra work, seemingly gratuitously created for them, and they come JF> here to complain. This is unlikely to change anytime soon. It is true that we cannot protect ourselves from the complaints of developers who do not read the specification before they write thier bugs. That is no reason to change anything at all. JF> The bottom line, though, is that there are three pieces of version JF> information related to an HTTP transaction: 1) the capability version JF> of the sender, 2) the entity version of the transaction, and, for JF> requests, 3) the requested version of the response. There is no such thing as the 'entity version of the response' and there is no need for any. -- Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Saturday, 9 August 1997 19:00:44 UTC