app/foo and app/fooresult


Couldn't make the mtg in Irvine, but I have a question about draft-0.6.

Is there a rationale for defining complementary MIME types for requests and
responses to a method besides the ability to unambiguously determine the nature
of the message out of context?  Are you that much more likely to retain the C-T
header than the HTTP request/response line?

If a lock request is in the form of:

LOCK foo HTTP/1.x
Content-Type: application/lock

[lock request entity]

and the response is in the form of:

HTTP/1.x 20x OK
Content-Type: application/lockresult

[lock response body]

The main reason that I can see for creating MIME types for request and reponse
is that you are missing the HTTP request or status lines but manage to keep the
Content-Type header value around.  Contrast this to the message/http content
type that doesn't need to a separate IMT for the request and reponse as its
form is unambiguous.