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
At 01:22 04/01/13 +0100, Mario Salzer wrote:
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.
Good! (but see below)
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.
Yes, unless you want something in the vendor tree or so, you have to write an RFC. There are a lot of examples already, so it may not be too difficult.
I think the type name should either be application/xml-rpc+xml, or application/rpc+xml, or application/rpc-xml.
Sorry, the latest should have been application/xml-rpc. But probably irrelevant now anyway.
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?
I don't think RFC 3023 says anything on that, but I guess an application may very well do that in some cases.
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?
I have thought about this, too. I think in general, I would be opposed to registrations such as application/graphics+xml or application/finance+xml for an xml-based graphics or finance format, for the reasons you give. However, xml-rpc is so well known, and even trademarked, that I doubt anybody else who came up with a format in this space would want to use those letters too much. So in my opinion, /rpc+xml would be okay. Others may feel different. In any case, it should not be taken as a case for a general first-come, first-serve policy. (but see also below)
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.
It does contain 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?
Yes, it does. It is XML because it follows the grammar (and some additional conventions) of the XML spec. There are a lot of XML files out there that don't have a dtd, don't have namespaces, don't have empty elements, and so on.
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).
The lists where we are discussing this are IETF lists, where people express their personal opinions. I seem to remember that the W3C TAG has discussed the issue of 'Simplified XML variants', and if there is anything like a 'w3c recommendation' on this issue, that's where you would find it. It is my personal opinion that in general, it is a bad idea to create simplified variants, because the additional efforts for parsers is minimal, and a lot of parsers are available, while on the other hand, confusion and interoperability problems can be serious. On the other hand, I can mention that SOAP also has some restrictions on XML syntax, some of the similar to rpc-xml, and SOAP is being registered as application/soap+xml.
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.
I agree that the RFC/registration should mention this, but it should say that xml-rpc only allows a restricted subset of XML syntax. Calling this a variant can lead to misunderstandings.
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]
After a look at that, and reading "This specification documents the XML-RPC protocol implemented in UserLand Frontier 5.1.", I'm starting to wonder whether a type of application/vnd.userland.rpc+xml might not be more appropriate.
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.
I haven't found that in the spec. It would be a serious deviation from XML, where UTF-8 (and UTF-16) is the 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).
Where in the 'spec' does it say so?
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.
ASCII is a subset of UTF-8, so this is not really a mixture of encodings, but just a subsetting of what characters you can use in different fields. If one and the same rpc-xml document would use two or more really different encodings in the same document (e.g. iso-8859-1 and utf-8), then this would no longer be XML at all. Do you know about any such cases?
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".
Once you have added base64, for XML, it's all in ASCII. But why make it more complicated by adding base64, why not just send all data in UTF-8? That's what XML was designed for.
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.
[That would be <?xml version='...' encoding='...' ?>]
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).
Keeping things undefined and keeping things simple are two different things.
- 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?
For application/vnd...., you write a full registration form, and send it here. For application/rpc+xml, my understanding is that you need an RFC. The first step to get there is to write an Internet Draft. Regards, Martin.
participants (2)
-
Mario Salzer -
Martin Duerst