From discuss-bounces@apps.ietf.org Mon Sep 04 12:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHDm-0006M3-RC; Mon, 04 Sep 2006 12:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKHDk-0006Lx-UX for discuss@apps.ietf.org; Mon, 04 Sep 2006 12:22:48 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKHDf-0004tY-HK for discuss@apps.ietf.org; Mon, 04 Sep 2006 12:22:48 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k84GMomw013575 for ; Mon, 4 Sep 2006 09:22:50 -0700 Message-ID: <44FC52C3.2060101@ninebynine.org> Date: Mon, 04 Sep 2006 17:22:27 +0100 From: Graham Klyne User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: javascript URI scheme not registered - spec seems to be missing X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: gk@ninebynine.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Digging around a question recently posed to me reveals that the commonly-used (pseudo-)URI scheme 'javascript:' is not registered [1], and I also note that the specification [3] noted by one web site [2] is no longer available. BTW, the web page [4] ("What schemes are out there?") might be a useful resource in considering what schemes might be candidates for provisional registration (possibly with health warnings) if they're not already registered. #g -- [1] http://www.iana.org/assignments/uri-schemes.html [2] http://esw.w3.org/topic/UriSchemes/javascript [3] http://developer.netscape.com/docs/manuals/js/client/jsref/index.htm (no longer available) [4] http://esw.w3.org/topic/UriSchemes -- Graham Klyne For email: http://www.ninebynine.org/#Contact From discuss-bounces@apps.ietf.org Tue Sep 05 12:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKdv0-0004Lo-UQ; Tue, 05 Sep 2006 12:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNbk-0003ts-NY for discuss@apps.ietf.org; Mon, 04 Sep 2006 19:12:00 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKNbg-00038T-BZ for discuss@apps.ietf.org; Mon, 04 Sep 2006 19:12:00 -0400 Received: by ug-out-1314.google.com with SMTP id q2so1708446uge for ; Mon, 04 Sep 2006 16:11:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NRjX4pz82HO+1h7hoWYnxfCih43alaJbRIGT1YcEfitzST6M31POfmOizflW4w+qaVrBMOZvzA7oBt+Xr1GweU2QRuxNSnBRjrajcAJ1QdJqEkkQ8LGFQv+rOVmm0Ca7iT6ItusOGWilBxIv8Il4MZB/NnwuHZdy7jjlRqbbBIM= Received: by 10.66.216.20 with SMTP id o20mr3247477ugg; Mon, 04 Sep 2006 16:11:54 -0700 (PDT) Received: by 10.66.224.9 with HTTP; Mon, 4 Sep 2006 16:11:54 -0700 (PDT) Message-ID: <84ce626f0609041611r5a32208er883b7bdeb7114707@mail.gmail.com> Date: Mon, 4 Sep 2006 16:11:54 -0700 From: "Charles Iliya Krempeaux" To: "IETF Apps Discuss Mailing List" Subject: Re: javascript URI scheme not registered - spec seems to be missing In-Reply-To: <44FC52C3.2060101@ninebynine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44FC52C3.2060101@ninebynine.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Tue, 05 Sep 2006 12:36:57 -0400 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Graham, I noticed there was one URI scheme missing from that list of known URI schemes. In the old Netscape Navigator web browsers, there was something like a WYSIWYG URI scheme. (Although I think it wasn't exactly "WYSIWYG"... but had one of the letters different.) I remember it coming up every now about then when you were just going about normal web browsing. (Back then I thought it was some kind of bug that made it show up.) Not sure if anyone else remembers this. On 9/4/06, Graham Klyne wrote: > Digging around a question recently posed to me reveals that the commonly-used > (pseudo-)URI scheme 'javascript:' is not registered [1], and I also note that > the specification [3] noted by one web site [2] is no longer available. > > BTW, the web page [4] ("What schemes are out there?") might be a useful resource > in considering what schemes might be candidates for provisional registration > (possibly with health warnings) if they're not already registered. > > #g > -- > > [1] http://www.iana.org/assignments/uri-schemes.html > > [2] http://esw.w3.org/topic/UriSchemes/javascript > > [3] http://developer.netscape.com/docs/manuals/js/client/jsref/index.htm (no > longer available) > > [4] http://esw.w3.org/topic/UriSchemes > > > -- > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___________________________________________________________________________ Make Television http://maketelevision.com/ From discuss-bounces@apps.ietf.org Wed Sep 06 14:06:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1m7-0007lt-2Y; Wed, 06 Sep 2006 14:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL1m6-0007lo-Az for discuss@apps.ietf.org; Wed, 06 Sep 2006 14:05:22 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL1m4-0000DV-T5 for discuss@apps.ietf.org; Wed, 06 Sep 2006 14:05:22 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k86I5At7021587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Sep 2006 11:05:12 -0700 Received: from [129.46.225.24] ([129.46.225.24]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k86I524J024030; Wed, 6 Sep 2006 11:05:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 6 Sep 2006 11:04:53 -0700 To: ietf@ietf.org, discuss@apps.ietf.org, ietf-charsets@iana.org From: Ted Hardie Subject: Volunteer needed to serve as IANA charset reviewer Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The Applications Area is soliciting volunteers willing to serve as the IANA charset reviewer. This position entails reviewing charset registrations submitted to IANA in accordance with the procedures set out in RFC 2978. It requires the reviewer to monitor discussion on the ietf-charsets mailing list (moderating it, if necessary); it also requires that the reviewer interact with the registrants and IANA on the details of the registration. There is currently a small backlog, and it will be necessary to work to resolve that backlog during the initial period of the appointment. If you are willing to serve in this capacity, please notify the ADs by September 20th, 2006. A short summary of your experience in the area should be included. From discuss-bounces@apps.ietf.org Wed Sep 06 14:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL2Oz-0008Ha-DO; Wed, 06 Sep 2006 14:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL2Ox-0008HB-B3 for discuss@apps.ietf.org; Wed, 06 Sep 2006 14:45:31 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL2Ov-0001St-UD for discuss@apps.ietf.org; Wed, 06 Sep 2006 14:45:31 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GL2Ou-000PWQ-IW; Wed, 06 Sep 2006 14:45:28 -0400 Date: Wed, 06 Sep 2006 14:45:27 -0400 From: John C Klensin To: Ted Hardie , discuss@apps.ietf.org, ietf-charsets@iana.org Subject: Re: Volunteer needed to serve as IANA charset reviewer Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org (IETF list removed, since this is about to become specialized) --On Wednesday, 06 September, 2006 11:04 -0700 Ted Hardie wrote: > The Applications Area is soliciting volunteers willing to > serve as the IANA charset reviewer. This position entails > reviewing charset registrations submitted to IANA in > accordance with the procedures set out in RFC 2978. It > requires the reviewer to monitor discussion on the > ietf-charsets mailing list (moderating it, if necessary); it > also requires that the reviewer interact with the registrants > and IANA on the details of the registration. There is > currently a small backlog, and it will be necessary to work to > resolve that backlog during the initial period of the > appointment. >... Perhaps the need for a new volunteer in this area is the time to ask a broader question: At the time 2978 (and its predecessor, 2278) were defined, there were a large number of charsets in heavy use and there was some general feeling in the implementer community that, despite the provisions of RFC 2277, Unicode/ISO 10646 were not quite ready. Although we probably still have some distance to go (the issues with my net-Unicode draft may be illustrative), I wonder if we are reaching the point at which a stronger "use Unicode on the wire" recommendation would be in order. The implications of such a recommendation would presumably include a 2978bis that made the requirements for registration of a new charset _much_ tougher, e.g., requiring a demonstration that the then-current version of Unicode cannot do the relevant job and/or evidence that the newly-proposed charset is needed in deployed applications. This question is motivated, not by a strong love for Unicode, but by the observation that RFC 2277 requires it and that the IETF is shifting toward it in a number of areas. More options and possibilities for local codings that are not generally known and supported do not help with interoperability; perhaps it is time to start pushing back. And that, of course, would dramatically change the work of the charset reviewer by reducing the volume but increasing the amount of evaluation to be done. john From discuss-bounces@apps.ietf.org Wed Sep 06 16:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3ci-0001lW-7N; Wed, 06 Sep 2006 16:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3ch-0001lR-8r for discuss@apps.ietf.org; Wed, 06 Sep 2006 16:03:47 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3cb-0003fi-Qb for discuss@apps.ietf.org; Wed, 06 Sep 2006 16:03:47 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k86K3f61016768 for ; Wed, 6 Sep 2006 14:03:41 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5600501SHCU400@mail-amer.sun.com> (original mail from tbray@textuality.com) for discuss@apps.ietf.org; Wed, 06 Sep 2006 14:03:41 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.64]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5600IUWT0IX731@mail-amer.sun.com>; Wed, 06 Sep 2006 14:03:41 -0600 (MDT) Date: Wed, 06 Sep 2006 13:04:17 -0700 From: Tim Bray Subject: Re: Volunteer needed to serve as IANA charset reviewer In-reply-to: To: John C Klensin Message-id: <5D2B3F79-EFD6-4847-ABC1-EE8401759437@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Ted Hardie , discuss@apps.ietf.org, ietf-charsets@iana.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sep 6, 2006, at 11:45 AM, John C Klensin wrote: > I wonder if we > are reaching the point at which a stronger "use Unicode on the > wire" recommendation would be in order. The implications of > such a recommendation would presumably include a 2978bis that > made the requirements for registration of a new charset _much_ > tougher, e.g., requiring a demonstration that the then-current > version of Unicode cannot do the relevant job and/or evidence > that the newly-proposed charset is needed in deployed > applications. Yes, please. Unicode is not perfect, but it's actually very good in quite a few different ways, and network effects have pretty well taken over, so if you're doing any text on the network at all, it's almost certainly the right thing to use Unicode. As a Certified Unicode Bigot(tm) I would volunteer to help with such a redraft. -Tim From discuss-bounces@apps.ietf.org Wed Sep 06 17:03:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4YL-0001hT-MH; Wed, 06 Sep 2006 17:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4YJ-0001gR-VL for discuss@apps.ietf.org; Wed, 06 Sep 2006 17:03:19 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL4YI-0003R7-Dv for discuss@apps.ietf.org; Wed, 06 Sep 2006 17:03:19 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6VLE7Q1CW00NVEZ@mauve.mrochek.com> for discuss@apps.ietf.org; Wed, 6 Sep 2006 14:03:13 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6VIKB0I6O0008CX@mauve.mrochek.com>; Wed, 06 Sep 2006 14:03:12 -0700 (PDT) To: John C Klensin Message-id: <01M6VLE70BJ60008CX@mauve.mrochek.com> Date: Wed, 06 Sep 2006 13:30:44 -0700 (PDT) From: Ned Freed Subject: Re: Volunteer needed to serve as IANA charset reviewer In-reply-to: "Your message dated Wed, 06 Sep 2006 14:45:27 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Ted Hardie , discuss@apps.ietf.org, ietf-charsets@iana.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > (IETF list removed, since this is about to become specialized) > --On Wednesday, 06 September, 2006 11:04 -0700 Ted Hardie > wrote: > > The Applications Area is soliciting volunteers willing to > > serve as the IANA charset reviewer. This position entails > > reviewing charset registrations submitted to IANA in > > accordance with the procedures set out in RFC 2978. It > > requires the reviewer to monitor discussion on the > > ietf-charsets mailing list (moderating it, if necessary); it > > also requires that the reviewer interact with the registrants > > and IANA on the details of the registration. There is > > currently a small backlog, and it will be necessary to work to > > resolve that backlog during the initial period of the > > appointment. > >... > Perhaps the need for a new volunteer in this area is the time to > ask a broader question: > At the time 2978 (and its predecessor, 2278) were defined, there > were a large number of charsets in heavy use and there was some > general feeling in the implementer community that, despite the > provisions of RFC 2277, Unicode/ISO 10646 were not quite ready. > Although we probably still have some distance to go (the issues > with my net-Unicode draft may be illustrative), I wonder if we > are reaching the point at which a stronger "use Unicode on the > wire" recommendation would be in order. The implications of > such a recommendation would presumably include a 2978bis that > made the requirements for registration of a new charset _much_ > tougher, e.g., requiring a demonstration that the then-current > version of Unicode cannot do the relevant job and/or evidence > that the newly-proposed charset is needed in deployed > applications. I agree that we've reached a point where "use UTF-8" is what we need to be pushing for in new protocol development. (Note that I said UTF-8 and not Unicode - given the existance of gb18030 [*] I don't regard a recommendation of "use Unicode" as even close to sufficient. The last thing we want is to see the development of specializesd Unicode CESes for Korean, Japanese, Arabic, Hebrew, Thai, and who knows what else.) And if the reason there are new charset registrations was because of the perceived need to have new charsets for use in new protocols, I would be in total agreement that a change in focus for charset registration is in order. But that's not why we're seeing new registrations. The new registrations we're seeing are of legacy charsets used in legacy applications and protocols that for whatever reason never got registered previously. Given that these things are in use in various nooks and crannies around the world, it is critically important that when they are used they are labelled accurately and consistently. The plain fact of the matter is that we have done a miserable job of producing an accurate and useful charset registry, and considerable work needs to be done both to register various missing charsets as well as to clean up the existing registry, which contains many errors. I've seen no interest whatsoever in registering new charsets for new protocols, so to my mind pushing back on, say, the recent registration of iso-8859-11, is an overreaction to a non-problem. [**] > This question is motivated, not by a strong love for Unicode, > but by the observation that RFC 2277 requires it and that the > IETF is shifting toward it in a number of areas. More options > and possibilities for local codings that are not generally known > and supported do not help with interoperability; perhaps it is > time to start pushing back. Well, I have to say that to the extent we've pushed back on registrations, what we've ended up with is ad-hoc mess of unregistered usage. I am therefore quite skeptical of any belief that pushing back on registrations is a useful tactic. > And that, of course, would dramatically change the work of the > charset reviewer by reducing the volume but increasing the > amount of evaluation to be done. Even if we closed the registry completely there is still a bunch of work to do in terms of registry cleanup. Now, having said all this, I'm willing to take on the role of charset reviewer, but with the understanding that one of the things I will do is conduct a complete overhaul of the existing registry. [***] Such a substantive change will of course require some degree of oversight, which in turn means I'd like to see some commitment from the IESG of support for the effort. As for qualifications, I did write the charset registration specification, and I also wrote and continue to maintain a fairly full-features charset conversion library. I can provide more detail if anyone cares. Ned [*] - For those not fully up to speed on this stuff, gb18030 can be seen as an encoding of Unicode that is backwards compatible with the previous simplified Chinese charsets gb2312 and gbk. [**] - The less recent attempt to register ISO-2022-JP-2004 is a more interesting case. I believe this one needed to be pushed on, but not because of potential use in new applications or protocols. [***] - I have the advantage of being close enough to IANA that I can drive over there and have F2F meetings should the need arise - and I suspect it will. From discuss-bounces@apps.ietf.org Wed Sep 06 18:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL60a-0000zC-Cj; Wed, 06 Sep 2006 18:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL60Z-0000xp-PF for discuss@apps.ietf.org; Wed, 06 Sep 2006 18:36:35 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL60X-0001v9-Hk for discuss@apps.ietf.org; Wed, 06 Sep 2006 18:36:35 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 271A056452; Wed, 6 Sep 2006 17:43:55 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcDWQhEeb2yp; Wed, 6 Sep 2006 17:43:52 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by shu.cs.utk.edu (Postfix) with ESMTP id ED64D56415; Wed, 6 Sep 2006 17:43:37 -0400 (EDT) Date: Wed, 6 Sep 2006 17:45:58 -0400 From: Keith Moore To: Ned Freed Subject: Re: Volunteer needed to serve as IANA charset reviewer Message-Id: <20060906174558.ff156501.moore@cs.utk.edu> In-Reply-To: <01M6VLE70BJ60008CX@mauve.mrochek.com> References: <01M6VLE70BJ60008CX@mauve.mrochek.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: hardie@qualcomm.com, ietf-charsets@iana.org, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I concur with the need to maintain the current charset registry to support legacy apps that use it. And I think Ned would be an excellent choice for reviewer, though it wouldn' t bother me if he could have the assistance of people with specialized expertise in Asian writing schemes. As for utf-8 vs. Unicode, this is a bit tricky. I agree that merely specifying Unicode isn't sufficient given the potential for incompatible CESs. And yet I'm sympathetic to the notion that UTF-8 pessimizes storage and transmission of text written in certain languages. IMHO it's unreasonable to exclude the potential for a Unicode based CES that has more-or-less equivalent information density across a wide variety of languages. But I do think that use of multiple CESs in a new protocol should require substantial justification, and that UTF-8 should be presumed to be the CES of choice for any new protocol that requires ASCII compatibility for its character representation. Keith From discuss-bounces@apps.ietf.org Wed Sep 06 19:28:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6ng-0001V2-LX; Wed, 06 Sep 2006 19:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6nf-0001Ux-KC for discuss@apps.ietf.org; Wed, 06 Sep 2006 19:27:19 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL6nd-0003XN-9T for discuss@apps.ietf.org; Wed, 06 Sep 2006 19:27:19 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k86NR9No024196 for ; Wed, 6 Sep 2006 17:27:09 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5700I012DG4600@mail-amer.sun.com> (original mail from tbray@textuality.com) for discuss@apps.ietf.org; Wed, 06 Sep 2006 17:27:09 -0600 (MDT) Received: from [192.168.1.15] ([216.113.204.64]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J57007IJ2H8AOX0@mail-amer.sun.com>; Wed, 06 Sep 2006 17:27:09 -0600 (MDT) Date: Wed, 06 Sep 2006 16:27:46 -0700 From: Tim Bray Subject: Re: Volunteer needed to serve as IANA charset reviewer In-reply-to: <20060906174558.ff156501.moore@cs.utk.edu> To: Keith Moore Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <01M6VLE70BJ60008CX@mauve.mrochek.com> <20060906174558.ff156501.moore@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: hardie@qualcomm.com, discuss@apps.ietf.org, Ned Freed , ietf-charsets@iana.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sep 6, 2006, at 2:45 PM, Keith Moore wrote: > As for utf-8 vs. Unicode, this is a bit tricky. I agree that merely > specifying Unicode isn't sufficient given the potential for > incompatible CESs. And yet I'm sympathetic to the notion that UTF-8 > pessimizes storage and transmission of text written in certain > languages. IMHO it's unreasonable to exclude the potential for a > Unicode based CES that has more-or-less equivalent information > density across a wide variety of languages. But I do think that > use of > multiple CESs in a new protocol should require substantial > justification, and that UTF-8 should be presumed to be the CES of > choice for any new protocol that requires ASCII compatibility for its > character representation. Agreed on all counts. Section 5.1 of RFC3470 (aka BCP70) says smart things about this, referencing 2277. Basically, if you're going to use XML, there's probably no point trying to legislate against UTF-16 since any conformant reader is required to accept it, and in practice all known XML software can handle 8859 and Shift-JIS and EUC. But if you're not doing XML, compulsory UTF-8 removes a lot of failure points without costing much. -Tim From discuss-bounces@apps.ietf.org Wed Sep 06 20:59:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL8DZ-0003sC-L9; Wed, 06 Sep 2006 20:58:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL8DY-0003ru-Ia for discuss@apps.ietf.org; Wed, 06 Sep 2006 20:58:08 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL8AH-00005i-2F for discuss@apps.ietf.org; Wed, 06 Sep 2006 20:54:46 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6VTGROUB400OH84@mauve.mrochek.com> for discuss@apps.ietf.org; Wed, 6 Sep 2006 17:54:22 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6VIKB0I6O0008CX@mauve.mrochek.com>; Wed, 06 Sep 2006 17:54:11 -0700 (PDT) To: Keith Moore Message-id: <01M6VTGKMA620008CX@mauve.mrochek.com> Date: Wed, 06 Sep 2006 15:58:19 -0700 (PDT) From: Ned Freed Subject: Re: Volunteer needed to serve as IANA charset reviewer In-reply-to: "Your message dated Wed, 06 Sep 2006 17:45:58 -0400" <20060906174558.ff156501.moore@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01M6VLE70BJ60008CX@mauve.mrochek.com> <20060906174558.ff156501.moore@cs.utk.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: hardie@qualcomm.com, Ned Freed , ietf-charsets@iana.org, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I concur with the need to maintain the current charset registry to > support legacy apps that use it. > And I think Ned would be an excellent choice for reviewer, though it > wouldn' t bother me if he could have the assistance of people with > specialized expertise in Asian writing schemes. Any such assistance would be hugely welcome. As an aside, it would also be nice if more people would post comments to the list... > As for utf-8 vs. Unicode, this is a bit tricky. I agree that merely > specifying Unicode isn't sufficient given the potential for > incompatible CESs. And yet I'm sympathetic to the notion that UTF-8 > pessimizes storage and transmission of text written in certain > languages. IMHO it's unreasonable to exclude the potential for a > Unicode based CES that has more-or-less equivalent information > density across a wide variety of languages. But I do think that use of > multiple CESs in a new protocol should require substantial > justification, and that UTF-8 should be presumed to be the CES of > choice for any new protocol that requires ASCII compatibility for its > character representation. This is pretty much where I'm at as well. I have no problem with UTF-16 or UTF-32 if there is a compelling reason to allow them, but I really want to at least try and close the door to additional CESes to the greatest extent possible. Of course this is really an issue for the IAB and not the charset reviewer - thank goodness. Ned From discuss-bounces@apps.ietf.org Thu Sep 07 09:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKPJ-0007g4-F9; Thu, 07 Sep 2006 09:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKPH-0007ft-Ho for discuss@apps.ietf.org; Thu, 07 Sep 2006 09:59:03 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKPF-0007Yc-Ra for discuss@apps.ietf.org; Thu, 07 Sep 2006 09:59:03 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GLKP4-0007y7-SV; Thu, 07 Sep 2006 09:58:51 -0400 Date: Thu, 07 Sep 2006 09:58:49 -0400 From: John C Klensin To: Ned Freed Subject: Re: Volunteer needed to serve as IANA charset reviewer Message-ID: <9401EE90FE7BD970E71C9285@p3.JCK.COM> In-Reply-To: <01M6VLE70BJ60008CX@mauve.mrochek.com> References: <01M6VLE70BJ60008CX@mauve.mrochek.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Ted Hardie , discuss@apps.ietf.org, ietf-charsets@iana.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned, Several observations... The first is that my note was intended as "is it time to review RFC 2978 and the definition of the charset reviewer job". Just a question. I had no expectation of discontinuing the current registry, nor any realistic one of banning future registrations. I think your comments, Mark's, and those of others are consistent with my goal in asking the question. What should be done is another matter -- see below. Second, while I agree with your concern about GB 18030 and its ilk, what I learned in trying to put a network-Unicode definition together (see draft-klensin-net-utf8-01.txt) is that, for practical use, just specifying "UTF-8" may not be good enough either. For example, for at least most purposes other than pure rendering, one probably wants to specify the normalization form (ideally a "stable" one(++)) for text going on the wire, so "Unicode, in Stable NFC, encoded in UTF-8" is probably the level of specification we are looking for, not "UTF-8". I deliberately said "Unicode" in my note, not because I thought it was adequate, but because I was certain that it would expose this issue if we got this far. If we really need to be pushing toward a specific encoding and either the required specification of the normalization applied or, preferably, a specific normalization, then RFC 2978 isn't our only issue -- we need to review, and possibly reopen RFC 2277 and 3629 and might need to look at some other specifications. Realizing this was what caused me to temporarily put the network-Unicode draft on hold. I am delighted that you would be willing to take this on -- I think you have just exactly the right combination of skill and experience with both character sets and Internet applications protocols. Your ability to do the currently-defined job, or a slightly different one, is largely independent of whether the specifications for new additions to the registry are what we should have today. Clearly, the registry serves the purpose of reducing the odds of the same name being used, inadvertently, to describe different things and that is a benefit in itself. Mark suggests that the definitions are not sufficiently consistent and of high quality to be used for anything else. I think we need to figure out what we need (does the current quality of registrations meet your criteria for "accurately and consistently"?) and then respecify things so that we get it on future reservations (and maybe can ask IANA to send out requests for clarification to relevant existing ones). Certainly your notion of overhauling the current registry is consistent with this... it even goes beyond what I had hoped there were energy for. You wrote... > The plain fact of the matter is that we have done a miserable > job of producing an accurate and useful charset registry, and > considerable work needs to be done both to register various > missing charsets as well as to clean up the existing registry, > which contains many errors. I've seen no interest whatsoever in > registering new charsets for new protocols, so to my mind > pushing back on, say, the recent registration of iso-8859-11, > is an overreaction to a non-problem. [**] Speaking personally, we are in complete agreement. > Well, I have to say that to the extent we've pushed back on > registrations, what we've ended up with is ad-hoc mess of > unregistered usage. I am therefore quite skeptical of any > belief that pushing back on registrations is a useful tactic. Also agree, regardless of what my note appeared to say (in the interest of opening up exactly this discussion). john ++ For those who have not been following that particular piece of work, the Unicode Consortium now has a proposal for "Stable Normalization Process" under public review (see http://www.unicode.org/review/pr-95.html). It differs from the existing normalization forms by applying additional prohibitions on unassigned code points and problematic sequences and originated from discussions about the conditions under which IDNA and Stringprep could be migrated from Unicode 3.2 to contemporary versions. I would encourage those in IETF who are interested in these issues to review that proposal carefully and comment on it as appropriate. From discuss-bounces@apps.ietf.org Thu Sep 07 13:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNpj-0003h6-Se; Thu, 07 Sep 2006 13:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLHD6-0002UG-6p for discuss@apps.ietf.org; Thu, 07 Sep 2006 06:34:16 -0400 Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLHD3-000092-QP for discuss@apps.ietf.org; Thu, 07 Sep 2006 06:34:16 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 07 Sep 2006 06:34:13 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id MFA75622; Thu, 7 Sep 2006 06:34:10 -0400 (EDT) Received: from 68-187-229-110.dhcp.oxfr.ma.charter.com (HELO mail.blilly.com) ([68.187.229.110]) by smtp01.lnh.mail.rcn.net with ESMTP; 07 Sep 2006 06:34:06 -0400 X-IronPort-AV: i="4.08,223,1154923200"; d="scan'208"; a="272470077:sNHT27785664" Received: from marty.blilly.com (marty.blilly.com [192.168.99.98]) by mail.blilly.com with ESMTP id k87AXxPx006736(8.13.6/8.13.6/mail.blilly.com /etc/sendmail.mc.mail 1.28 2006/06/11 04:26:23) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Sep 2006 06:33:59 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id k87AXwtB006735(8.13.6/8.13.6/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) ; Thu, 7 Sep 2006 06:33:59 -0400 From: Bruce Lilly Organization: Bruce Lilly To: ietf-charsets@iana.org Subject: Re: Volunteer needed to serve as IANA charset reviewer Date: Thu, 7 Sep 2006 06:33:48 -0400 User-Agent: KMail/1.9.4 References: <20060906174558.ff156501.moore@cs.utk.edu> <01M6VTGKMA620008CX@mauve.mrochek.com> In-Reply-To: <01M6VTGKMA620008CX@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609070633.54738@mail.blilly.com> X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.44FFF41E.0089,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Thu, 07 Sep 2006 13:38:34 -0400 Cc: Keith Moore , hardie@qualcomm.com, Ned Freed , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-charsets@iana.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed September 6 2006 18:58, Ned Freed wrote: > > I concur with the need to maintain the current charset registry to > > support legacy apps that use it. > > > And I think Ned would be an excellent choice for reviewer, though it > > wouldn' t bother me if he could have the assistance of people with > > specialized expertise in Asian writing schemes. > > Any such assistance would be hugely welcome. As an aside, it would also be nice > if more people would post comments to the list... OK. I concur with most of what has already been said by others, specifically that if a charset (i.e. something meeting the definition of charset) is in use, it ought to be registered; using the registry as a way to force some agenda is a very bad idea. Also that Ned would be an excellent choice for reviewer, and I would add that I fully support his stated plan to overhaul the existing registry, which has long been in need of such an overhaul (e.g. the registration procedure has long said that "ASCII" is disallowed, yet it is in fact registered as an alias). A few differences of opinion: Keith Moore wrote: > > But I do think that use of > > multiple CESs in a new protocol should require substantial > > justification, and that UTF-8 should be presumed to be the CES of > > choice for any new protocol that requires ASCII compatibility for its > > character representation. There may well be areas of application for new protocols which cannot fully support Unicode which underlies use of utf-8, due to character set size, huge tables needed for normalization, etc. (see sections 3.1 (paying particular attention to "memory-starved microprocessors") and 3.4 of RFC 1958). Not all protocols need to fully support utf-8 directly; the highly successful mail system, for example, supports only a subset of ANSI X3.4 in message header fields, yet it allows pass-through of utf-8 and other charsets via RFC 2047 mechanisms as amended by RFC 2231 and errata. Ted Hardie wrote: > > This question is motivated, not by a strong love for Unicode, > > but by the observation that RFC 2277 requires it and that the > > IETF is shifting toward it in a number of areas. To be precise, RFC 2277 says: " Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text. Protocols MAY specify, in addition, how to use other charsets or other character encoding schemes for ISO 10646, such as UTF-16, but lack of an ability to use UTF-8 is a violation of this policy; such a violation would need a variance procedure ([BCP9] section 9) with clear and solid justification in the protocol specification document before being entered into or advanced upon the standards track. For existing protocols or protocols that move data from existing datastores, support of other charsets, or even using a default other than UTF-8, may be a requirement. This is acceptable, but UTF-8 support MUST be possible. When using other charsets than UTF-8, these MUST be registered in the IANA charset registry, if necessary by registering them when the protocol is published. " Several points: 1. "MUST be able to use" is a bit different from "requires" (see the above example of the mail system, which is able to use utf-8 by the mechanisms noted, but which does not require and in fact cannot directly accommodate raw utf-8). 2. The explicitly stated policy of allowing alternative charsets is important. 3. Most important, note that 2277 explicitly requires registration. > I have no problem with UTF-16 or > UTF-32 if there is a compelling reason to allow them, Well neither (as well as their "BE" and "LE" variants) is suitable for use with MIME text types, which precludes their use in a number of important applications. And one thing the charset registry sorely needs is a more explicit indication of which charsets are/are not suitable for such use (heck, some registrations have lacked the required statement of [un]suitability, so even groping through all of the registrations is of no use (and don't get me started on RFC 1345 issues)). From discuss-bounces@apps.ietf.org Thu Sep 07 13:39:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNqS-0003kk-E7; Thu, 07 Sep 2006 13:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLMNT-0004GB-5s for discuss@apps.ietf.org; Thu, 07 Sep 2006 12:05:19 -0400 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLMFf-0002Zp-1Z for discuss@apps.ietf.org; Thu, 07 Sep 2006 11:57:16 -0400 Received: by rap.rap.dk (Postfix, from userid 500) id A550227A8E; Thu, 7 Sep 2006 17:56:14 +0200 (CET DST) Date: Thu, 7 Sep 2006 17:56:14 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: ietf-charsets@iana.org Subject: Re: Volunteer needed to serve as IANA charset reviewer Message-ID: <20060907155614.GA21105@rap.rap.dk> References: <20060906174558.ff156501.moore@cs.utk.edu> <01M6VTGKMA620008CX@mauve.mrochek.com> <200609070633.54738@mail.blilly.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609070633.54738@mail.blilly.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Thu, 07 Sep 2006 13:39:19 -0400 Cc: Keith Moore , hardie@qualcomm.com, Ned Freed , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Sep 07, 2006 at 06:33:48AM -0400, Bruce Lilly wrote: > On Wed September 6 2006 18:58, Ned Freed wrote: > > > I concur with the need to maintain the current charset registry to > > > support legacy apps that use it. > > > > > And I think Ned would be an excellent choice for reviewer, though it > > > wouldn' t bother me if he could have the assistance of people with > > > specialized expertise in Asian writing schemes. > > > > Any such assistance would be hugely welcome. As an aside, it would also be nice > > if more people would post comments to the list... > > OK. I concur with most of what has already been said by others, specifically > that if a charset (i.e. something meeting the definition of charset) is in > use, it ought to be registered; using the registry as a way to force some > agenda is a very bad idea. Also that Ned would be an excellent choice for > reviewer, and I would add that I fully support his stated plan to overhaul > the existing registry, which has long been in need of such an overhaul (e.g. > the registration procedure has long said that "ASCII" is disallowed, yet it > is in fact registered as an alias). There seems to be a problem here, but maybe it whould then be the procedures that be revised, as ASCII is a well known name for a specific character set. I can agree to that ascii not be the recommended name for the specific charset. Best regards keld From discuss-bounces@apps.ietf.org Thu Sep 07 13:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNs1-0004E2-Vj; Thu, 07 Sep 2006 13:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL6h4-00071a-Ta for discuss@apps.ietf.org; Wed, 06 Sep 2006 19:20:30 -0400 Received: from fw.tj.unn.no ([193.157.66.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL6h2-0001zc-3X for discuss@apps.ietf.org; Wed, 06 Sep 2006 19:20:30 -0400 Received: from 193.157.66.5 (pounder.neutri.no [193.157.66.5]) (authenticated bits=0) by fw.tj.unn.no (8.13.1/8.13.1) with ESMTP id k86M3MFt024435 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 7 Sep 2006 00:03:25 +0200 Date: Thu, 7 Sep 2006 00:03:23 +0200 From: Terje Bless Subject: Re: Volunteer needed to serve as IANA charset reviewer To: Ted Hardie X-Priority: 3 In-Reply-To: <01M6VLE70BJ60008CX@mauve.mrochek.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith Prerelease X-Spam-Score: 1.6 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Thu, 07 Sep 2006 13:40:56 -0400 Cc: discuss@apps.ietf.org, Ned Freed , ietf-charsets@iana.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org [ My apologies for replying to a reply ] Ned Freed wrote: >>I wonder if we are reaching the point at which a stronger "use Unicode on >>the wire" recommendation would be in order. The implications of such a >>recommendation would presumably include a 2978bis that made the requireme= nts >>for registration of a new charset _much_ tougher, e.g., requiring a >>demonstration that the then-current version of Unicode cannot do the >>relevant job and/or evidence that the newly-proposed charset is needed in >>deployed applications. The time is, IMO, certainly ripe for pushing UTF-8 much stronger, but the p= lace to do so is *not* at IANA =E2=80=94 the registry of assigned names and numb= ers; protocol values =E2=80=94 but rather in the development of new specifications. Not even the Unicode Consortium envisions a mass conversation of all legacy content into, say, UTF-8. The IANA registry's documentary function is quite orthogonal to the desire to avoid defining new charsets or mandating or eve= n just enabling legacy charsets in new specifications. If a charset exists it should, modulo other factors, be registered with IAN= A. --=20 Everytime I write a rhyme these people thinks its a crime I tell `em what's on my mind. I guess I'm a CRIMINAL! I don't gotta say a word I just flip `em the bird and keep goin, I don't take shit from no one. I'm a CRIMINAL! From discuss-bounces@apps.ietf.org Thu Sep 07 13:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNs2-0004EJ-3u; Thu, 07 Sep 2006 13:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL74Y-0000ay-36 for discuss@apps.ietf.org; Wed, 06 Sep 2006 19:44:46 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL74W-0006hm-9U for discuss@apps.ietf.org; Wed, 06 Sep 2006 19:44:46 -0400 Received: by nf-out-0910.google.com with SMTP id m19so348802nfc for ; Wed, 06 Sep 2006 16:44:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hU+Rpn9VKbjEcjRsKLYvojjbnT/1WiwBgAftP8ent6j2MHgW520ekMdtch5DPJ+YSrOz9ZVj7TGTWPR38UmKEJNTxptt3kNsw42AIfkpEOHCDAEmhu0P2fC6KLU835rylnGZ8d67Hv3m9e7hCl52Kmw5nVS12wW3nBdWX8G3cpo= Received: by 10.49.8.4 with SMTP id l4mr1723805nfi; Wed, 06 Sep 2006 16:44:42 -0700 (PDT) Received: by 10.49.20.10 with HTTP; Wed, 6 Sep 2006 16:44:42 -0700 (PDT) Message-ID: <30b660a20609061644o56e49c9etfdf2f9f96e03d6fa@mail.gmail.com> Date: Wed, 6 Sep 2006 16:44:42 -0700 From: "Mark Davis" To: "Ned Freed" Subject: Re: Volunteer needed to serve as IANA charset reviewer In-Reply-To: <01M6VLE70BJ60008CX@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_200911_10740580.1157586282234" References: <01M6VLE70BJ60008CX@mauve.mrochek.com> X-Google-Sender-Auth: 24aca28e73949c50 X-Spam-Score: 0.3 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 X-Mailman-Approved-At: Thu, 07 Sep 2006 13:40:56 -0400 Cc: Ted Hardie , ietf-charsets@iana.org, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ------=_Part_200911_10740580.1157586282234 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline If the registry provided an unambiguous, stable definition of each charset identifier in terms of an explicit, available mapping to Unicode/10646 (whether the UTF-8 form of Unicode or the UTF-32 code points -- that is just a difference in format, not content), it would indeed be useful. However, I suspect quite strongly that it is a futile task. There are a number of problems with the current registry. 1. Poor registrations (minor) There are some registered charset names that are not syntactically compliant to the spec. 2. Incomplete (more important) There are many charsets (such as some windows charsets) that are not in the registry, but that are in *far* more widespread use than the majority of the charsets in the registry. Attempted registrations have just been left hanging, cf http://mail.apps.ietf.org/ietf/charsets/msg01510.html 2. Ill-defined registrations (crucial) a) There are registered names that have useless (inaccessable or unstable) references; there is no practical way to figure out what the charset definition is. b) There are other registrations that are defined by reference to an available chart, but when you actually test what the vendor's APIs map to, they actually *use* a different definition: for example, the chart may say that 0x80 is undefined, but actually map it to U+0080. c) The RFC itself does not settle important issues of identity among charsets. If a new mapping is added to a charset converter, is that a different charset (and thus needs a different registration) or not? Does that go for any superset? etc. We've raised these issues before, but with no resolution (or even attempt at one) Cf. http://dev.icu-project.org/cgi-bin/viewcvs.cgi/*checkout*/icuhtml/design/charset_questions.html As a product of the above problems, the actual results obtained by using the iana charset names on any given platform* may vary wildly. For example, among the iana-registry-named charsets, there were over a million different mapping differences between Sun's and IBM's Java, total. * "platform" speaking broadly -- ithe results may vary by OS (Mac vs Windows vs Linux...), by programming language [Java) or by version of programming language runtime (IBM vs Sun's Java), or even by product (database version). In ICU, for example, our requirement was to be able to reproduce the actual, observeable, character conversions in effect on any platform. With that goal, we basically had to give up trying to use the IANA registry at all. We compose mappings by scraping; calling the APIs on those platforms to do conversions and collecting the results, and providing a different internal identifier for any differing mapping. We then have a separate name mapping that goes from each platform's name (the name according to that platform) for each character to the unique identifier. Cf. http://icu.sourceforge.net/charts/charset/. And based on work here at Google, it is pretty clear that -- at least in terms of web pages -- little reliance can be placed on the charset information. As imprecise as heuristic charset detection is, it is more accurate than relying on the charset tags in the html meta element (and what is in the html meta element is more accurate than what is communicated by the http protocol). So while I applaud your goal, I would suspect that that it would be a huge amount of effort for very little return. Mark > I agree that we've reached a point where "use UTF-8" is what we need to be > pushing for in new protocol development. (Note that I said UTF-8 and not > Unicode - given the existance of gb18030 [*] I don't regard a recommendation of > "use Unicode" as even close to sufficient. The last thing we want is to see the > development of specializesd Unicode CESes for Korean, Japanese, Arabic, Hebrew, > Thai, and who knows what else.) And if the reason there are new charset > registrations was because of the perceived need to have new charsets for use in > new protocols, I would be in total agreement that a change in focus for charset > registration is in order. > > But that's not why we're seeing new registrations. The new registrations we're > seeing are of legacy charsets used in legacy applications and protocols that > for whatever reason never got registered previously. Given that these things > are in use in various nooks and crannies around the world, it is critically > important that when they are used they are labelled accurately and > consistently. > > The plain fact of the matter is that we have done a miserable job of producing > an accurate and useful charset registry, and considerable work needs to be done > both to register various missing charsets as well as to clean up the existing > registry, which contains many errors. I've seen no interest whatsoever in > registering new charsets for new protocols, so to my mind pushing back on, say, > the recent registration of iso-8859-11, is an overreaction to a non-problem. > [**] > > > This question is motivated, not by a strong love for Unicode, > > but by the observation that RFC 2277 requires it and that the > > IETF is shifting toward it in a number of areas. More options > > and possibilities for local codings that are not generally known > > and supported do not help with interoperability; perhaps it is > > time to start pushing back. > > Well, I have to say that to the extent we've pushed back on registrations, what > we've ended up with is ad-hoc mess of unregistered usage. I am therefore quite > skeptical of any belief that pushing back on registrations is a useful tactic. > > > And that, of course, would dramatically change the work of the > > charset reviewer by reducing the volume but increasing the > > amount of evaluation to be done. > > Even if we closed the registry completely there is still a bunch of work to do > in terms of registry cleanup. > > Now, having said all this, I'm willing to take on the role of charset reviewer, > but with the understanding that one of the things I will do is conduct a > complete overhaul of the existing registry. [***] Such a substantive change will > of course require some degree of oversight, which in turn means I'd like to see > some commitment from the IESG of support for the effort. > > As for qualifications, I did write the charset registration specification, and > I also wrote and continue to maintain a fairly full-features charset conversion > library. I can provide more detail if anyone cares. > > Ned > > [*] - For those not fully up to speed on this stuff, gb18030 can be seen as an > encoding of Unicode that is backwards compatible with the previous simplified > Chinese charsets gb2312 and gbk. > > [**] - The less recent attempt to register ISO-2022-JP-2004 is a more > interesting case. I believe this one needed to be pushed on, but not > because of potential use in new applications or protocols. > > [***] - I have the advantage of being close enough to IANA that I can drive > over there and have F2F meetings should the need arise - and I suspect > it will. > ------=_Part_200911_10740580.1157586282234 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline If the registry provided an unambiguous, stable definition of each charset identifier in terms of an explicit, available mapping to Unicode/10646 (whether the UTF-8 form of Unicode or the UTF-32 code points -- that is just a difference in format, not content), it would indeed be useful. However, I suspect quite strongly that it is a futile task. There are a number of problems with the current registry.

1. Poor registrations (minor)
There are some registered charset names that are not syntactically compliant to the spec.

2. Incomplete (more important)
There are many charsets (such as some windows charsets) that are not in the registry, but that are in *far* more widespread use than the majority of the charsets in the registry. Attempted registrations have just been left hanging, cf http://mail.apps.ietf.org/ietf/charsets/msg01510.html

2. Ill-defined registrations (crucial)
  a) There are registered names that have useless (inaccessable or unstable) references; there is no practical way to figure out what the charset definition is.
  b) There are other registrations that are defined by reference to an available chart, but when you actually test what the vendor's APIs map to, they actually *use* a different definition: for example, the chart may say that 0x80 is undefined, but actually map it to U+0080.
  c) The RFC itself does not settle important issues of identity among charsets. If a new mapping is added to a charset converter, is that a different charset (and thus needs a different registration) or not? Does that go for any superset? etc. We've raised these issues before, but with no resolution (or even attempt at one) Cf. http://dev.icu-project.org/cgi-bin/viewcvs.cgi/*checkout*/icuhtml/design/charset_questions.html

As a product of the above problems, the actual results obtained by using the iana charset names on any given platform* may vary wildly. For example, among the iana-registry-named charsets, there were over a million different mapping differences between Sun's and IBM's Java, total.

* "platform" speaking broadly -- ithe results may vary by OS (Mac vs Windows vs Linux...), by programming language [Java) or by version of programming language runtime (IBM vs Sun's Java), or even by product (database version).

In ICU, for example, our requirement was to be able to reproduce the actual, observeable, character conversions in effect on any platform. With that goal, we basically had to give up trying to use the IANA registry at all. We compose mappings by scraping; calling the APIs on those platforms to do conversions and collecting the results, and providing a different internal identifier for any differing mapping. We then have a separate name mapping that goes from each platform's name (the name according to that platform) for each character to the unique identifier. Cf. http://icu.sourceforge.net/charts/charset/.

And based on work here at Google, it is pretty clear that -- at least in terms of web pages -- little reliance can be placed on the charset information. As imprecise as heuristic charset detection is, it is more accurate than relying on the charset tags in the html meta element (and what is in the html meta element is more accurate than what is communicated by the http protocol).

So while I applaud your goal, I would suspect that that it would be a huge amount of effort for very little return.

Mark


> I agree that we've reached a point where "use UTF-8" is what we need to be
> pushing for in new protocol development. (Note that I said UTF-8 and not
> Unicode - given the existance of gb18030 [*] I don't regard a recommendation of
> "use Unicode" as even close to sufficient. The last thing we want is to see the
> development of specializesd Unicode CESes for Korean, Japanese, Arabic, Hebrew,
> Thai, and who knows what else.) And if the reason there are new charset
> registrations was because of the perceived need to have new charsets for use in
> new protocols, I would be in total agreement that a change in focus for charset
> registration is in order.
>
> But that's not why we're seeing new registrations. The new registrations we're
> seeing are of legacy charsets used in legacy applications and protocols that
> for whatever reason never got registered previously. Given that these things
> are in use in various nooks and crannies around the world, it is critically
> important that when they are used they are labelled accurately and
> consistently.
>
> The plain fact of the matter is that we have done a miserable job of producing
> an accurate and useful charset registry, and considerable work needs to be done
> both to register various missing charsets as well as to clean up the existing
> registry, which contains many errors. I've seen no interest whatsoever in
> registering new charsets for new protocols, so to my mind pushing back on, say,
> the recent registration of iso-8859-11, is an overreaction to a non-problem.
> [**]
>
> > This question is motivated, not by a strong love for Unicode,
> > but by the observation that RFC 2277 requires it and that the
> > IETF is shifting toward it in a number of areas.   More options
> > and possibilities for local codings that are not generally known
> > and supported do not help with interoperability; perhaps it is
> > time to start pushing back.
>
> Well, I have to say that to the extent we've pushed back on registrations, what
> we've ended up with is ad-hoc mess of unregistered usage. I am therefore quite
> skeptical of any belief that pushing back on registrations is a useful tactic.
>
> > And that, of course, would dramatically change the work of the
> > charset reviewer by reducing the volume but increasing the
> > amount of evaluation to be done.
>
> Even if we closed the registry completely there is still a bunch of work to do
> in terms of registry cleanup.
>
> Now, having said all this, I'm willing to take on the role of charset reviewer,
> but with the understanding that one of the things I will do is conduct a
> complete overhaul of the existing registry. [***] Such a substantive change will
> of course require some degree of oversight, which in turn means I'd like to see
> some commitment from the IESG of support for the effort.
>
> As for qualifications, I did write the charset registration specification, and
> I also wrote and continue to maintain a fairly full-features charset conversion
> library. I can provide more detail if anyone cares.
>
>                                 Ned
>
> [*] - For those not fully up to speed on this stuff, gb18030 can be seen as an
> encoding of Unicode that is backwards compatible with the previous simplified
> Chinese charsets gb2312 and gbk.
>
> [**] - The less recent attempt to register ISO-2022-JP-2004 is a more
> interesting case. I believe this one needed to be pushed on, but not
> because of potential use in new applications or protocols.
>
> [***] - I have the advantage of being close enough to IANA that I can drive
> over there and have F2F meetings should the need arise - and I suspect
> it will.
>
------=_Part_200911_10740580.1157586282234-- From discuss-bounces@apps.ietf.org Fri Sep 08 07:38:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLefN-0006Un-GJ; Fri, 08 Sep 2006 07:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLefM-0006Ui-G9 for discuss@apps.ietf.org; Fri, 08 Sep 2006 07:37:00 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLefI-0001PU-Lj for discuss@apps.ietf.org; Fri, 08 Sep 2006 07:37:00 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k88BamLj002600 for ; Fri, 8 Sep 2006 20:36:51 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7432_502eef42_3f2e_11db_9306_0014221fa3c9; Fri, 08 Sep 2006 20:36:48 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40230) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 8 Sep 2006 20:36:49 +0900 Message-Id: <6.0.0.20.2.20060908185538.04760c00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 08 Sep 2006 19:02:00 +0900 To: Keith Moore , Ned Freed From: Martin Duerst Subject: Re: Volunteer needed to serve as IANA charset reviewer In-Reply-To: <20060906174558.ff156501.moore@cs.utk.edu> References: <01M6VLE70BJ60008CX@mauve.mrochek.com> <20060906174558.ff156501.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: hardie@qualcomm.com, ietf-charsets@iana.org, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 06:45 06/09/07, Keith Moore wrote: >I concur with the need to maintain the current charset registry to >support legacy apps that use it. I concur with Keith (and it seems almost everybody else) that we still need a charset registry. >And I think Ned would be an excellent choice for reviewer, though it >wouldn' t bother me if he could have the assistance of people with >specialized expertise in Asian writing schemes. He would certainly have my assistance, for whatever it's worth. >As for utf-8 vs. Unicode, this is a bit tricky. I agree that merely >specifying Unicode isn't sufficient given the potential for >incompatible CESs. And yet I'm sympathetic to the notion that UTF-8 >pessimizes storage and transmission of text written in certain >languages. True. The most affected languages are not CJK (Chinese, Japanese, Korean), but all the scripts that have most of their characters beyond U+0800 but don't need two bytes to encode the particular script, i.e. all the Indian Scripts, and so on. A serious part of the overhead is often (but not always) compensated by the fact that protocol or markup information is usually heavily ascii-biased. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Sat Sep 09 02:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLwS5-0000sp-QI; Sat, 09 Sep 2006 02:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLwRz-0000LN-M3 for discuss@apps.ietf.org; Sat, 09 Sep 2006 02:36:23 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLwJE-0003GJ-2o for discuss@apps.ietf.org; Sat, 09 Sep 2006 02:27:23 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k896RHH4002056 for ; Sat, 9 Sep 2006 15:27:18 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 732b_3d3c878e_3fcc_11db_90af_0014221f2a2d; Sat, 09 Sep 2006 15:27:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51420) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 9 Sep 2006 15:27:11 +0900 Message-Id: <6.0.0.20.2.20060908190213.047611f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 09 Sep 2006 15:23:39 +0900 To: "Mark Davis" , "Ned Freed" From: Martin Duerst Subject: Problems (and non-problems) in charset registry (was: Re: Volunteer needed to serve as IANA charset reviewer) In-Reply-To: <30b660a20609061644o56e49c9etfdf2f9f96e03d6fa@mail.gmail.co m> References: <01M6VLE70BJ60008CX@mauve.mrochek.com> <30b660a20609061644o56e49c9etfdf2f9f96e03d6fa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Ted Hardie , discuss@apps.ietf.org, ietf-charsets@iana.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Mark, others, I think it's good to have such a collection of problems in the registry. But I think it's also fair to say that what Mark lists as problems may not in all cases actually be problems. At 08:44 06/09/07, Mark Davis wrote: >If the registry provided an unambiguous, stable definition of each charset identifier in terms of an explicit, available mapping to Unicode/10646 (whether the UTF-8 form of Unicode or the UTF-32 code points -- that is just a difference in format, not content), it would indeed be useful. However, I suspect quite strongly that it is a futile task. There are a number of problems with the current registry. I think the request for an explicit, fixed mapping is a good one, but in some cases, it would come at a high cost. A typical example is Shift_JIS: We know there are many variants, on the one hand due to additions made by makers (or even privately), on the other hand also due to some changes in the underlying standard (which go back to 1983). For an example like Shift_JIS, the question becomes whether we want to use a single label, or whether we want to carefully label each variant. Benefits for a single label: - Better chance that the recipient knows the label and can do something with it. - Better chance to teach people about different encodings (it's possible to teach people the difference between Shift_JIS, EUC-JP, and UTF-8, but it would be close to impossible to teach them about all the various variants) - No 'overlabeling' (being more precise than necessary, for the cases (the huge majority) where in the actual data, there is no difference). - Usually enough for visual decoding (reading of emails and Web pages by humans) - Not influenced by issues outside actual character encoding (e.g. error treatment of APIs) Benefits for detailled labeling: - Accurate data transmission for all data, even fringe cases - True round-trips for a wider range of scenarios - May be better suited for machine-to-machine processing >2. Incomplete (more important) >There are many charsets (such as some windows charsets) that are not in the registry, but that are in *far* more widespread use than the majority of the charsets in the registry. Attempted registrations have just been left hanging, cf http://mail.apps.ietf.org/ietf/charsets/msg01510.html Some of this is due to the original rather strict management of the registry. Some of it is due to the current backlog. A lot of this is due to the fact that nobody cares enough to work through the registration process; many people think that 'the IETF' or 'the IANA' will just do it. The solution is easy: Don't complain, register. >2. Ill-defined registrations (crucial) > a) There are registered names that have useless (inaccessable or unstable) references; there is no practical way to figure out what the charset definition is. This is possible; some of these registrations are probably irrelevant, for others, it's pretty clear what the charset means in general, even though there might be implementation differences for some codepoints. > b) There are other registrations that are defined by reference to an available chart, but when you actually test what the vendor's APIs map to, they actually *use* a different definition: for example, the chart may say that 0x80 is undefined, but actually map it to U+0080. It's clear that for really faulty charts, the vendors should be blamed, and not the registry. However, the difference between the published map and the actually used API may be due to the fact that 0x80 is indeed not part of the encoding as formally defined, and is mapped to U+0080 just as part of error treatment. For most applications (not for all necessarily), it would be a mistake to include error processing in the formal definition of an encoding. > c) The RFC itself does not settle important issues of identity among charsets. If a new mapping is added to a charset converter, is that a different charset (and thus needs a different registration) or not? Does that go for any superset? etc. We've raised these issues before, but with no resolution (or even attempt at one) Cf. http://dev.icu-project.org/cgi-bin/viewcvs.cgi/*checkout*/icuhtml/design/charset_questions.html It seems that what you would want, for your purposes, is to use a new label if a new character gets added to a legacy encoding, but not use a new label e.g. for UTF-8 each time a character gets added. So things would be somewhat case-by-case. >As a product of the above problems, the actual results obtained by using the iana charset names on any given platform* may vary wildly. For example, among the iana-registry-named charsets, there were over a million different mapping differences between Sun's and IBM's Java, total. It would be better to express these numbers in terms of percentages: In the experiment made, how many codepoints were mapped, and for how many did you get differences? Even better would be to express these numbers in terms of percentages of actual average data. My guess is that this would be much lower than the percentage of code points. This is in no way to belittle the problems, just to make sure we put it in proportions. >In ICU, for example, our requirement was to be able to reproduce the actual, observeable, character conversions in effect on any platform. With that goal, we basically had to give up trying to use the IANA registry at all. This is understandable. The start of the IANA registry was MIME, i.e. email. The goal was to be able to (ultimately visually) decode the characters at the other end. >We compose mappings by scraping; calling the APIs on those platforms to do conversions and collecting the results, and providing a different internal identifier for any differing mapping. We then have a separate name mapping that goes from each platform's name (the name according to that platform) for each character to the unique identifier. Cf. http://icu.sourceforge.net/charts/charset/. This is very thorough, and may look foolproof, but isn't. One issue already mentioned is error behavior. If a first API maps an undefined character to some codepoint, and a second API maps it to another codepoint (or sequence), they just made different decision for error behavior (e.g. mapping unknown codepoints to '?' or to one of the substitution characters, or dropping them,...). This would be particularly prominent when converting from Unicode to a legacy encoding, because in this case there are tons of codepoints that can't be converted. But this most probably should not be part of the definition of a 'charset'. Also, There are cases where there are no differences in transcoding, but font differences. Examples are the treatment of the backslash character on MS Windows systems (shown as a Yen symbol because most (Unicode!) fonts on Japanese Windows systems have it that way, or certain cases where the traditional and (Japanese) simplified variant of a character got exchanged when moving from the 1978 to the 1983 version of the standard. >And based on work here at Google, it is pretty clear that -- at least in terms of web pages -- little reliance can be placed on the charset information. Yes, but this is a problem on a diffent level than the above. Above, you are speaking about small variant differences. Here, you are speaking about completely mislabled pages. The problems with small variants don't make the labels in the registry unsuitable for labeling Web pages. Most Web pages don't contain characters where the minor version differences matter, because private use and corporate characters don't work well on the Web, and because some of the transcoding differences are between e.g. full-width and half-width variants, which are mostly irrelevant for viewing and in particular for search. >As imprecise as heuristic charset detection is, it is more accurate than relying on the charset tags in the html meta element (and what is in the html meta element is more accurate than what is communicated by the http protocol). This sounds reasonable. >So while I applaud your goal, I would suspect that that it would be a huge amount of effort for very little return. There are other protocols, in particular email. My understanding is that for email, the situation is quite a bit better, because people use a dedicated tool (their MUA) to write emails, and emails rarely get transcoded on the character level, and there is no server involved, whereas users use whatever they can get their hands on to create Web pages, the server can mess things up (or help, in some cases), and pages may get transcoded. A reasonable conclusion from the above is that no size fits all. Many applications may be very well served with the granularity of labels we have now. Some others may need more granularity. We would either have to decide that we stay with the current granularity, or that we maybe move to a system with multiple levels of granularity. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Sat Sep 09 10:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM3fr-0000Ic-F0; Sat, 09 Sep 2006 10:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM3fq-0000IS-GY for discuss@apps.ietf.org; Sat, 09 Sep 2006 10:19:10 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM3fn-0003kM-Id for discuss@apps.ietf.org; Sat, 09 Sep 2006 10:19:10 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6ZE62674W00L6IM@mauve.mrochek.com> for discuss@apps.ietf.org; Sat, 9 Sep 2006 07:19:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6ZC7MMVC00008CX@mauve.mrochek.com>; Sat, 09 Sep 2006 07:18:57 -0700 (PDT) To: Martin Duerst Message-id: <01M6ZE60BOFW0008CX@mauve.mrochek.com> Date: Sat, 09 Sep 2006 06:39:06 -0700 (PDT) From: Ned Freed Subject: Re: Problems (and non-problems) in charset registry (was: Re: Volunteer needed to serve as IANA charset reviewer) In-reply-to: "Your message dated Sat, 09 Sep 2006 15:23:39 +0900" <6.0.0.20.2.20060908190213.047611f0@localhost> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01M6VLE70BJ60008CX@mauve.mrochek.com> <30b660a20609061644o56e49c9etfdf2f9f96e03d6fa@mail.gmail.com> <6.0.0.20.2.20060908190213.047611f0@localhost> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Ted Hardie , discuss@apps.ietf.org, Ned Freed , ietf-charsets@iana.org, Mark Davis X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Hello Mark, others, > I think it's good to have such a collection of problems in the registry. > But I think it's also fair to say that what Mark lists as problems may > not in all cases actually be problems. I agree. I also think that there's a bunch of low-hanging fruit here: Many (but certainly not all) of the registry problems can be fixed without a huge investment of time and effort. Once the obvious stuff is addressed we can discuss how far we want to go, especially in regards to versioning, variant tagging, and so on. But let's please not get bogged down in the hard stuff before dealing with the easy stuff. > > If the registry provided an unambiguous, stable definition of each charset > > identifier in terms of an explicit, available mapping to Unicode/10646 > > (whether the UTF-8 form of Unicode or the UTF-32 code points -- that is > > just a difference in format, not content), it would indeed be useful. > > However, I suspect quite strongly that it is a futile task. There are a > > number of problems with the current registry. > I think the request for an explicit, fixed mapping is a good one, > but in some cases, it would come at a high cost. A typical example > is Shift_JIS: We know there are many variants, on the one hand due > to additions made by makers (or even privately), on the other hand > also due to some changes in the underlying standard (which go back > to 1983). > For an example like Shift_JIS, the question becomes whether > we want to use a single label, or whether we want to carefully > label each variant. Exactly so. And I would provose that we defer worrying about such tricky issues until the obvious stuff is done. It is always important not to let the best be the enemy of the good. > >2. Incomplete (more important) > > There are many charsets (such as some windows charsets) that are not in the > > registry, but that are in *far* more widespread use than the majority of the > > charsets in the registry. Attempted registrations have just been left > > hanging, cf http://mail.apps.ietf.org/ietf/charsets/msg01510.html > Some of this is due to the original rather strict management of the registry. > Some of it is due to the current backlog. A lot of this is due to the fact > that nobody cares enough to work through the registration process; many > people think that 'the IETF' or 'the IANA' will just do it. The solution > is easy: Don't complain, register. And reviewing registration applications in a timely way might help encourage more registration activitiy. > > 2. Ill-defined registrations (crucial) > > a) There are registered names that have useless (inaccessable or unstable) > > references; there is no practical way to figure out what the charset definition > > is. > This is possible; some of these registrations are probably irrelevant, > for others, it's pretty clear what the charset means in general, even > though there might be implementation differences for some codepoints. Well said. If nobody can figure out anything about a charset in the registry, that's a pretty good indication that it's irrlevant at least in terms of current usage. I suspect quite a few of the incomplete entries fall into this category. > > b) There are other registrations that are defined by reference to an > > available chart, but when you actually test what the vendor's APIs map to, they > > actually *use* a different definition: for example, the chart may say that 0x80 > > is undefined, but actually map it to U+0080. > It's clear that for really faulty charts, the vendors should be blamed, > and not the registry. Well, to be fair, vendors sometimes add wierd mappings in response to customer demand. For example, I've seen codepoints specific to some Microsoft variant of a national standard charset creep into usage of the standard charset. In such cases what's a vendor to do when they have a bunch of customers saying "we don't care what the standard is, either add these codepoints or we'll switch to the competitor's product that does do this"? > However, the difference between the published map and the > actually used API may be due to the fact that 0x80 is indeed not > part of the encoding as formally defined, and is mapped to U+0080 > just as part of error treatment. For most applications (not for > all necessarily), it would be a mistake to include error processing > in the formal definition of an encoding. Yes, that's an issue too. I've observed wide variations in the handling of unassigned code points by different converters. > > c) The RFC itself does not settle important issues of identity among > > charsets. If a new mapping is added to a charset converter, is that a different > > charset (and thus needs a different registration) or not? Does that go for any > > superset? etc. We've raised these issues before, but with no resolution (or > > even attempt at one) Cf. http://dev.icu-project.org/cgi-bin/viewcvs.cgi/*checkout*/icuhtml/design/charset_questions.html > It seems that what you would want, for your purposes, is to use a new > label if a new character gets added to a legacy encoding, but not use > a new label e.g. for UTF-8 each time a character gets added. > So things would be somewhat case-by-case. I agree - I don't think it is possible to codify a single "best practice" to handle every case here. > > As a product of the above problems, the actual results obtained by using the > > iana charset names on any given platform* may vary wildly. For example, among > > the iana-registry-named charsets, there were over a million different mapping > > differences between Sun's and IBM's Java, total. > It would be better to express these numbers in terms of percentages: > In the experiment made, how many codepoints were mapped, and for how many > did you get differences? > Even better would be to express these numbers in terms of percentages > of actual average data. My guess is that this would be much lower than > the percentage of code points. It certainly better be or thing must not be working very well somewhere! > This is in no way to belittle the problems, just to make sure we put > it in proportions. Right. > > In ICU, for example, our requirement was to be able to reproduce the actual, > > observeable, character conversions in effect on any platform. With that goal, > > we basically had to give up trying to use the IANA registry at all. > This is understandable. The start of the IANA registry was MIME, i.e. > email. The goal was to be able to (ultimately visually) decode the > characters at the other end. And that tends to drive various tradeoffs in a particular direction. For example, it tends to argue for fewer tags for minor charset variations because that's easier to deploy and update. > ... > >And based on work here at Google, it is pretty clear that -- at least in > > terms of web pages -- little reliance can be placed on the charset information. > Yes, but this is a problem on a diffent level than the above. > Above, you are speaking about small variant differences. > Here, you are speaking about completely mislabled pages. I don't see any way we can fix the mislabelling problem (which also exists in email but takes on a somewhat different form there) in any direct way. However, to the extent that mislabelling has occured due to people getting confused by our current registry mess, cleaning our own house might help a little. But probably not much - a site that labels every message they send as iso-8859-1 no matter what's actually in the message (and I've seen some big ones that do this) isn't going to be cured by our having a perfectly accurate and totally comprehensive registry. Like it or not, we cannot fix everything here. > The problems with small variants don't make the labels in > the registry unsuitable for labeling Web pages. Most Web > pages don't contain characters where the minor version > differences matter, because private use and corporate > characters don't work well on the Web, and because some > of the transcoding differences are between e.g. full-width > and half-width variants, which are mostly irrelevant for > viewing and in particular for search. I've observed similar behavior in email. People are pretty adaptable and tend to figure out what works and what doesn't fairly quickly. > >So while I applaud your goal, I would suspect that that it would be a huge amount of effort for very little return. > There are other protocols, in particular email. My understanding is > that for email, the situation is quite a bit better, because people > use a dedicated tool (their MUA) to write emails, and emails rarely > get transcoded on the character level, and there is no server involved, > whereas users use whatever they can get their hands on to create > Web pages, the server can mess things up (or help, in some cases), > and pages may get transcoded. To be honest, it is hard for me to judge whether the situation for email is better or worse than for the web or other protocols. Since I work on email systems a lot more than I work on other stuff, I tend to see reports of lots more problems with email. But this is probably more the result of being on the receiving end of bug reports for email while not being on the receiving end of bug reports for, say, a web client. In any case, the Internet is now such a big place with so many nooks and crannies that I have no idea how you'd figure out where the worst problems are. And I'm not sure it matters either. Ned From discuss-bounces@apps.ietf.org Fri Sep 29 14:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMoQ-00034f-WF; Fri, 29 Sep 2006 14:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTMoQ-00034a-4b for discuss@apps.ietf.org; Fri, 29 Sep 2006 14:10:14 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTMoO-00066F-Fe for discuss@apps.ietf.org; Fri, 29 Sep 2006 14:10:14 -0400 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8AA5214231B for ; Fri, 29 Sep 2006 11:10:03 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13917-06 for ; Fri, 29 Sep 2006 11:10:02 -0700 (PDT) Received: from [10.1.1.210] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A70F6142319 for ; Fri, 29 Sep 2006 11:10:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: discuss@apps.ietf.org Message-Id: <680AEFDB-32CA-40D1-9165-C140F973A8BE@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-12-857574823 References: <0972D5B8-16C3-4983-AF63-C9C63CA75ECB@osafoundation.org> From: Lisa Dusseault Subject: Fwd: Lisa's September Apps Area Activity Date: Fri, 29 Sep 2006 11:10:01 -0700 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-12-857574823 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Let me know (privately) if I should routinely send this to the Apps discuss list, or not! thx, Lisa Begin forwarded message: > From: Lisa Dusseault > Date: September 29, 2006 11:06:50 AM PDT > To: lisa-dusseault-chairs@tools.ietf.org > Subject: Lisa's September Apps Area Activity > > > Planning for San Diego: > - Need Apps Area meeting agenda. Any announcements? Tech topics? > - One possible BoF for San Diego: HTTP (2616 and 2617) revisions > - WG meetings in San Diego: SIEVE, CALSIFY, WIDEX, IMAPEXT. > > Document Status and progress > > PUBLISHED documents this month: > - RFC 4685: Atom Threading Extensions (individual submission) > - Also note RFCs 4645-4647 on language tagging -- do you need to > update your references? > > APPROVED documents this month: > - draft-ietf-sieve-spamtestbis > > Documents in IETF Last Call: > - draft-ietf-usefor-usefor-10, Usenet article format revision: > Issue raised so far on subsetting and supersetting RFC2822 > > Documents needing new versions: > - One month stale: draft-ietf-imapext-annotate: New version needed > to address Alexey's issues from Last Call. > - draft-melnikov-imap-expunged-01.txt: Last call raised questions > which may be resolved with list discussion, ongoing, as well as > clearer text about requirements for state maintenance on the server. > - draft-snell-atompub-feed-license-08.txt : IETF Last call raised > issues about scope of license. > - draft-ietf-imapext-i18n-06.txt: Probably should be resurrected > now that comparator is nearly out the door > > Documents in IESG Evaluation: > - draft-newman-i18n-comparator: Waiting for Ted to review his > DISCUSS issue resolutions > - draft-ietf-imapext-sort: Waiting for comparator to be approved. > Need to double-check if changes needed. > - draft-jennings-impp-vcard-08.txt: Waiting for Ted to review his > DISCUSS issues resolutions > - draft-kunze-rfc2413bis (Informational, RFC Ed Submission): on > next agenda. > - draft-ietf-imapext-list-extensions: Waiting for Bill Fenner to > review his DISCUSS issue resolutions > > Working Group Activity > > AtomPub: did a WG last call on Atom Publishing Protocol. > UseFor: Publication requested on Usenet Article Format specification. > IMAPExt: Discussing Expunge document. > Sieve: Discussing UTF8 escaping issues. > Calsify: Steadily resolving issues for revision of RFC2445. > Widex: Where are you guys? > > Other Activity > > Apps Architecture Review Team : No documents reviewed yet > Apps Discuss list: great discussion on TV URIs (the instigators > will come back with many suggestions incorporated) > W3C related activity: WGs proposed to revise XML DSig, and to > address Web phishing (e.g. through Web browser GUI recommendations) > --Apple-Mail-12-857574823 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Let me know (privately)=A0 if I = should routinely send this to the Apps discuss list, or not!

thx,
Lisa
<= BR>
Begin forwarded message:

From: = Lisa Dusseault <lisa@osafoundation.org>
Date: September 29, 2006 11:06:50 AM = PDT
Subject: Lisa's September Apps = Area Activity


Planning for San = Diego:=A0
- Need Apps Area meeting agenda.=A0= Any announcements? Tech topics?
- One possible BoF for San Diego: = HTTP (2616 and 2617) revisions
- WG meetings in San Diego: = SIEVE, CALSIFY, WIDEX, IMAPEXT.

Document Status and = progress

PUBLISHED documents = this month:=A0
- RFC = 4685: Atom Threading Extensions (individual = submission)
- Also note RFCs 4645-4647 on = language tagging -- do you need to update your references?

APPROVED documents this = month:
= - draft-ietf-sieve-spamtestbis

Documents in IETF Last = Call:
= -=A0draft-ietf-usefor-usefor-10, Usenet article format revision: = Issue raised so far on subsetting and supersetting RFC2822

Documents needing new = versions:
- One = month stale:=A0draft-ietf-imapext-annotate: New version needed to = address Alexey's issues from Last Call.
= -=A0draft-melnikov-imap-expunged-01.txt: Last call raised = questions which may be resolved with list discussion, ongoing, as well = as clearer text about requirements for state maintenance on the = server.
= -=A0draft-snell-atompub-feed-license-08.txt=A0: IETF Last call = raised issues about scope of license.
= -=A0draft-ietf-imapext-i18n-06.txt: Probably should be = resurrected now that comparator is nearly out the door

Documents in IESG = Evaluation:
-=A0draft-newman-i18n-comparator: = Waiting for Ted to review his DISCUSS issue resolutions
- = draft-ietf-imapext-sort: Waiting for comparator to be approved.=A0 Need = to double-check if changes needed.
= -=A0draft-jennings-impp-vcard-08.txt: Waiting for Ted to review = his DISCUSS issues resolutions
-=A0draft-kunze-rfc2413bis = (Informational, RFC Ed Submission): on next = agenda.
= -=A0draft-ietf-imapext-list-extensions: Waiting for Bill Fenner = to review his DISCUSS issue resolutions

Working Group = Activity=A0

AtomPub:=A0 did a WG = last call on Atom Publishing Protocol.
UseFor: Publication = requested on Usenet Article Format specification.
IMAPExt: = Discussing Expunge document.
Sieve: Discussing UTF8 escaping = issues.
Calsify: Steadily resolving issues for revision of = RFC2445.
Widex:=A0 Where are you guys?

Other = Activity

Apps Architecture = Review Team : No documents reviewed yet
Apps Discuss list: = great discussion on TV URIs (the instigators will come back with many = suggestions incorporated)
W3C related activity: WGs proposed = to revise XML DSig, and to address Web phishing (e.g. through Web = browser GUI recommendations)


= --Apple-Mail-12-857574823--