W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

Re: app/foo and app/fooresult

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
Message-Id: <97Feb3.190627pdt."241"@palimpsest.parc.xerox.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT