- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Mon, 3 Feb 1997 18:06:27 PST
- To: ejw@ics.uci.edu
- CC: w3c-dist-auth@w3.org, marc@ckm.ucsf.edu
The problem really is that "method specific content type" is contrary to the spirit and practice of MIME. Content types were intended not as an arbitrary type space, but as a specific method for determining the appropriate DISPLAY method for a package of data. If you want to send arbitrary data packaged up, you might as well use ASN.1 and BER. I think that the "design group" got itself into a bind by taking the rough sentiment of the Palo Alto meeting without letting the group interact about the consequences of that design. # 1. In the URL, via munging (e.g., http://foo.bar.com/junk.html?type=exlusive_write) Part of the reason you've gotten to this place is by having interfaces with too many parameters. Why should the client have to decide ahead of time whether a call is "exclusive write"? # 2. In headers, which often end up being method-specific (such as LockEntry, # which if used as a header would have limited applicability outside LOCK and # CHECKOUT). Why are lock entries different from entity tags? # 3. In the message body. In this category, we had the choices of a) using # the same content type for all methods (e.g., application/davparams) or b) # having method-specific content types. Or multipart/form-data or even application/x-url-encoded. As long as you're pursuing the tack of doing a general purpose distributed object protocol, and the question is "how do you hide this in HTTP", you'll wind up solving a problem that is much more general than you needed to solve, and with much more serious entailments. Larry
Received on Monday, 3 February 1997 22:07:06 UTC