Re: MPEG asks for MIME review for the MPEG21 file format

Martin Duerst <duerst@it.aoyama.ac.jp> Fri, 18 May 2007 11:08 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4IB83iJ019990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 04:08:04 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4IB83mi019989; Fri, 18 May 2007 04:08:03 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4IB82k6019962 for <ietf-xml-mime@imc.org>; Fri, 18 May 2007 04:08:03 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp)
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l4IB7tla020634 for <ietf-xml-mime@imc.org>; Fri, 18 May 2007 20:07:55 +0900 (JST)
Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 51f3_07416dc8_0530_11dc_9798_0014221f2a2d; Fri, 18 May 2007 20:07:54 +0900
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59354) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <SA4B72> for <ietf-xml-mime@imc.org> from <duerst@it.aoyama.ac.jp>; Fri, 18 May 2007 20:06:23 +0900
Message-Id: <6.0.0.20.2.20070518194309.08d1ee50@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Fri, 18 May 2007 20:07:29 +0900
To: Anne van Kesteren <annevk@opera.com>, Chris Lilley <chris@w3.org>, Larry Masinter <LMM@acm.org>, ned.freed@mrochek.com
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: MPEG asks for MIME review for the MPEG21 file format
Cc: 'Dave Singer' <singer@apple.com>, 'Graham Klyne' <GK@ninebynine.org>, ietf-liaisons@ietf.org, "'Christian Timmerer (ITEC)'" <christian.timmerer@itec.uni-klu.ac.at>, ietf-types@alvestrand.no, ietf-xml-mime@imc.org
In-Reply-To: <op.tsidc6yf64w2qv@annevk.hotspot.sfr.fr>
References: <E94B6002-BAE6-4D08-98A3-89E8D46504F3@stewe.org> <AE61ED01-9B91-4D5D-8654-AF8DD1B86EA2@stewe.org> <464814BE.4090208@ninebynine.org> <p06240821c26e59493bca@[17.202.35.52]> <4649B0BA.4040002@ninebynine.org> <p0624084bc26f9de750bc@[17.202.35.52]> <002901c798b8$0f9ab4f0$2ed01ed0$@org> <892351513.20070518031209@w3.org> <op.tsidc6yf64w2qv@annevk.hotspot.sfr.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>

At 14:54 07/05/18, Anne van Kesteren wrote:
>
>On Fri, 18 May 2007 03:12:09 +0200, Chris Lilley <chris@w3.org> wrote:
>> The successor to RFC 3023 needs to indicate that binary XML which is  
>> presented as a new encoding (in the xml sense) can use +xml, while other  
>> binary forms cannot.
>
>You wouldn't be able to still parse the retrieved resource in that case  
>with a generic XML parser. Wasn't that the whole idea of +xml?

Well, yes, but the language lawyers argue as follows:

Except for UTF-8 and UTF-16, there is absolutely no guarantee
that an XML parser accepts any encoding whatsoever. There is
a lot of XML out there with e.g.
   <?xml version='1.0' encoding='Shift_JIS'?>
but no XML parser is required to grok that (although many do).
So you can view binary XML just as an extremely weird and special
character encoding. I personally wish it wouldn't be necessary,
but there are people who claim that it is, for whatever it's worth.

The successor of RFC 3032 shouldn't mention binary XML explicitly
(except by example), but just say that the boundary between what's
okay and what's not okay for a +xml prefix is whether the document
starts as an XML document as described in appendix F of the XML
Rec, and can correctly be parsed after the conversion from that
'character' encoding to XML.

What I also would like to see (in particular in my role as
one of the IETF charset reviewers) is how to make sure that
the labels for binary encodings won't in the future collide
with real registered charsets. Probably the best way to do
this would be to create some kind of 'provisional' registration,
or 'reserving' registration in the charset registry.
But that would need some work on a spec, at the moment,
probably the best way to do things would be to try and
get some kind of comment into the charset registry.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp