Best practices for defining custom mime-types

I'm working on a draft specification that eventually I would like to submit to the IETF. This spec defines a web service, that largely operates using xml over HTTP.

One point that came up, was the usage of mime-types. A common way of doing things is to just use:

 application/xml

There's benefits to defining new mimetypes though, as it will allow for content-negotation using the Accept header.

So there's a clearly defined benefit for doing this for resources that would be fetched using GET.

This benefit doesn't really exist as much for POST requests (we'll have a few of these too). The argument that is being made, is that we should just use application/xml for all our RPC-style POST operations, because if there are alternative xml bodies being sent, the server should be able to figure out what the intent of the message is, by looking at the root xml element.

Completely fictional example:

POST /endpoint
Content-Type: application/xml

<?xml version="1.0"?>
<publish xmlns="urn:our-specification" />

Later on we may add a:

POST /endpoint
Content-Type: application/xml

<?xml version="1.0"?>
<hide xmlns="urn:some-future-spec" />

The combination of the local element name and the xml namespace should be enough to figure out the intent, so the argument is that custom mimetypes for this are kind of pointless.

I intuitively feel that always defining custom mimetypes for any type of operation is a good idea, but don't have a strong enough argument to make... so I'm curious if there's anyone who has something to contribute.

Also, if we do define a custom mimetype... should it be the the same mimetype for any xml body / operation we define, or should we define a custom mime-type per operation?

Curious if there's people here with past experiences.