ietf-xml-mime
[Top] [All Lists]

Re: application/xml+rpc

2004-01-12 09:53:30

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

<Prev in Thread] Current Thread [Next in Thread>