Hello Mario, Some comments below. At 09:38 04/01/12 +0100, Mario Salzer wrote:
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),
The best thing is to look at some of the RFCs that have registered types, and the various type registrations. You can find all of them from the registry.
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.
Can you explain that? The above looks like perfectly well-formed XML to me. Where are there differences? And if it's not XML, it shouldn't be called XML.
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).
Ah, so it's still XML, but not all XML would work for xml-rpc.
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.
It's definitely wrong in that xml-rpc is far away from what people consider suitable for a text subtype, and also because text/xml is considered unadvisable in general these days.
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)
All very good points.
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
Very much to the point. I'd even say it goes without saying :-).
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)
I think the type name should either be application/xml-rpc+xml, or application/rpc+xml, or application/rpc-xml. Using the + for anything other than new generic suffixes (we currently only have +xml, and I don't see any new ones, but nevertheless) seems to be bad idea. The hyphen is available, and would be even closer to the original name. Using +xml is still a good idea. Some XML applications may not want to look at this type, but other XML applications *may* want to look at, and they will not have any troubles doing so. (an XML parser without any problems can parse an XML document without a DTD, without namespaces, and without attributes). Regarding the trademark, I'm not sure this is an issue. After all, we would just use "xml-rpc" to denote "xml-rpc". That's similar to using it in a newspaper article, or so. As far as I know (I'm not a lawer, of course), trademark law doesn't forbid anybody to use the trademark, it only forbids/restricts to use the trademark to denote other things than what the trademark is registered for. An example in case might be application/postscript, which is defined in RFC 2046, with the following text:
4.5.2. PostScript Subtype
A media type of "application/postscript" indicates a PostScript program. Currently two variants of the PostScript language are allowed; the original level 1 variant is described in [POSTSCRIPT] and the more recent level 2 variant is described in [POSTSCRIPT2]. PostScript is a registered trademark of Adobe Systems, Inc. Use of the MIME media type "application/postscript" implies recognition of that trademark and all the rights it entails. ...
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
I'm not sure I understand this. How can the question of whether something is ASCII, EBCDIC, or UTF-16 be a minor detail?
- 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
What do you mean by "Mail protos"?
- security seems no issue for requesting this MIME type - at best handled at HTTP level (Basic Auth or Cookies)
Please read a few of the security sections in existing MIME type registrations. You should see that security is very much an issue, and you need to write a good security section. Regards, Martin. P.S.: ietf-types@alvestrand.no and ietf-types@iana.org are the same list. But ietf-xml-mime@imc.org is a separate list, which I'm cross- posting because you might get valuable feedback from there.