A new draft of the application/soap+xml media type registration is
available;
http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-04.txt
This draft incorporates the actual registration data, making the
document self-contained, and tweaks some minor details (such as the
contact). The substance of the registration is unchanged.
--
Mark Nottingham Principal Technologist
Office of the CTO BEA Systems
>From duerst(a)w3.org Thu Jan 15 00:59:30 2004:
> >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
> >...
> 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.
As I now read, "every stupid can write a RFC", so that's just what I'm
going to do...
> 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)
And I guess it wouldn't matter either, as there seems no reason to me
not to assign a MIME type later to something different. For example
HTML2 and HTML4 share the same MIME type! Also if registration is
based on RFCs, then there isn't a reason not to obsolete a registration
by obsoleting such a RFC.
> It does contain a real xml document.
> ...
> >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.
Ok, XML is XML is XML. (I then almost answered that question myself.) And
obviously many documents are XML documents at a closer look:
<Hello World="!" />
> 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.
I've noticed multiple threads about "simplified XML" on the general
XML mailing list, but again refused to download another mbox compilation
just to follow them. And after noticing that this issue was already
discussed to death there, I didn't feel the necessarity to annoy
subscribers there. (And needless to say, until there is a full XML
parser in Assembler or Brainfuck this discussion will keep on.)
But as you pointed out, it also made little sense to have another
specification just for documenting a shadow of the original format.
> 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.
So I already started a draft, which would initially just mention what
features of XML to use and which not - this seriously becomes a big
"MUST NOT" paragraph. ;)
It's my current understanding of XML-RPC to be a dumb enough XML
format to even allow a token parser (flex) instead of a XML parser
or reading it.
> >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.
Hmm, possible. But won't happen. The UserLand folks (as I see it) are
not very interested in that. That's also why the XML-RPC isn't yet
RFCified.
And if they would register it in the vendor tree, you'd soon also
see:
* application/vnd.apache.rpc+xml
* application/vnd.xwt.xmc
(And one for everybody, who also interpreted the 'spec' slightly
different.)
Did the IETF or IANA make any provision against such MIME type explosions?
I think that's a serious concern, not only with this XML-RPC thing (but I
think here it was very likely to happen).
> >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.
The charset issue was discussed on the xmlrpc-dev mailing list almost
a thousand times. And still the so called 'spec' does not clearify it,
as you've seen.
Originally it mentioned "ASCII" in the table explaining the <string> type,
which led to implementations which only support or recommend 7bit chars,
and some only [\t\n\r040-0177] chars). Later UserLand introduced the
<base64> type to as one workaround. And then it was clearified that the
XML-RPC msgs are allowed to contain "binary" content (which rises the
question, why the <base64> thing then was introduced in the first place).
So the 'spec' says nothing about it. This then however would allow the
RFC to tell, that UTF-8 should be used all over.
>
> 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 <base64> is a good example, that one may choose to have UTF-8 in
the <string>s, but leave the original binary encoding within the <base64>
parts. Which would be ok from the XML point of view.
I only know of an implementation that recommended to UTF-8 encode some
<string>s and URLencoding (%41+%E1) for others. The latter ones then
could be some other charset, but then this was also ok, as they were
ciphered into an ASCII string.
However I'm almost sure, that there are also cases, where people freely
intermix encodings; because the destination RPC function would take care
of what format which function was.
>
> 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.
Exactly. However now that the <base64> is there, it won't go away.
>
> >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.
Ok, some more readings on that issue clearified the process to me. And
the RFC draft seems to be a good idea, because that userland howto is
anything but a "specification".
However, there was already an earlier attemp to do so. A draft on a
protocol called "XMC" was here until the end of 2002. (It documented
almost "XML-RPC", but because of the trademark issue was called
differently.) I've spoken with the drafts author, and he told me he
didn't update it because of the "lack of interest" from the IETF.
It was nearly complete on documenting the message body format, but
obviously lacked a bit RFC fine tuning. However this being rejected
in the end, makes me wonder if _I_ then should risk it even if it's
interesting and appears to be in widespread use.
Best regards,
mario
I submitted what I hope is the final draft of the "PDF registration"
document, draft-zilles-pdf-02.txt.
After re-reading RFC 2026 more carefully, I removed the entire
section that was giving trouble (Section 6 on Intellectual
Property).
The document is not intended for standards track. The
standard XML2RFC boilerplate includes RFC 2026 Section
10.4 (A) "The IETF takes no position regarding ..."
and (B) "The IETF invites any interested party to bring ...",
even though RFC 2026 only requires those for standards track
documents. If needed (e.g., if the document were to be
moved to standards track), I believe I can get Adobe to make an
Intellectual Property statement that repeats the information
contained in the PDF Reference manual (as modified by
its errata) in a separate statement to be included in the
IETF list of IPR statements.
The only other content change was to take the wording
from RFC 2854 (text/html) about Javascript execution
environments.
Larry
--
http://larry.masinter.net
