Re: application/xml+rpc

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 <[email protected]> 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.