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