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