application/xml+rpc

[Mario Salzer]

Hey,

I see no problems using instead the subtype name /rpc+xml instead, after
all it's just a MIME type, and does not (should not?) need to reflect the
application name. It will be adopted, regardless of how it reads.

> Martin Duerst <duerst at w3.org> wrote:
> 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.

Found it now (the original 2048 only mentioned a FTP directory, last
updated February 2001).

But your statement makes me wonder, if registration of /rpc+xml must happen
as RFC? Actually I would like to do one (knowing, that there were already
two failed attempts with XML-RPC), but the trademark issue made me initially
request for registration of a MIME type distinct from "/xml-rpc" - so to
eventually allow a RFC with a title different from "XML-RPC" to overcome
the existing trademark. But that's off-topic here, I suspect.

> ...
> 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.
> ...
> Ah, so it's still XML, but not all XML would work for xml-rpc.

Yes, personally I don't use a XML parser to parse XML-RPC messages. And as I
see it, the "XML" in "XML-RPC" is just a buzzword. Moreover I would say
XML-RPC messages are only "using XML-like tokens" for making RPC calls
readable. Even if in fact the tokens make up validly nested XML tags, and
the <?xml...?> prefix then even allows to use XML-RPC messages with
non-validating XML parsers.


> 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.

I was unaware of the "+" denoting a generic subtype - does it also imply
the default or fall back file extension of xml dialect files to be .xml?
So of course the /xml+rpc is out of discussion, if only things like
+xml +sgml and +yaml are to be used as generic suffixes.

Again, I believe the "/rpc+xml" would then perfectly satisfy everyone. For
"/xml-rpc+xml" I would vote against, because then it would allow someone
else to register something like "XML encapsulated XML" as "*/xml-xml+xml"
or something that way ;)

"/rpc+xml" is fine, at least I like it. But is it eventually too generic?
What if there comes up another concurrent protocol of implementing RPC
with XML as its basis? Or can we now just consider XML-RPC to be the current
de facto standard and therefore reserve "/rpc+xml" presently? I know it was
ok to mark even a MIME type as OBSOLETE someday, but the question is, if
"/rpc+xml" isn't too generic to register for sole use by "XML-RPC". But
after all, this was just a matter of first come first serve?


> MURATA Makoto <murata at hokkaido.email.ne.jp> wrote:
> The whole point of using the "+xml" convention is allow generic XML 
> programs (e.g., parsers, browsers, etc.) to work properly.  I am sure 
> that many programs work with XML-RPC messages.  For example, users  
> might want to use browsers for debugging XML-RPC.  Unless there are 
> good reasons to *forbid* generic XML programs, please follow the 
> "+xml" convention.

I doubt that anything but a proxy will ever see such a XML-RPC message,
but who knows? And yes, there is absolutely no reason to _forbid_ anyone
to use a XML aware software (parser) on it - and actually this is
explicetely wanted (expressed in the <?xml...?> message prefix).


> 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).

The only fear I have is, that if the MIME type suggests that (by the "+xml"
convention), then such a hypothetic proxy could actually treat the body as
containing a REAL XML document. If that proxy now would be filtering one, it
may decide to mangle the content (addind some contents or some
<proxy:policy /> informational tags; who knows???). This was ok for real XML
documents, but XML-RPC is not XML-based as I already pointed out, and
various XML-RPC servers and clients can't even understand empty <tags /> nor
would they be able to understand XML-RPC messages anymore if the document
structure changed.

Ok, this is a silly example, and there is no automated XML mangling anywhere
on the net - but I'd like to revive the question, if we should denote
XML-RPC to be valid XML by using the +xml suffix?  Again: not-validating
XML parsers would understand XML-RPC, but does that fact alone prove a file
do be in XML?
And my final question to this is, if the w3c had any recommendations on the
"Simplified XML variants" issue (I'm very afraid to put that question into
the XML mailing list, knowing it rised nearly two thousand times there).

But let it say me again, "/rpc+xml" is fine for me, if you think it's okay
to state thereby that XML-RPC was a XML variant.

> >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?

The so called specification [http://www.xmlrpc.org/spec] does not state
anything about that (ho, it leaves out a lot more questions), and unless
there is a RFC about the protocol, it probably wouldn't be legitamate to
specify character set issues from the MIME level.

As far as I understand it, the current spec allows Latin1 as default. But it
is also clear that the actual character set is application dependent; that
is, that the participating programs in a XML-RPC connection already
negotiated on a charset, before that connection even was established (this
is just done by documenting the actual XML-RPC gateway API - the provided
method set).
And additionally there are also APIs out there (I'm about 'WikiXmlRpc'),
that even mix charsets (and encodings) inside of the requests - so that
there for example is a <value><string>...</ tag which requires ASCII and
another one which must be filled using UTF-8.
The WikiXmlRpc API for example reads like: "you must encode this method
parameter first with UTF-8 and then with base64 and pack it into a
<value><base64>...</ tag".

So, about the MIME type, I here just can say, that MIME won't help fixing
the various problems of the protocol, and thus there should be no charset=
parameter to the /rpc+xml MIME subtype, like there is no <?xml charset= ?>
parameter inside of the messages. Not using any of the possible MIME type
parameters also keeps the XML-RPC protocol simple (but the "spec" does not
talk much about _how_ XML and HTTP should be used).


> >- XML-RPC currently only operates on HTTP, so no need to take Mail protos
> >   into account
>
> What do you mean by "Mail protos"?

Currently XML-RPC only is supposed to work over HTTP, but I guess it would
be possible to use it over SMTP (but there would be no application for this,
and it wouldn't be widely used either).


> >- 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.

Ok, but for the XML-RPC I could only add a few fluffy comments, like "don't
make application interfaces available over XML-RPC which would allow
formatting your harddisk" or "implementations MUST NOT trust the received
method parameters and MUST check their data type".

#

After reading "draft-freed-mime-p4-04.txt" I'm still unsure how to proceed
with this request. Shall I just file another (then completed) registration
request to THIS list, or should I send it over to another address to let it
get approved, after we had finally discussed the remaining issues?


Regards,
mario