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