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(_at_)w3(_dot_)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.