January 2004 - Ietf-types

dns media type registration tree
by Mark Baker 02 Mar '04

02 Mar '04

Hi, I wanted to express my *strong* support for the recently published draft about the "dns" media type registration tree[1]. I think this is long overdue, and I thank Mark for devising such a straightforward mechanism for decentralizing the media type assignment process (you don't want to know what I was going to propose 8-). I would like to propose one substantive change to the document though. As I see it, there are two objectives that we'd really like to achieve; a decentralized namespace, and dereferenceable identifiers (for all the reasons in [2]). Mark's draft ably addresses the former, but doesn't seem to treat the latter as an objective, although the "doc" parameter is a step in that direction. I think a fairly small tweak can give us both. What I propose is that the doc parameter be replaced by a "base" parameter whose value is a URI that is intended to permit the media type name itself to be used as a relative URI. For example, if we had the media type "text/dns.foo.example.com", with a base parameter value of "http://example.com/mtype/" then the authoritative URI for the media type would be "http://example.com/mtype/text/dns.foo.example.com" (see the discussion[3] about the relative URI approach by the W3C TAG). The document should be clear that the resultant URI is the authoritative URI for the media type. It would still be optional, though I'd like to say that we recommend that it SHOULD be used, and SHOULD be dereferenceable using currently ubiquitous technologies. Thoughts? [1] http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree-00.txt [2] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registrie… [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9 Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

5 11

Hi
by iana＠iana.org 24 Jan '04

24 Jan '04

Test =) juonmymriikwo -- Test, yep.

1 0

application/soap+xml
by Mark Nottingham 22 Jan '04

22 Jan '04

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

1 0

Hi
by iana＠iana.org 20 Jan '04

20 Jan '04

Test =) atrfaysspwiynsnsfxodid -- Test, yep.

1 0

Hi
by iana＠iana.org 20 Jan '04

20 Jan '04

Test =) edtjvkdfavifdsiba -- Test, yep.

1 0

Hi
by iana＠iana.org 20 Jan '04

20 Jan '04

Test =) iedlihrlriyvhf -- Test, yep.

1 0

Hi
by iana＠iana.org 20 Jan '04

20 Jan '04

Test =) sqouvnlbsyrbfypdevnlx -- Test, yep.

1 0

Re: application/xml+rpc
by Mario Salzer 20 Jan '04

20 Jan '04

>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

2 3

New version of PDF registration draft
by Larry Masinter 20 Jan '04

20 Jan '04

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

1 0

Hi
by iana＠iana.org 19 Jan '04

19 Jan '04

Test =) sajbwjnc -- Test, yep.

1 0