- From: Jim Seidman <jim@rafiki.spyglass.com>
- Date: Tue, 5 Sep 1995 14:30:58 -0500
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: fielding@beach.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 11:32 AM 9/5/95 PDT, Larry Masinter wrote: >Suppose that the definition of application/foobar is such that both >client and server recognize that anything that is >application/foobar;version=2.x is also application/foobar;version=2.y >for y<x. Then you can just accept 2.5 and leave the others implied. How would something like this be defined? Is backwards-compatibility between versions something that goes into the IANA registry when the MIME type is registered? Also, a definition such as you describe only helps if that backwards-compatibility is made clear when application/foobar;version=2.0 comes out. If you wait until application/foobar;version=2.1 is available, then an older server wouldn't know that it could send a version=2.0 response to a version=2.1 request. Clients would then have to request version 2.0 anyway. IMHO, relying on servers to parse and interpret these media parameters is a very un-robust way of going about this anyway. Hard-coding the MIME-types which have backwards compatibility defined for them is a poor solution, and expecting users to correctly configure this information (e.g. text/html;version=2.0 can be returned for text/html;version=2.1 or text/html;version=2.2, etc.) is unreasonable. -- Jim Seidman, Senior Software Engineer Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563
Received on Tuesday, 5 September 1995 12:33:38 UTC