Re: app/foo and app/fooresult

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