application/xml+rpc

[Martin Duerst]

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 at alvestrand.no and ietf-types at iana.org are the same
list. But ietf-xml-mime at imc.org is a separate list, which I'm cross-
posting because you might get valuable feedback from there.