application/xml+rpc

[Mario Salzer]

MIME media type name:                application
MIME subtype name:                   xml+rpc
Required parameters:                 -
Optional parameters:                 -
Encoding considerations:             -
Security considerations:             -
Interoperability considerations:     existing apps needed little changing
Published specification:             http://www.xmlrpc.com/spec
Applications which use this media type:  XML-RPC (various implementations)
Additional information:
  Magic number(s):                   -
  File extension(s):                 -
  Macintosh File Type Code(s):       -
Intended usage:                      COMMON USE

#

Hi, I have no idea on how such a request should look ([2048] didn't help
much), so here just comes the what and why:

I'd like to have the MIME type "application/xml+rpc" registered for use
with the XML-RPC (XML-RemoteProcedureCalls) protocol as defined by UserLand
[http://www.xmlrpc.com/]. That specification currently uses "text/xml" as
the MIME type for transportation the encapsulated cross server application
calls over HTTP[2616]. This is what such a message (until now) looks:

   POST /cgi-bin/xml-rpc.cgi HTTP/1.1
   Host: www.example.com
   User-Agent: some_xml-rpc_software
   Content-Length: 244
   Content-Type: text/xml

   <?xml version="1.0"?>
   <methodCall>
      <methodName>whateverFuntion</methodName>
      <params>
         <param><value><string>I'm the first parameter</string></value></param>
         <param><value><int>2</int></value></param>
      </params>
   </methodCall>
   
So the protocol uses "text/xml" currently. I think this is totally wrong and
an abuse of that MIME type, because XML-RPC (despite its name) is not based
upon XML as defined by the w3c.
The XML-RPC specification instead introduced a lightweight __XML-like__
markup, which differs from XML in that there is no DTD for it, no namespaces
are allowed, and even tag attributes must be absent. This is what commonly
is referred to as "Simplified XML" or so (the Jabber proto also uses such
one I think).

The fact that the first line of every XML-RPC message now contains <?xml
version="1.0"?> only arised from that most implementations are using a full
fledged XML parser to process the messages. However implementations can go
without and use a far simpler parser, because of the restricted structure of
XML-RPC messages.
So my main concern for requesting a MIME type for this protocol on its own
is, that "text/xml" is blatantly wrong here, even if it looks alike.

Reasons for a MIME type on its own:
- XML-RPC is not a file format, it misses a file extension and is rarely 
  saved to disk (= not at all)
- eventually there is little confusion for web servers receiving a text/xml
  message, but "application/xml+rpc" would certainly clearify which handler
  should take care of it, and thus the messages wouldn't end up in an
  unprepared CGI script because of URL misspellings
- there is even no DTD, so distinguishing it from other (real-)XML
  applications is nearly impossible by other means than first running a
  parser on it (and knowing/detecting the message structure of course)
- one could safely say, that XML-RPC is widely used and adopted (if this
  is a point for allowing a separate MIME type)

Reasons for the "application/" tree:
- while "text/xml" files are to be edited by humans, XML-RPC messages are
  not - they only exist temporarily as application glue, and even if people
  could write requests in an editor, this is not what commonly happens;
  hence the application/
- the messages are no text representations, but really just application and
  function call syntax

Reasons for the "/xml+rpc" subtype:
- despite [3023] paragraph 1 and section 7, I believe it was ok to not
  use the "+xml" postfix this time, because the term "XML-RPC" is the 
  protocol name and "/xml+rpc" would sound only little different
  (wouldn't this allow for an exception from the rule?)
- it would ease adoption of a new MIME type, if it sounded familar
- XML applications may not even want to work with XML-RPC messages, so it
  is not necessary to go with the standard "+xml" postfix
- "/xml-rpc" may not be a possible MIME sub type, because of the trademark
  issue ("XML-RPC" being a registered one)

Additional (asorted) notes:
- there should be no charset= attribute to that MIME type, the XML-RPC spec
  is about keeping it simple, and letting such "minor" details be handled
  by the actual web service API specification and implementation
- existing XML-RPC impl. need little tweaking and can signalise other
  applications to use this eventual new MIME type by means of the Accept:
  response/request header [2295]
  (this means a transition phase for XML-RPC, but not necessarily / unlikely
  interoparability problems)
- XML-RPC currently only operates on HTTP, so no need to take Mail protos
  into account
- security seems no issue for requesting this MIME type - at best handled
  at HTTP level (Basic Auth or Cookies)


Best regards,
mario