From owner-idn@ops.ietf.org Thu May 2 06:13:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06988 for ; Thu, 2 May 2002 06:13:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173DEt-0007jG-00 for idn-data@psg.com; Thu, 02 May 2002 02:51:03 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 173DAD-0007f3-00 for idn@ops.ietf.org; Thu, 02 May 2002 02:46:14 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26620; Thu, 2 May 2002 02:46:11 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g429k6g10427; Thu, 2 May 2002 11:46:07 +0200 (MEST) Date: Thu, 2 May 2002 09:13:37 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] nameprep vs. stringprep To: "Eric A. Hall" Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <3CCED264.4277645F@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > I'll have to wait to see what the impact of this change is, but on the > surface, the immediate affect will be that this draft will no longer be > able to encourage the creation of stringprep profiles for specific > resource record owner names and RR data. Until now, domain names which > require syntaxes that were not compatible with nameprep could create their > own stringprep profiles, but if the prohibitions go into stringprep, then > these domain names will have to be defined separately from the stringprep > family altogether. At that point, I'm not sure what value stringprep has > over just going back to a monolithic nameprep. Eric, The above is not the intent. The intent is that stringprep define a bunch of tables and the stringprep profile then selects which table(s) of prohibited characters and mappings it want to use from stringprep. And if need be a stringprep profile can also add its own prohibitions and mappings although. Hence we get easier reuse of the tables of code points - nothing more and nothing less. Erik From owner-idn@ops.ietf.org Thu May 2 07:32:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13700 for ; Thu, 2 May 2002 07:32:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173Egs-000A5t-00 for idn-data@psg.com; Thu, 02 May 2002 04:24:02 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 173Egr-000A5n-00 for idn@ops.ietf.org; Thu, 02 May 2002 04:24:01 -0700 Message-ID: <000d01c1f1cc$6fef4a20$287a4b0a@neteka.inc> From: "Edmon Chung" To: "Erik Nordmark" , "Eric A. Hall" Cc: "Erik Nordmark" , References: Subject: Re: [idn] nameprep vs. stringprep Date: Thu, 2 May 2002 07:27:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Erik Nordmark" > The intent is that stringprep define a bunch of tables and the stringprep > profile then selects which table(s) of prohibited characters and mappings > it want to use from stringprep. And if need be a stringprep profile can > also add its own prohibitions and mappings although. > > Hence we get easier reuse of the tables of code points - nothing more > and nothing less. So you mean Stringprep will actually contain all the tables and then Nameprep would be a profile that chooses which table to use? So essentially, stringprep will be sort of like a general framework plus a mapping table repository. I think this makes sense. If this is so, why dont we also put in the mapping tables created by the CJK communities respectively on their particular issues (including jpchar hangulchar and tsconv) into the Stringprep respository? Nameprep will not need to choose these tables, while people can get the information from those valuable discussions at a common place and decide whether to implement it themselves. Thoughts? Edmon From owner-idn@ops.ietf.org Thu May 2 08:27:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18089 for ; Thu, 2 May 2002 08:27:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173FXM-000BbE-00 for idn-data@psg.com; Thu, 02 May 2002 05:18:16 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 173FXL-000Bb8-00 for idn@ops.ietf.org; Thu, 02 May 2002 05:18:15 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17243; Thu, 2 May 2002 08:18:11 -0400 (EDT) Message-Id: <200205021218.IAA17243@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-hoffman-stringprep-02.txt Date: Thu, 02 May 2002 08:18:10 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Preparation of Internationalized Strings ('stringprep') Author(s) : P. Hoffman, M. Blanchet Filename : draft-hoffman-stringprep-02.txt Pages : Date : 01-May-02 This document describes a framework for preparing text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoffman-stringprep-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hoffman-stringprep-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hoffman-stringprep-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-hoffman-stringprep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141355.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu May 2 08:27:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18102 for ; Thu, 2 May 2002 08:27:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173FXh-000BbN-00 for idn-data@psg.com; Thu, 02 May 2002 05:18:37 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 173FXg-000BbH-00 for idn@ops.ietf.org; Thu, 02 May 2002 05:18:37 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17343; Thu, 2 May 2002 08:18:32 -0400 (EDT) Message-Id: <200205021218.IAA17343@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-09.txt Date: Thu, 02 May 2002 08:18:32 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Nameprep: A Stringprep Profile for Internationalized Domain Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-09.txt Pages : Date : 01-May-02 This document describes how to prepare internationalized domain name labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-nameprep-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-nameprep-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-nameprep-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-nameprep-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141443.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu May 2 10:04:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27413 for ; Thu, 2 May 2002 10:04:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173H24-000EWi-00 for idn-data@psg.com; Thu, 02 May 2002 06:54:04 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 173H24-000EWW-00 for idn@ops.ietf.org; Thu, 02 May 2002 06:54:04 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25869; Thu, 2 May 2002 07:54:00 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g42Drtg01714; Thu, 2 May 2002 15:53:56 +0200 (MEST) Date: Thu, 2 May 2002 15:53:16 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] nameprep vs. stringprep To: Edmon Chung Cc: Erik Nordmark , "Eric A. Hall" , idn@ops.ietf.org In-Reply-To: "Your message with ID" <000d01c1f1cc$6fef4a20$287a4b0a@neteka.inc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > If this is so, why dont we also put in the mapping tables created by the CJK > communities respectively on their particular issues (including jpchar > hangulchar and tsconv) into the Stringprep respository? Nameprep will not > need to choose these tables, while people can get the information from those > valuable discussions at a common place and decide whether to implement it > themselves. The tables currently in stringprep are only those that are going be used by an IETF standard. Thus as more IETF standards do I18N and need more stringprep profiles, stringprep might need additional tables. But adding tables to stringprep before there is an intended use for them seems problematic - the IETF would have no criteria for what tables would or would not go into stringprep. Erik From owner-idn@ops.ietf.org Thu May 2 11:17:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05202 for ; Thu, 2 May 2002 11:17:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173I7n-000HhL-00 for idn-data@psg.com; Thu, 02 May 2002 08:04:03 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 173I7m-000HhF-00 for idn@ops.ietf.org; Thu, 02 May 2002 08:04:02 -0700 Message-ID: <005601c1f1eb$2b23a750$287a4b0a@neteka.inc> From: "Edmon Chung" To: "Erik Nordmark" Cc: "Erik Nordmark" , "Eric A. Hall" , References: Subject: Re: [idn] nameprep vs. stringprep Date: Thu, 2 May 2002 11:07:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agreed... but not convinced that the CJK tables do not have an "intended" use. At least the T/SC table is already actively being used by a couple of domain operators. Edmon ----- Original Message ----- From: "Erik Nordmark" To: "Edmon Chung" > > If this is so, why dont we also put in the mapping tables created by the CJK > > communities respectively on their particular issues (including jpchar > > hangulchar and tsconv) into the Stringprep respository? Nameprep will not > > need to choose these tables, while people can get the information from those > > valuable discussions at a common place and decide whether to implement it > > themselves. > > The tables currently in stringprep are only those that are going > be used by an IETF standard. Thus as more IETF standards do I18N > and need more stringprep profiles, stringprep might need additional > tables. > > But adding tables to stringprep before there is an intended use for them > seems problematic - the IETF would have no criteria for what tables would > or would not go into stringprep. > > Erik > > > From owner-idn@ops.ietf.org Thu May 2 11:33:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06701 for ; Thu, 2 May 2002 11:33:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173IPB-000IKJ-00 for idn-data@psg.com; Thu, 02 May 2002 08:22:01 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 173IPA-000IKD-00 for idn@ops.ietf.org; Thu, 02 May 2002 08:22:01 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 90801; Thu, 02 May 2002 10:21:53 -0500 Message-ID: <3CD15992.B0A93047@ehsco.com> Date: Thu, 02 May 2002 10:21:54 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] nameprep vs. stringprep References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > The intent is that stringprep define a bunch of tables and the stringprep > profile then selects which table(s) of prohibited characters and mappings > it want to use from stringprep. And if need be a stringprep profile can > also add its own prohibitions and mappings although. Thanks for the clarification -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 2 11:48:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08109 for ; Thu, 2 May 2002 11:48:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173IiT-000J1Y-00 for idn-data@psg.com; Thu, 02 May 2002 08:41:57 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #1) id 173IiT-000J1S-00 for idn@ops.ietf.org; Thu, 02 May 2002 08:41:57 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GVHQ9V00.U07; Thu, 2 May 2002 11:41:55 -0400 Message-ID: <005701c1f1ef$cc93ca80$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: "Edmon Chung" , "Erik Nordmark" Cc: "Eric A. Hall" , References: <005601c1f1eb$2b23a750$287a4b0a@neteka.inc> Subject: Re: [idn] nameprep vs. stringprep Date: Thu, 2 May 2002 08:41:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edmon Chung wrote: > Agreed... but not convinced that the CJK tables do not have an "intended" > use. At least the T/SC table is already actively being used by a couple of > domain operators. Ah, see, I knew that was the intent all along. This is another attempt to force IDN to perform 1-to-1 TC/SC mapping by having IETF "publish" the proposed table in the stringprep document and then insisting that IDN implement the conversions specified in the "official" table. TC/SC equivalence is not 1-to-1. Implementations that pretend that it is will confuse and mislead Chinese speakers who expect true, context-based equivalence. Domain operators who implement 1-to-1 TC/SC mapping tables are out of conformance with the IDN proposal. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Thu May 2 12:59:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14409 for ; Thu, 2 May 2002 12:59:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173Jof-000LQ0-00 for idn-data@psg.com; Thu, 02 May 2002 09:52:25 -0700 Received: from mail.imc.org ([208.184.76.43] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 173Jof-000LPu-00 for idn@ops.ietf.org; Thu, 02 May 2002 09:52:25 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42GqLa02226 for ; Thu, 2 May 2002 09:52:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3CD15992.B0A93047@ehsco.com> References: <3CD15992.B0A93047@ehsco.com> Date: Thu, 2 May 2002 09:51:29 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] nameprep vs. stringprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk And, as folks can see on the list, the drafts with the tables moved have been published. As far as we know, there is literally no change for the IDN WG with these new drafts from the previous ones. The exact same characters are mapped and prohibited. If we made a mistake in this, by all means let us know. The only significant change that will affect other WGs that use stringprep is that only Unicode normalization form KC is specified. Our thinking is that if we specified both NFC and NFKC, we would need many more tables and there is a much higher chance of error. No one has given a strong argument for using NFC, other than objections to some of the mappings in NFKC, which cannot be changed by the Unicode Consortium without breaking a lot of deployed software. If other working groups want us to allow NFC and create and check the additional tables, we will probably hear about it during IETF last call. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu May 2 22:35:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23392 for ; Thu, 2 May 2002 22:35:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173Sak-000Era-00 for idn-data@psg.com; Thu, 02 May 2002 19:14:38 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 173Sak-000ErU-00 for idn@ops.ietf.org; Thu, 02 May 2002 19:14:38 -0700 Message-ID: <001c01c1f248$da42c2e0$287a4b0a@neteka.inc> From: "Edmon Chung" To: "Doug Ewell" , "Erik Nordmark" Cc: "Eric A. Hall" , References: <005601c1f1eb$2b23a750$287a4b0a@neteka.inc> <005701c1f1ef$cc93ca80$fa424244@anhmca.adelphia.net> Subject: Re: [idn] nameprep vs. stringprep Date: Thu, 2 May 2002 22:18:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I dont think this is an intent to "force" TC/SC mapping, I just think that it would be a good repository for work done that is meaningful for the community. Edmon ----- Original Message ----- From: "Doug Ewell" To: "Edmon Chung" ; "Erik Nordmark" Cc: "Eric A. Hall" ; Sent: Thursday, May 02, 2002 11:41 AM Subject: Re: [idn] nameprep vs. stringprep > Edmon Chung wrote: > > > Agreed... but not convinced that the CJK tables do not have an > "intended" > > use. At least the T/SC table is already actively being used by a > couple of > > domain operators. > > Ah, see, I knew that was the intent all along. This is another attempt > to force IDN to perform 1-to-1 TC/SC mapping by having IETF "publish" > the proposed table in the stringprep document and then insisting that > IDN implement the conversions specified in the "official" table. > > TC/SC equivalence is not 1-to-1. Implementations that pretend that it > is will confuse and mislead Chinese speakers who expect true, > context-based equivalence. Domain operators who implement 1-to-1 TC/SC > mapping tables are out of conformance with the IDN proposal. > > -Doug Ewell > Fullerton, California > > > From owner-idn@ops.ietf.org Fri May 3 15:13:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25241 for ; Fri, 3 May 2002 15:13:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173iHY-0008CX-00 for idn-data@psg.com; Fri, 03 May 2002 11:59:52 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 173iHY-0008CR-00 for idn@ops.ietf.org; Fri, 03 May 2002 11:59:52 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06917 for ; Fri, 3 May 2002 12:59:54 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g43Ixlg28346 for ; Fri, 3 May 2002 20:59:47 +0200 (MEST) Date: Fri, 3 May 2002 20:59:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] Editorial comments on punycode To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk draft-ietf-idn-punycode-01.txt ------------------------------ I've reviewed the punycode document to make sure it is ready for IETF last call. Here are some editorial comments that it would be useful to fix before the last call. Overall the document looks very good. The introduction of "bootstring" in the abstract is a bit odd - almost made me look for bootstring in the references section. Saying "This document defines bootstring as a general algorithm ..." is more clear. Section 4 talks about mixed-case annotations but it hasn't been mentioned earlier in the document - a bit surprising to the reader. Thus it would be good to introduce this optional possibility earlier in the document. E.g. in section 1.2 stating that this optional capability exists in the algorithm but that it isn't needed for IDNA. Section 6.2 says at the end what the decoder need not re-encode its output. Why would it ever need that? I think there is some context missing but I can't guess what that context is. Section 6.3 talks about overflow - but is the information in that paragraph common to the decoder and encoder? (The text lives only in the encoder section.) If not what are the size requirements for the integer data type for the decoder? Section 7.1 talks about "the IDNA signature prefix" but the IDNA spec uses the term "ACE prefix". Split normative vs. non-normative references. --- From owner-idn@ops.ietf.org Fri May 3 15:14:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25273 for ; Fri, 3 May 2002 15:14:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173iHh-0008Cu-00 for idn-data@psg.com; Fri, 03 May 2002 12:00:01 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 173iHf-0008Ck-00 for idn@ops.ietf.org; Fri, 03 May 2002 11:59:59 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09261 for ; Fri, 3 May 2002 12:59:58 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g43Ixpg28350 for ; Fri, 3 May 2002 20:59:52 +0200 (MEST) Date: Fri, 3 May 2002 20:59:09 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] Editorial comments on idna To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk draft-ietf-idn-idna-07.txt ---------------------- I've reviewed the idna document to make sure it is ready for IETF last call. Here are some editorial comments that it would be useful to fix before the last call. I've read the document thinking about what an implementor of an application needs to understand and know in order to enable IDN in the app. The introduction makes sense for those that have participated on the IDN mailing list. Unfortunately it doesn't do a good job of introducing things for the first time reader. Assume that Joe/Jane application implementor is going to read this. What would they need to know up front to help them understand what they need to do where in the applications? I think this can be done with an introduction that is 1-2 pages long. But it needs to start stating the problem a bit. And the dangling reference to "other proposals" don't make any sense for such a reader. Perhaps even the picture in section 6 can be moved to the introduction. Even better to split that picture into two pictures - one "before" and one "after" adding IDN support to the application. Section 4 and the ToASCII and ToUnicode algorithms in general operate on labels but the application cares about domain names. I don't think it is sufficient to tell the poor application programmer "do this for each label" without saying how to extract the labels from the domain name. I assume this algorithm just consists of looking for U+002E in the input strings. However, in order to be consistent with the text in section 5.1 in nameprep I think IDNA should say that the labels should be separated at U+3002 as well as U+002E. Section 6 doesn't mention that the application needs to set the "host name syntax rule" flag. Section 6 doesn't mention that the application needs to set the "prohibit unassigned" flag. What is needed here is just some text to make it clear that the application needs to do *something*. Example text would be: When the application is handling a domain name for which the host name syntax checks should apply (which is the common case) the application needs to set the "host name syntax" flag when using ToASCII/ToUnicode. When the domain name is stored the application needs to set the "prohibit unassigned" flag when using ToASCII/ToUnicode. [and similarly for the inverse] The abstract could be improved by adding the benefit of using a representation into the same octets e.g. by adding This representation allows IDNs to be introduced with minimal changes to the existing DNS infrastructure. Section 2: Is there a reference for US-ASCII that can be added? Section 2: host name vs. domain name. I think it makes sense to add "In this document we use the term "domain name" in general, and when referring explicitly to the syntax restrictions in [STD3] we use the term "host name syntax". Section 2" IDN definition. I don't think the last sentence about "name handling bodies" is part of the definition. Is there a better home for that statement somewhere else in the document? Section 2: Internationalized Label I think the definition for "ACE label" should be broken out as being its own paragraph. Also, the ACE definition should be explicit that the ACE label includes the ACE prefix (which is what punycode states). Section 2: I find it odd that the "generic domain name slot" is less generic than the "internationalized domain name slot". Is there a better name which is closer to the reality that such slots are quite restrictive? (LDH slot? ASCII slot?) Section 4.1 should say in its first sentence that the input is a sequence of code points making up one label. Section 4.1 and the definition of "internationalized label" talk of "equivalence". I think this is a bit too subtle. I think it might help to define "label equivalence" in section 2 explicitly (in its own paragraph) and point out that this is not just a case of code point by code point comparison (because under "label equivalence" an ACE label should match the corresponding non-ACE label.) Section 4.1 talk of "host name syntax rules" but has no reference to what this means. STD3? Perhaps the above clarfication to the definition takes care of this. Section 4.1 (or section 6?) should say something about the meaning of a failure indication of ToASCII. Section 4.1 step 2: specify that the "prohibit unassigned" flag is used by nameprep. Section 4.1 step 3: "is a host name" isn't well defined. It should say something like if the "host name syntax" flag is set. Section 4.1. Step 5 should presumably be before step 4. Or do you want to allow multiple applications of ToASCII i.e. being able to apply it to a label which has already been "ACEd"? If so it makes sense the desire to be able to do this explicit. Section 4.1 step 6 doesn't say "and fail if there is an error". Section 4.2 should say in its first sentence that the input is a sequence of code points making up one label. Section 4.2 step 2. Why is this step needed? This is likely to be another unstated desire/requirement. Section 4.2 step 2. Should say that nameprep uses the "prohibit unassigned" flag. Section 4.2 step 6. What happens when ToASCII returns an error? Section 4.2 step 7. Instead of "sequence" how about "result of ToASCII"? "Sequence" reads a bit like "the saved copy of the sequence". Section 5 After "IESG--" add: [IANA to assign] The picture in section 6 doesn't actually show where ToASCII and ToUnicode fits. How about putting a box between the resolver library and the application conversion box? Also, the text on the arrow going to "application servers" talks both of the immediate case (when application protocols use ACE) and a future where some application protocols might negotiate to use a non-ACE encoding. Perhaps the latter should be a separate picture? The text could be replaced by having two different paths. Roughly v ^ ^ | | | v ^ | ToASCII/ToUnicode TBD ^ | | Existing application | New, IDN-aware application | protocol | protocol v v Existing application New, IDN-aware application servers servers I think the text in the picture is trying to say the above. The above "TBD" is "predefined by the protocol" in the document. Perhaps the "ToASCII/ToUnicode" box should be named "IDNA" - but "IDNA" is more the whole approach than the single functional unit doing the conversions. The last paragraph in section 6.2 can perhaps refer to the terminology in the picture. For instance saying that in terms of figure X this means that the ToASCII/ToUnicode box would be available as part of the Resolver library box. Section 6.6 says It also SHOULD be used for other name comparisons, such as when a browser wants to indicate that a URL has been previously visited. I don't understand what this has to do with DNSSEC. Does it belong in a different section? And if we allow well-defined comparisons without requiring ACE encoding before the comparison then I don't see why it would be required. Section 7 says: ACE is an encoding for domain name labels that use non-ASCII characters. My brain tripped on this. Seemed to read that ACE uses non-ASCII characters. And I suspect other non-native English speakers might have more problems understanding what "that" refers to. Can it be reworded? Split normative vs. non-normative references. --- From owner-idn@ops.ietf.org Fri May 3 15:15:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25303 for ; Fri, 3 May 2002 15:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173iFg-00089j-00 for idn-data@psg.com; Fri, 03 May 2002 11:57:56 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 173iFf-00089d-00 for idn@ops.ietf.org; Fri, 03 May 2002 11:57:55 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17267 for ; Fri, 3 May 2002 11:57:53 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g43Ivng28219 for ; Fri, 3 May 2002 20:57:50 +0200 (MEST) Date: Fri, 3 May 2002 20:57:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] Editorial comments on stringprep To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk draft-hoffman-stringprep-02.txt ------------------------------- I've reviewed the stringprep document to make sure it is ready for IETF last call. Here are some editorial comments that it would be useful to fix before the last call. The nameprep document contained some text which I think should belong in stringprep. The text in nameprep (in two different contexts) was: The lists in Appendix E MUST be used by implementations of this specification. If there are any discrepancies between the lists in Appendix E and subsections below, the lists in Appendix E always takes precedence. This profile lists the unassigned code points in the range 0 to 10FFFF for Unicode 3.1 in Appendix F. The list in Appendix F MUST be used by implementations of this specification. If there are any discrepancies between the list in Appendix F and the Unicode 3.1 specification, the list in Appendix F always takes precedence. The document needs to make it more clear that it will be an exception when profiles define additional tables. The intent is that stringprep define the tables and that the stringprep profiles will select among those defined tables. Adding some text to section 1.2 about this would be helpful for folks defining profiles. E.g. add "(in exceptional cases)" for those items in the bulleted list. It isn't obvious that table B.2 and B.3 derive directly from the Uncode tables when in fact they do. I think it would be useful to state this. In fact the text about "NormalizeWithKC(Fold...)" in section 3.2 describes how table B.2 is created, but it needs to explicitly say this. Likewise it would be helpful to say that B.3 is created from the Unicode table for case folding (CaseFolding.txt??) The document needs a table of content based on the rfc-editors criteria and the length of the document. Section 1: Is there a missing "would" before "cause an error"? The RFC 2119 citing text does not include all the 2119 words. The document uses "SHOULD NOT" and "MUST NOT" which are not included. The safest thing is to use the boiler plate that lists all the 2119 words. Section 1.2: - The tables froom this document of characters that are prohibited as s/froom/from/ Section 3: talks about "mapped to nothing" but the tables refer to this as "map out". Either use a single term or explicitly state e.g. in section 3 that they mean the same. Latter could perhaps be done by adding "map out" in parenthesis after "map to nothing". 3.1 says "because their presence or absence should not make two strings different". The statement makes sense in the context of protocol elements (for the protocols whose stringprep profile select this mapping) but it might not make sense for text in general. Thus I think it makes sense adding this context to the description. Section 3.2 talks about the tradition of using lowercase but my understanding is also that there is a technical argument in that downcasing is more well-defined in Unicode than upcasing. Is this not the case? If so if would make sense to add that to the description of the motivation. Section 3.2 missing close parenthesis after "statuses C, F, and I." Section 3.2 talks about "the table is stable from that point on." But it doesn't actually state that this is how the table in B.2 is generated. Perhaps this should be made explicit both here and at the top of appendix B.2. Section 3.2 and elsewhere: I don't think "unupdated" is a word. How about in both those systems which have been updated and those which have not. Section 4 talks of "three options for Unicode normalization" but there are only two bullets below that text. Section 4 doesn't refer to which Uncode table to use (e.g. the filename) In fact, partially because of this I originally read the document as if table B.2 including the NFKC mapping when it in fact does not. This needs to be made more clear. Section 5.2. Says displayed. Note that additional control characters (U+0000 through U+001F, and U+007F) are not listed below. They are listed in Appendix C-2. The second sentence makes one believe the ASCII control characters are in appendix C.2 when in fact they are not. The references to the parts of appendix C use "C-" but the appendices are named "C.". Section 5.3. The argument for the replacement character is quite weak - it does have some semantics. Isn't there a stronger argument that one would never expect to use this character as an *input*? The intent is to only use it for *output*. As such it doesn't make sense to have it be used in a protocol element. Section 5.4 missing "in" before "the Proplist.txt file ..." Section 6 talks of "names of SNMP objects" in multiple places. But SNMP objects are named by OIDs - not character strings. Drop it? Section 6 says Using two different policies for where unassigned code points can appear prevents the need for versioning in protocols that use I think "removes" is better than "prevents" here. Section 6 seems to use the term "query" in some places and "request" in others. Please make it use a consistent term. Section 6.2 seems to use the term "correct" with two rather different meanings: 1. The correct answer is returned (positive or negative answer) 2. In order to prevent false positives the "correct" approach is to return false negatives in some cases. I think #2 should use a different term. ("predictable"? conservatively? I'm open to suggestions). This appears in two places: the XY vs. YX and the X vs. nX. Section 7 reads like the designers were just too lazy to handle similar looking characters, which clearly isn't the case. Thus I think it makes sense to add some language saying that similar-looking is a very hard problem and is (believed to be) impossible to solve without some additional context, and that context is not available in DNS lookups. Appendix E. I think it makes sense to move this to a section i.e. before the character tables. "MUST be an RFC" is not one of the choices in RFC 2434. "IETF Consensus" seems closest to what the text says, but "IESG approval" might also match. And add a citation to RFC 2434. Split normative vs. non-normative references. --- From owner-idn@ops.ietf.org Fri May 3 15:15:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25338 for ; Fri, 3 May 2002 15:15:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173iGv-0008BR-00 for idn-data@psg.com; Fri, 03 May 2002 11:59:13 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 173iGu-0008BJ-00 for idn@ops.ietf.org; Fri, 03 May 2002 11:59:12 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06635 for ; Fri, 3 May 2002 12:59:15 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g43Ix7g28333 for ; Fri, 3 May 2002 20:59:08 +0200 (MEST) Date: Fri, 3 May 2002 20:58:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] Editorial comments on nameprep To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk draft-ietf-idn-nameprep-09.txt ------------------------------ I've reviewed the nameprep document to make sure it is ready for IETF last call. Here are some editorial comments that it would be useful to fix before the last call. Section 1 says that the applicability is for a domain name label as opposed to a domain name. It would be helpful to briefly state in the text why this choice was made (which is basically to leave U+002E related processing above nameprep) was made and also point out that the user of nameprep needs to separate the domain name into labels before applying nameprep. Section 4. It would be useful to have an explicit reference to the Unicode table for NFKC (e.g. the file name). The text reads as if stringprep defines NFKC when it is in fact defined by Unicode. Section 5.1: The text says that the input mechanism can choose to map U+3002 to U+002E. But that would potentially cause problems for non-domain name use of that code point. I think the correct statement in nameprep is that the application, when it is handling a domain name and splits in into labels before applying ToASCII, the *application* (not the *input method*) can do this mapping. Thus changing "input method" to "application" seems the right thing here. The RFC 2119 citing text does not include all the 2119 words. The document uses "SHOULD NOT" which is not included. The safest thing is to use the boiler plate that lists all the 2119 words. Section 7 reads like the designers were just too lazy to handle similar looking characters, which clearly isn't the case. Thus I think it makes sense to add some language saying that similar-looking is a very hard problem and is (believed to be) impossible to solve without some additional context, and that context is not available in DNS lookups. Split normative vs. non-normative references. --- From owner-idn@ops.ietf.org Sat May 4 00:16:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09420 for ; Sat, 4 May 2002 00:16:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173qip-000Frs-00 for idn-data@psg.com; Fri, 03 May 2002 21:00:35 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 173qio-000Frm-00 for idn@ops.ietf.org; Fri, 03 May 2002 21:00:34 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4440PA16536 for ; Sat, 4 May 2002 13:00:26 +0900 Message-ID: <00c501c1f320$2f86a1e0$2b19fea9@temp> From: "Soobok Lee" To: Subject: [idn] 1st stringprep issue: not answered and ignored Date: Sat, 4 May 2002 12:59:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is the following issue addressed or mentioned in new stringprep/nameprep draft? and represent the same character. that is, they are NFC-equivalent. But, UAX21 (casefolding in stringprep) maps the latter one errornously into (very different than the correct one ). In lowercaseing, should be converted as a whole, instead of by char-by-char basis. Stringprep should have contained warnings about this or included new revised casefolding operatins/tables, but it didn't . the authors and co-chairs have ignored this repeated warnings without any responses in this list. This is not a theoretical issue, but a practical issue because the sequences are used by modern east-europeans. Therefore,stringprep(NFC(x)) == stringprep(x) is not guaranteed. This will cause unnoticeable failures. It's ridiculous that repeated warnings are ignored/unanswered and the drafts went to IESG. This will result in downplay on overall IETF processes and its reputations. Soobok Lee ----- Original Message ----- From: "Soobok Lee" To: Sent: Tuesday, February 12, 2002 1:39 AM Subject: [idn] IDNA comment 1 : applications' own normalization vs stringprep > > In the IDNA draft version6, section 6.1, paragraph 4 and 5, > > "In protocols and document formats that define how to handle > specification or negotiation of charsets, labels can be encoded in any > charset allowed by the protocol or document format. If a protocol or > document format only allows one charset, the labels MUST be given in > that charset." > > "In any place where a protocol or document format allows transmission of > the characters in internationalized labels, internationalized labels > SHOULD be transmitted using whatever character encoding and escape > mechanism that the protocol or document format uses at that place." > > Here,we need more security warnings in this section regarding to applications' > own normalizations that may collided with STRINGPREP's NFC/NFKC. > > Like some XML and HTML standards, there may be applications that performs > NFC,NFKC or other normalizations on their data/text contents that > may contain IDN labels that will be stringprepped and the ACEed later time. > > But, even in the case NFC, stringprep(NFC(x)) == stringprep(x) is not always > guaranteed, especially in the case of and ( + ). > That will cause silent failures in applications. > > Current premature UAX15 used in stringprep and other compensating or superior normalizations that may > be from the same UTC or other organizations may collide to each other in > a sequence of normalizatiom processes eventually ending in stringprep > in many mission critical applications. > > We need more researches and inspections for the possiblities of normalization vs normalization > conflicts and include the warning or recommendations in the IDNA specficiations. > > Soobok Lee > > > > > From owner-idn@ops.ietf.org Sat May 4 00:36:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09850 for ; Sat, 4 May 2002 00:36:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173r6p-000GAn-00 for idn-data@psg.com; Fri, 03 May 2002 21:25:23 -0700 Received: from smtprelay1.dc3.adelphia.net ([24.50.78.4]) by psg.com with esmtp (Exim 3.36 #1) id 173r6o-000GAh-00 for idn@ops.ietf.org; Fri, 03 May 2002 21:25:22 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay1.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GVKKA900.T3F; Sat, 4 May 2002 00:25:21 -0400 Message-ID: <000c01c1f323$9695f720$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: "Erik Nordmark" , References: Subject: Re: [idn] Editorial comments on stringprep Date: Fri, 3 May 2002 21:24:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the midst of some very well-thought-out comments, Erik Nordmark wrote: > Section 3.2 talks about the tradition of using lowercase > but my understanding is also that there is a technical argument > in that downcasing is more well-defined in Unicode than upcasing. > Is this not the case? If so if would make sense to add that to > the description of the motivation. I can't think of anything that would lead to that impression, in Unicode or anywhere else. Uppercase, lowercase, and titlecase mapping are all handled on a completely equal footing in Unicode. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Sat May 4 01:08:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10178 for ; Sat, 4 May 2002 01:08:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173raW-000Geh-00 for idn-data@psg.com; Fri, 03 May 2002 21:56:04 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 173raV-000Geb-00 for idn@ops.ietf.org; Fri, 03 May 2002 21:56:03 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/52qX+5mZcTamaHIuizWTyg=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id GZXLD8SY; Sat, 04 May 2002 00:55:50 EDT To: idn@ops.ietf.org Date: Fri, 3 May 2002 21:55:28 -0700 Subject: Re: [idn] 1st stringprep issue: not answered and ignored Message-ID: <20020503.215541.2796.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To discuss this problem, we have to know how the tables in stringprep is organized. I wander if stringprep authors may have some thoughts. Liana Ye On Sat, 4 May 2002 12:59:27 +0900 "Soobok Lee" writes: > Is the following issue addressed or mentioned in new > stringprep/nameprep draft? > > and represent the same character. that > is, they are NFC-equivalent. > But, UAX21 (casefolding in stringprep) maps the latter one > errornously into > (very different than the correct one ). > In lowercaseing, should be converted as a whole, > instead of by char-by-char basis. > > Stringprep should have contained warnings about this or included new > revised casefolding operatins/tables, > but it didn't . the authors and co-chairs have ignored this repeated > warnings > without any responses in this list. This is not a theoretical issue, > > but a practical issue because the sequences are used by modern > east-europeans. > > Therefore,stringprep(NFC(x)) == stringprep(x) is not guaranteed. > This will cause unnoticeable failures. > > It's ridiculous that repeated warnings are ignored/unanswered and > the drafts went to IESG. > This will result in downplay on overall IETF processes and its > reputations. > > Soobok Lee > > > ----- Original Message ----- > From: "Soobok Lee" > To: > Sent: Tuesday, February 12, 2002 1:39 AM > Subject: [idn] IDNA comment 1 : applications' own normalization vs > stringprep > > > > > > In the IDNA draft version6, section 6.1, paragraph 4 and 5, > > > > "In protocols and document formats that define how to handle > > specification or negotiation of charsets, labels can be encoded in > any > > charset allowed by the protocol or document format. If a protocol > or > > document format only allows one charset, the labels MUST be given > in > > that charset." > > > > "In any place where a protocol or document format allows > transmission of > > the characters in internationalized labels, internationalized > labels > > SHOULD be transmitted using whatever character encoding and escape > > mechanism that the protocol or document format uses at that > place." > > > > Here,we need more security warnings in this section regarding to > applications' > > own normalizations that may collided with STRINGPREP's NFC/NFKC. > > > > Like some XML and HTML standards, there may be applications that > performs > > NFC,NFKC or other normalizations on their data/text contents that > > may contain IDN labels that will be stringprepped and the ACEed > later time. > > > > But, even in the case NFC, stringprep(NFC(x)) == stringprep(x) is > not always > > guaranteed, especially in the case of and above> ( + ). > > That will cause silent failures in applications. > > > > Current premature UAX15 used in stringprep and other compensating > or superior normalizations that may > > be from the same UTC or other organizations may collide to each > other in > > a sequence of normalizatiom processes eventually ending in > stringprep > > in many mission critical applications. > > > > We need more researches and inspections for the possiblities of > normalization vs normalization > > conflicts and include the warning or recommendations in the IDNA > specficiations. > > > > Soobok Lee > > > > > > > > > > > > > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Sat May 4 04:11:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20398 for ; Sat, 4 May 2002 04:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173uVe-000Jun-00 for idn-data@psg.com; Sat, 04 May 2002 01:03:14 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 173uVe-000Jug-00 for idn@ops.ietf.org; Sat, 04 May 2002 01:03:14 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00193; Sat, 4 May 2002 02:03:12 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4482ng25409; Sat, 4 May 2002 10:02:50 +0200 (MEST) Date: Sat, 4 May 2002 10:02:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Editorial comments on stringprep To: Doug Ewell Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <000c01c1f323$9695f720$fa424244@anhmca.adelphia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > I can't think of anything that would lead to that impression, in Unicode > or anywhere else. Uppercase, lowercase, and titlecase mapping are all > handled on a completely equal footing in Unicode. I didn't mean "undefined" as poorly specified. Sorry for my lack of Unicode clue - perhaps I've misunderstood something. But I recall hearing that given two arbitrary Unicode code points X and Y one could do a comparison of MaptoUpperCase(X) and MaptoUpperCase(Y) or MaptoLowerCase(X) and MaptoLowerCase(Y) Both of these are well-defined, but the results of the comparison will be different in some cases. I haven't verfied this but I think U+0131 and U+0049 would compare as equal in the first case but not in the second case. But I now realize that the above isn't germane to the text on which I commented. The above is just an argument that the spec must pick one or the other techniques for case insensitive comparison. Hmm - I don't recall if Patrik has some additional arguments for why lowercase is better in his plenary presentation in Minneapolis. Erik From owner-idn@ops.ietf.org Sat May 4 06:13:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21578 for ; Sat, 4 May 2002 06:13:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 173wHm-000LFX-00 for idn-data@psg.com; Sat, 04 May 2002 02:57:02 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 173wHl-000LFR-00 for idn@ops.ietf.org; Sat, 04 May 2002 02:57:02 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g449uFQN023133; Sat, 4 May 2002 11:56:22 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sat, 4 May 2002 11:56:52 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sat, 4 May 2002 11:56:52 +0200 Date: Sat, 04 May 2002 11:17:49 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Erik Nordmark , Doug Ewell cc: Erik Nordmark , idn@ops.ietf.org Subject: Re: [idn] Editorial comments on stringprep Message-ID: <11503195.1020511069@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 04 May 2002 09:56:52.0557 (UTC) FILETIME=[042647D0:01C1F352] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA21578 --On 2002-05-04 10.02 +0200 Erik Nordmark wrote: > Hmm - I don't recall if Patrik has some additional arguments for why > lowercase is better in his plenary presentation in Minneapolis. Historically, Unicode Consortium has always stated that mapping to lowercase were more consistent and better than mapping to uppercase. At least for Unicode before version 2. Don't remember any exact reasons, but we can dig it up if you want us to. There are also a number of codepoints which are lowercase which doesn't have uppercase versions. Last, some codepoints (like the german sharp-s, ß) turns to "SS" in uppercase, and my guess is (with my limited knowledge of German, only 2 years of studies) that one when comparing don't want that similarities. Anyway, my point is that previously UTC has always recommended mapping to lowercase, and people seems to be happy with it. And, personally, I rather see bq-asdqwe123 than BQ-ASDQWE the few times I hope I see a domain name used in protocols natively in its ACE encoding. paf From owner-idn@ops.ietf.org Sat May 4 11:48:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25821 for ; Sat, 4 May 2002 11:48:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1741Xk-000PvQ-00 for idn-data@psg.com; Sat, 04 May 2002 08:33:52 -0700 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by psg.com with esmtp (Exim 3.36 #1) id 1741Xj-000PvK-00 for idn@ops.ietf.org; Sat, 04 May 2002 08:33:51 -0700 Received: from c1340594a ([12.234.220.58]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020504153349.SSDR5896.rwcrmhc53.attbi.com@c1340594a>; Sat, 4 May 2002 15:33:49 +0000 Message-ID: <003e01c1f381$2f492ca0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "Erik Nordmark" , "Doug Ewell" Cc: "Erik Nordmark" , References: <11503195.1020511069@localhost> Subject: Re: [idn] Editorial comments on stringprep Date: Sat, 4 May 2002 08:34:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit For most case-insensitive binary comparison, the recommendation is to use case folding, as defined in the Standard. For more info, see http://www.unicode.org/unicode/reports/tr21/. Mark ————— Γνῶθι σαυτόν — Θαλῆς [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Patrik Fältström" To: "Erik Nordmark" ; "Doug Ewell" Cc: "Erik Nordmark" ; Sent: Saturday, May 04, 2002 02:17 Subject: Re: [idn] Editorial comments on stringprep --On 2002-05-04 10.02 +0200 Erik Nordmark wrote: > Hmm - I don't recall if Patrik has some additional arguments for why > lowercase is better in his plenary presentation in Minneapolis. Historically, Unicode Consortium has always stated that mapping to lowercase were more consistent and better than mapping to uppercase. At least for Unicode before version 2. Don't remember any exact reasons, but we can dig it up if you want us to. There are also a number of codepoints which are lowercase which doesn't have uppercase versions. Last, some codepoints (like the german sharp-s, ß) turns to "SS" in uppercase, and my guess is (with my limited knowledge of German, only 2 years of studies) that one when comparing don't want that similarities. Anyway, my point is that previously UTC has always recommended mapping to lowercase, and people seems to be happy with it. And, personally, I rather see bq-asdqwe123 than BQ-ASDQWE the few times I hope I see a domain name used in protocols natively in its ACE encoding. paf From owner-idn@ops.ietf.org Sat May 4 12:08:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26195 for ; Sat, 4 May 2002 12:08:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17420J-0000Sx-00 for idn-data@psg.com; Sat, 04 May 2002 09:03:23 -0700 Received: from mail.imc.org ([208.184.76.43] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17420J-0000Sp-00 for idn@ops.ietf.org; Sat, 04 May 2002 09:03:23 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g44G3Ka15483 for ; Sat, 4 May 2002 09:03:20 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <00c501c1f320$2f86a1e0$2b19fea9@temp> References: <00c501c1f320$2f86a1e0$2b19fea9@temp> Date: Sat, 4 May 2002 09:03:17 -0700 To: From: Paul Hoffman / IMC Subject: Re: [idn] 1st stringprep issue: not answered and ignored Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:59 PM +0900 5/4/02, Soobok Lee wrote: >Stringprep should have contained warnings about this or included new >revised casefolding operatins/tables, >but it didn't . Correct. This has been covered many times on the mailing list. You want stringprep to change the tables issued by the Unicode Consortium so that stringprep does not do NFKC the same way all other software that does NFKC does. There is little support for that proposition in the WG. > the authors and co-chairs have ignored this repeated warnings >without any responses in this list. There is a big difference between "ignoring" and "disagreeing with". We hear you asking over and over for something for which there is little support. Are you saying that we should include the concerns of every single person, even if the rest of the group disagrees with them? >Therefore,stringprep(NFC(x)) == stringprep(x) is not guaranteed. >This will cause unnoticeable failures. Your equation is completely wrong. NFKC is part of stringprep. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat May 4 13:48:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27355 for ; Sat, 4 May 2002 13:48:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1743JL-0001nO-00 for idn-data@psg.com; Sat, 04 May 2002 10:27:07 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #1) id 1743JK-0001nI-00 for idn@ops.ietf.org; Sat, 04 May 2002 10:27:07 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GVLKH500.M1Z; Sat, 4 May 2002 13:27:05 -0400 Message-ID: <007f01c1f390$d2ca5480$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: "Patrik Fältström" Cc: "Erik Nordmark" , , "Mark Davis" References: <11503195.1020511069@localhost> Subject: Re: [idn] Editorial comments on stringprep Date: Sat, 4 May 2002 10:26:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > Historically, Unicode Consortium has always stated that mapping to > lowercase were more consistent and better than mapping to uppercase. > At least for Unicode before version 2. Don't remember any exact > reasons, but we can dig it up if you want us to. and later: > Anyway, my point is that previously UTC has always recommended > mapping to lowercase, and people seems to be happy with it. I couldn't remember UTC ever saying such a thing, so when Mark Davis wrote: > For most case-insensitive binary comparison, the recommendation is > to use case folding, as defined in the Standard. For more info, see > http://www.unicode.org/unicode/reports/tr21/. naturally I took a look. The only thing I found that could be construed as a preference for lowercase was in the CaseFolding details: > Each equivalence class is completely disjoint from all the others, > and together they form a partition of the entire Unicode code space. > From each class, one representative element (a single lowercase > letter where possible) is chosen to be the common form. > [CaseFolding] thus contains the mappings from other characters in > the equivalence characters to their common forms. This passage describes an *internal process* only. This has nothing to do with the Unicode Consortium or Technical Committee preferring lowercase forms over uppercase for user-visible operations, and it definitely does *not* claim that mapping to lowercase is more consistent or "better" than mapping to uppercase. There is no explanation given for the phrase "a single lowercase letter where possible" to explain why lowercase was selected. It appears to be an arbitrary choice. > There are also a number of codepoints which are lowercase which > doesn't have uppercase versions. Which ones? I can think of a character that looks uppercase but has no lowercase form (U+04C0 CYRILLIC LETTER PALOCHKA). But such letters, despite their appearance, are neither uppercase nor lowercase; they are caseless, and immune to the effects of any casing operation. > Last, some codepoints (like the german sharp-s, ß) turns to "SS" in > uppercase, and my guess is (with my limited knowledge of German, > only 2 years of studies) that one when comparing don't want that > similarities. German speakers are forced to deal with that mapping every day. It is a natural part of the language. > And, personally, I rather see bq-asdqwe123 than BQ-ASDQWE the few > times I hope I see a domain name used in protocols natively in its > ACE encoding. No argument there. All-lowercase is widely recognized as being easier to read than all-uppercase, primarily because of the greater variation in letterforms. But again, there doesn't seem to be any evidence that the Unicode Consortium has made any of the claimed statements about "preferring" lowercase or about the mapping to lowercase being more "consistent." Please dig up the relevant references, if possible. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Sat May 4 14:23:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27746 for ; Sat, 4 May 2002 14:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174449-0002dx-00 for idn-data@psg.com; Sat, 04 May 2002 11:15:29 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 174448-0002dm-00 for idn@ops.ietf.org; Sat, 04 May 2002 11:15:28 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g44IFNA21772; Sun, 5 May 2002 03:15:23 +0900 Message-ID: <01a101c1f397$9c2e8430$2b19fea9@temp> From: "Soobok Lee" To: , "Paul Hoffman / IMC" References: <00c501c1f320$2f86a1e0$2b19fea9@temp> Subject: Re: [idn] 1st stringprep issue: not answered and ignored Date: Sun, 5 May 2002 03:15:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Paul Hoffman / IMC" To: Sent: Sunday, May 05, 2002 1:03 AM Subject: Re: [idn] 1st stringprep issue: not answered and ignored > At 12:59 PM +0900 5/4/02, Soobok Lee wrote: > >Stringprep should have contained warnings about this or included new > >revised casefolding operatins/tables, > >but it didn't . > > Correct. This has been covered many times on the mailing list. You > want stringprep to change the tables issued by the Unicode Consortium > so that stringprep does not do NFKC the same way all other software > that does NFKC does. There is little support for that proposition in > the WG. I am not against NFKC. I am not proposing for modification to NFKC, but to UAX21 casefoldings. I just pointed our that The UAX21 casefolding is wrong at the example. Who had answered at my questions before your this article? How to measure the consensus? I have never seen this WG had discussed this issue in depth. > > > the authors and co-chairs have ignored this repeated warnings > >without any responses in this list. > > There is a big difference between "ignoring" and "disagreeing with". > We hear you asking over and over for something for which there is > little support. Are you saying that we should include the concerns of > every single person, even if the rest of the group disagrees with > them? > > >Therefore,stringprep(NFC(x)) == stringprep(x) is not guaranteed. > >This will cause unnoticeable failures. > > Your equation is completely wrong. NFKC is part of stringprep. Alas. You still don't get my point. The NFC(x) above is , for example, from IRI preprocessing or HTML authoring, which often require NFC normalization on their inputs. To rephrase the above equation, "NFKC(UAX21_casefold(NFC(x))) == NFKC(UAX21_casefold(x)) is not guaranteed." If you preprocess IDN with NFC, you will get different namepreped ACE labels than before in the IDN samples including . Soobok Lee > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn@ops.ietf.org Sat May 4 15:18:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28268 for ; Sat, 4 May 2002 15:18:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1744qi-0003YV-00 for idn-data@psg.com; Sat, 04 May 2002 12:05:40 -0700 Received: from mail.imc.org ([208.184.76.43] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 1744qh-0003YP-00 for idn@ops.ietf.org; Sat, 04 May 2002 12:05:39 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g44J5Za19831 for ; Sat, 4 May 2002 12:05:35 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <01a101c1f397$9c2e8430$2b19fea9@temp> References: <00c501c1f320$2f86a1e0$2b19fea9@temp> <01a101c1f397$9c2e8430$2b19fea9@temp> Date: Sat, 4 May 2002 12:05:24 -0700 To: From: Paul Hoffman / IMC Subject: Re: [idn] 1st stringprep issue: not answered and ignored Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:15 AM +0900 5/5/02, Soobok Lee wrote: >----- Original Message ----- >From: "Paul Hoffman / IMC" >To: >Sent: Sunday, May 05, 2002 1:03 AM >Subject: Re: [idn] 1st stringprep issue: not answered and ignored > > >> At 12:59 PM +0900 5/4/02, Soobok Lee wrote: >> >Stringprep should have contained warnings about this or included new >> >revised casefolding operatins/tables, >> >but it didn't . >> >> Correct. This has been covered many times on the mailing list. You >> want stringprep to change the tables issued by the Unicode Consortium >> so that stringprep does not do NFKC the same way all other software >> that does NFKC does. There is little support for that proposition in >> the WG. > >I am not against NFKC. I am not proposing for modification to NFKC, >but to UAX21 casefoldings. My apology for mixing up your previous arguments for changing NFKC with your current argument for changing UAX21. The result is, of course, the same: you are asking us to change an external standard so that our protocol will not work the same as other software that follows UAX21. > I just pointed our that The UAX21 casefolding is >wrong at the example. That's not true: you did much more than "just" point that out. You asked for us to change the mapping from the Unicode Consortium, and you accused the authors of the drafts of ignoring you. >Who had answered at my questions before your this article? You brought it up on the list in February; only one person supported your request, and he suggested that you take this to the Unicode Consortium. There are numerous threads on this mailing list about why we should use the Unicode Consortium tables, even if we we think there are some problems with them. >How to measure the consensus? I have never seen this WG had >discussed this issue in depth. Have you participated in any other IETF Working Groups? If so, how did they measure consensus? If not, do you think it is appropriate for every working group to spend time discussing this? If you have not done so already, you should probably read and the other documents describing how the IETF works. >The NFC(x) above is , for example, from IRI preprocessing or HTML authoring, >which often require NFC normalization on their inputs. >To rephrase the above equation, > >"NFKC(UAX21_casefold(NFC(x))) == NFKC(UAX21_casefold(x)) is not guaranteed." Quite true. I think the following simpler statement is also true: "UAX21_casefold(NFC(x))) == UAX21_casefold(x)) is not guaranteed." >If you preprocess IDN with NFC, you will get different namepreped ACE labels >than before in the IDN samples including . True, but irrelevant. Nameprep is called from IDNA. IDNA does not say, and has never said, "you can do NFC before processing the name". The fact that you might have done some processing on a name *before you processed IDNA*, and that pre-processing may cause you some surprises, is not an IDNA problem. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat May 4 15:40:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28493 for ; Sat, 4 May 2002 15:40:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1745Fe-00040K-00 for idn-data@psg.com; Sat, 04 May 2002 12:31:26 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 1745Fc-00040E-00 for idn@ops.ietf.org; Sat, 04 May 2002 12:31:25 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g44JVKA30353; Sun, 5 May 2002 04:31:20 +0900 Message-ID: <01d201c1f3a2$38998040$2b19fea9@temp> From: "Soobok Lee" To: , "Paul Hoffman / IMC" References: <00c501c1f320$2f86a1e0$2b19fea9@temp> <01a101c1f397$9c2e8430$2b19fea9@temp> Subject: Re: [idn] 1st stringprep issue: not answered and ignored Date: Sun, 5 May 2002 04:30:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Paul Hoffman / IMC" > > > >"NFKC(UAX21_casefold(NFC(x))) == NFKC(UAX21_casefold(x)) is not guaranteed." > > Quite true. I think the following simpler statement is also true: > "UAX21_casefold(NFC(x))) == UAX21_casefold(x)) is not guaranteed." > > >If you preprocess IDN with NFC, you will get different namepreped ACE labels > >than before in the IDN samples including . > > True, but irrelevant. Nameprep is called from IDNA. IDNA does not > say, and has never said, "you can do NFC before processing the name". > The fact that you might have done some processing on a name *before > you processed IDNA*, and that pre-processing may cause you some > surprises, is not an IDNA problem. == : these two represent the same character. Likewise, ==: so do these two . But, for the latter case, stringprep treat them as equal ones,but for the former case, it doesn't. it is inconsistent, and moreover errornous,because LOWERCASE() != . IDNA inherits the error of UAX21. Therefore , this is IDNA problem, because IDNA adopted the problematic UAX21 without patches, even though IETF is not directly responsible for the specific error in UAX21. From owner-idn@ops.ietf.org Sat May 4 15:42:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28512 for ; Sat, 4 May 2002 15:42:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1745KL-000460-00 for idn-data@psg.com; Sat, 04 May 2002 12:36:17 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 1745KK-00045u-00 for idn@ops.ietf.org; Sat, 04 May 2002 12:36:17 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g44Ja8A30372; Sun, 5 May 2002 04:36:08 +0900 Message-ID: <01d901c1f3a2$e489c450$2b19fea9@temp> From: "Soobok Lee" To: "Soobok Lee" , , "Paul Hoffman / IMC" Subject: (NB)Re: [idn] 1st stringprep issue: not answered and ignored Date: Sun, 5 May 2002 04:35:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit NB. UAX21 authors could argue that: UAX21 should be applied to strings which is already NFC-normalized. UAX21 is used improperly in stringprep. If we accept this excuse, stringprep should have applied NFC before casefolding and then NFKC. This may introduce another inefficiency but it make stringprep correct. Soobok Lee ----- Original Message ----- From: "Soobok Lee" To: ; "Paul Hoffman / IMC" Sent: Sunday, May 05, 2002 4:30 AM Subject: Re: [idn] 1st stringprep issue: not answered and ignored > > ----- Original Message ----- > From: "Paul Hoffman / IMC" > > > > > >"NFKC(UAX21_casefold(NFC(x))) == NFKC(UAX21_casefold(x)) is not guaranteed." > > > > Quite true. I think the following simpler statement is also true: > > "UAX21_casefold(NFC(x))) == UAX21_casefold(x)) is not guaranteed." > > > > >If you preprocess IDN with NFC, you will get different namepreped ACE labels > > >than before in the IDN samples including . > > > > True, but irrelevant. Nameprep is called from IDNA. IDNA does not > > say, and has never said, "you can do NFC before processing the name". > > The fact that you might have done some processing on a name *before > > you processed IDNA*, and that pre-processing may cause you some > > surprises, is not an IDNA problem. > > == : these two represent the same character. > Likewise, ==: so do these two . > But, for the latter case, stringprep treat them as equal ones,but > for the former case, it doesn't. it is inconsistent, and moreover > errornous,because LOWERCASE() != . > > IDNA inherits the error of UAX21. Therefore , this is IDNA problem, > because IDNA adopted the problematic UAX21 without patches, even though > IETF is not directly responsible for the specific error in UAX21. > From owner-idn@ops.ietf.org Sat May 4 17:17:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29405 for ; Sat, 4 May 2002 17:17:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1746cb-0005TX-00 for idn-data@psg.com; Sat, 04 May 2002 13:59:13 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 1746ca-0005TR-00 for idn@ops.ietf.org; Sat, 04 May 2002 13:59:12 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1746cZ-0003uP-00 for ; Sat, 04 May 2002 13:59:11 -0700 Date: Sat, 4 May 2002 20:59:11 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Editorial comments on stringprep Message-ID: <20020504205911.GC13774@nicemice.net> Reply-To: IETF idn working group References: <11503195.1020511069@localhost> <007f01c1f390$d2ca5480$fa424244@anhmca.adelphia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007f01c1f390$d2ca5480$fa424244@anhmca.adelphia.net> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk I don't think it matters whether Unicode has ever expressed any preference for lowercasing versus uppercasing. What matters is that Unicode defines a case folding algorithm that happens to use lower case, and Stringprep simply uses it. Although Unicode defines both lowercasing and uppercasing operations, the only case folding operation it defines uses lower case, so we really have no choice unless we want to define our own case folding algorithm (which we don't). (The case folding operation is designed for doing case-insensitive comparisons. The lowercasing operation is not.) AMC From owner-idn@ops.ietf.org Sat May 4 18:21:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00092 for ; Sat, 4 May 2002 18:21:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1747ny-0006tN-00 for idn-data@psg.com; Sat, 04 May 2002 15:15:02 -0700 Received: from rwcrmhc54.attbi.com ([216.148.227.87]) by psg.com with esmtp (Exim 3.36 #1) id 1747ny-0006tC-00 for idn@ops.ietf.org; Sat, 04 May 2002 15:15:02 -0700 Received: from c1340594a ([12.234.220.58]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020504221432.BMYB2627.rwcrmhc54.attbi.com@c1340594a>; Sat, 4 May 2002 22:14:32 +0000 Message-ID: <00ef01c1f3b9$29f75960$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Doug Ewell" , "Patrik Fältström" Cc: "Erik Nordmark" , References: <11503195.1020511069@localhost> <007f01c1f390$d2ca5480$fa424244@anhmca.adelphia.net> Subject: Re: [idn] Editorial comments on stringprep Date: Sat, 4 May 2002 15:14:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This passage describes an *internal process* only. This has nothing to > do with the Unicode Consortium or Technical Committee preferring > lowercase forms over uppercase for user-visible operations, and it > definitely does *not* claim that mapping to lowercase is more consistent > or "better" than mapping to uppercase. There is no explanation given > for the phrase "a single lowercase letter where possible" to explain why > lowercase was selected. It appears to be an arbitrary choice. The choice of whether to use upper or lower for folding was originally somewhat arbitrary; either could have been chosen.* However, the choice of lowercase was made for folding operations, and was encapsulated into the case folding mappings in the UCD. This does not indicate an fundamental sort of 'preference' by the consortium for either case in general text processing, but for a folding operation one must chose, and the choice needs to be stable. *The main reason for choosing lowercase was that there are more characters with lowercase-only than uppercase-only. These characters, mostly IPA, are lowercase in form but have no corresponding uppercase equivalent. Occasionally corresponding uppercase characters are added -- when the character is added to the orthography of some language and ceases to be only IPA (when this happens, it is typically for an African language), and an uppercase is required. Mark From owner-idn@ops.ietf.org Sat May 4 23:54:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04816 for ; Sat, 4 May 2002 23:54:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174CvH-000EGj-00 for idn-data@psg.com; Sat, 04 May 2002 20:42:55 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 174CvG-000EGd-00 for idn@ops.ietf.org; Sat, 04 May 2002 20:42:54 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g453gNA32687; Sun, 5 May 2002 12:42:23 +0900 Message-ID: <024801c1f3e6$d72924b0$2b19fea9@temp> From: "Soobok Lee" To: , "Paul Hoffman / IMC" Cc: "Mark Davis" , "David Hopwood" References: <00c501c1f320$2f86a1e0$2b19fea9@temp> <01a101c1f397$9c2e8430$2b19fea9@temp> Subject: Re: [idn] 1st stringprep issue: not answered and ignored Date: Sun, 5 May 2002 12:42:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Paul Hoffman / IMC" ? > > You brought it up on the list in February; only one person supported > your request, and he suggested that you take this to the Unicode > Consortium. > > There are numerous threads on this mailing list about why we should > use the Unicode Consortium tables, even if we we think there are some > problems with them. > UTC casefolding (UAX21) is made for char-by-char casefolding, not for combining sequences, but stringprep blindly applies UAX21 into them. That is not the problem of UAX21, rather of the stringprep. NFCing before casefolding solves this problem, but this suggestion was also ignored or not discussed in depth. Without any modificationa to UAX21 and NFKC and NFC, we could cure this stringprep errors, simply by adding NFC in step zero in stringprep. Soobok Lee From owner-idn@ops.ietf.org Sun May 5 04:31:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15581 for ; Sun, 5 May 2002 04:31:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174H8G-000IUv-00 for idn-data@psg.com; Sun, 05 May 2002 01:12:36 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 174H8F-000IUp-00 for idn@ops.ietf.org; Sun, 05 May 2002 01:12:36 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g458BeGA019197; Sun, 5 May 2002 10:11:55 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 5 May 2002 10:12:24 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 5 May 2002 10:12:22 +0200 Date: Sun, 05 May 2002 10:02:27 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Doug Ewell cc: Erik Nordmark , idn@ops.ietf.org, Mark Davis Subject: Re: [idn] Editorial comments on stringprep Message-ID: <11973387.1020592947@localhost> In-Reply-To: <007f01c1f390$d2ca5480$fa424244@anhmca.adelphia.net> References: <11503195.1020511069@localhost> <007f01c1f390$d2ca5480$fa424244@anhmca.adelphia.net> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 05 May 2002 08:12:24.0558 (UTC) FILETIME=[968B48E0:01C1F40C] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA15581 --On 2002-05-04 10.26 -0700 Doug Ewell wrote: > I couldn't remember UTC ever saying such a thing, so when Mark Davis > wrote: I said _at_least_before_version_2_. In 1995 I had a long discussion with Unicode Consortium when I worked at Bunyip Information System how to do normalization and case folding together. Their response was to covert to lower case, and our implementation of Whois++ named Digger also ended up in a paper which was presented at a Unicode Conference around 1995-1996. I also saw Mark only refering to case folding, not lower case perticularly, and that's why I talk about handwaving, historical artifacts etc etc. >> There are also a number of codepoints which are lowercase which >> doesn't have uppercase versions. > > Which ones? I can think of a character that looks uppercase but has no > lowercase form (U+04C0 CYRILLIC LETTER PALOCHKA). But such letters, > despite their appearance, are neither uppercase nor lowercase; they are > caseless, and immune to the effects of any casing operation. Quote from page 142 in Unicode version 3 book: "Also, because many characters are really caseless (most of the IPA block, for example), uppercasing a string does not mean that it will no longer contain any lowercase letters." I only quote the text. Yes, when reading it, one might think it should have been written "...that it will only contain uppercase letter." but it doesn't. >> Last, some codepoints (like the german sharp-s, ß) turns to "SS" in >> uppercase, and my guess is (with my limited knowledge of German, >> only 2 years of studies) that one when comparing don't want that >> similarities. > > German speakers are forced to deal with that mapping every day. It is a > natural part of the language. I know. I just gave it as one example where I _thought_ people from Germany rather wanted lower case than upper case. I wait until I hear from someone from Germany saying they prefer mapping to upper case before I say something else. We talk about what is preferred. Not wether people are used to. >> And, personally, I rather see bq-asdqwe123 than BQ-ASDQWE the few >> times I hope I see a domain name used in protocols natively in its >> ACE encoding. > > No argument there. All-lowercase is widely recognized as being easier > to read than all-uppercase, primarily because of the greater variation > in letterforms. But again, there doesn't seem to be any evidence that > the Unicode Consortium has made any of the claimed statements about > "preferring" lowercase or about the mapping to lowercase being more > "consistent." Please dig up the relevant references, if possible. After some digging, I see the paper Philippe and I wrote was presented on A5 on Unicode Conference number 9, on september 5, 1996: Text Searching Across Multiple Character Sets in Unicode Philippe Boucher, Senior Programmer, Bunyip Information Systems, Montreal, Quebec, Canada I can not find the document though. paf From owner-idn@ops.ietf.org Mon May 6 01:25:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29763 for ; Mon, 6 May 2002 01:25:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174aew-0007u2-00 for idn-data@psg.com; Sun, 05 May 2002 22:03:38 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 174aev-0007tw-00 for idn@ops.ietf.org; Sun, 05 May 2002 22:03:37 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4652ufP019797; Mon, 6 May 2002 07:02:57 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 6 May 2002 07:03:28 +0200 Received: from [10.0.1.3] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 6 May 2002 07:03:26 +0200 Date: Mon, 06 May 2002 06:55:49 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: IETF idn working group , "Paul Hoffman / IMC" Subject: Re: [idn] Editorial comments on idna Message-ID: <13214244.1020668149@localhost> In-Reply-To: <20020505215638.GD24050@nicemice.net> References: <20020505215638.GD24050@nicemice.net> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 06 May 2002 05:03:28.0230 (UTC) FILETIME=[5BFAA860:01C1F4BB] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-05 21.56 +0000 "Adam M. Costello" wrote: > First, a quick small proposal: The name "UnACE" would more accurately > reflect the behavior and purpose of ToUnicode. Should we rename it? If one is "ToASCII", then the other is either "FromASCII" or "ToSomethingElse" (I think...). paf From owner-idn@ops.ietf.org Mon May 6 05:04:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10151 for ; Mon, 6 May 2002 05:04:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174eJI-000Em2-00 for idn-data@psg.com; Mon, 06 May 2002 01:57:32 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 174eJG-000Elp-00 for idn@ops.ietf.org; Mon, 06 May 2002 01:57:31 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g468vTe28653 for ; Mon, 6 May 2002 10:57:29 +0200 (METDST) Received: from trab.se ([131.115.48.22]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g468vQT28628; Mon, 6 May 2002 10:57:26 +0200 (METDST) Message-ID: <3CD6458E.58A3D737@trab.se> Date: Mon, 06 May 2002 10:57:50 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org, phoffman@imc.org, lsb@postel.co.kr, mark@macchiato.com, david.hopwood@zetnet.co.uk Subject: Re: [idn] 1st stringprep issue: not answered and ignored Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The point that Soobok Lee shows is a very serious matter. The requirement on the ACE form of IDNA is that the same name must always result in the same ACE!!!! If doing casefolding/mapping followed by NFKC results in a different code point sequence than doing NFC, casefolding/mapping and NFKC again, we will get DNS lookup failures due to names do not match. While hopefully most data entered into stringprep will be NFC, some will not. If the above is true, stringprep/nameprep must be changed so that the preparation steps for strings are: 1) See to that input strings is NFC. 2) all the steps in stringprep. Dan -- Below i Soobok Lee's text: >UTC casefolding (UAX21) is made for char-by-char casefolding, not for >combining sequences, but stringprep blindly applies UAX21 into them. >That is not the problem of UAX21, rather of the stringprep. > >NFCing before casefolding solves this problem, but this suggestion >was also ignored or not discussed in depth. > >Without any modificationa to UAX21 and NFKC and NFC, we could cure >this stringprep errors, simply by adding NFC in >step zero in stringprep. From owner-idn@ops.ietf.org Mon May 6 06:23:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11461 for ; Mon, 6 May 2002 06:23:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174fQ3-000HHH-00 for idn-data@psg.com; Mon, 06 May 2002 03:08:35 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 174fQ2-000HHA-00 for idn@ops.ietf.org; Mon, 06 May 2002 03:08:34 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08284; Mon, 6 May 2002 04:08:32 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g46A8Ug24846; Mon, 6 May 2002 12:08:30 +0200 (MEST) Date: Mon, 6 May 2002 12:07:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Editorial comments on stringprep To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Erik Nordmark , Doug Ewell , idn@ops.ietf.org In-Reply-To: "Your message with ID" <11503195.1020511069@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Historically, Unicode Consortium has always stated that mapping to > lowercase were more consistent and better than mapping to uppercase. At > least for Unicode before version 2. Don't remember any exact reasons, but > we can dig it up if you want us to. *If* there is such additional reasons it wouldn't hurt to state that as part of the motivation in the draft. Erik From owner-idn@ops.ietf.org Mon May 6 11:52:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24413 for ; Mon, 6 May 2002 11:52:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174kXU-0002YL-00 for idn-data@psg.com; Mon, 06 May 2002 08:36:36 -0700 Received: from rwcrmhc54.attbi.com ([216.148.227.87]) by psg.com with esmtp (Exim 3.36 #1) id 174kXU-0002YD-00 for idn@ops.ietf.org; Mon, 06 May 2002 08:36:36 -0700 Received: from c1340594a ([12.234.220.58]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020506153634.JLZD2627.rwcrmhc54.attbi.com@c1340594a>; Mon, 6 May 2002 15:36:34 +0000 Message-ID: <00aa01c1f513$e6af5ac0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Dan Oscarsson" , , , , References: <3CD6458E.58A3D737@trab.se> Subject: Re: [idn] 1st stringprep issue: not answered and ignored Date: Mon, 6 May 2002 08:37:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The Unicode Consortium recommends that the tables in StringPrep be updated to encompass Unicode 3.2, which was released in March. As a part of this release, there was one change (in addition to new characters) in case folding. The situation regarding the dotted/dotless I in the case foldings has been cleaned up by providing several options, one of which (full case folding without option T) preserves canonical equivalence (although not normalization forms -- text still needs to be normalized after case folding). http://www.unicode.org/Public/3.2-Update/CaseFolding-3.2.0.txt Mark __________ http://www.macchiato.com "Eppur si muove" ----- Original Message ----- From: "Dan Oscarsson" To: ; ; ; ; Sent: Monday, May 06, 2002 01:57 Subject: Re: [idn] 1st stringprep issue: not answered and ignored > > The point that Soobok Lee shows is a very serious matter. > The requirement on the ACE form of IDNA is that the same > name must always result in the same ACE!!!! > > If doing casefolding/mapping followed by NFKC results in a > different code point sequence than doing NFC, casefolding/mapping and > NFKC again, we will get DNS lookup failures due to names do not > match. While hopefully most data entered into stringprep will > be NFC, some will not. > > If the above is true, stringprep/nameprep must be changed so that > the preparation steps for strings are: > > 1) See to that input strings is NFC. > > 2) all the steps in stringprep. > > > Dan > > -- > Below i Soobok Lee's text: > >UTC casefolding (UAX21) is made for char-by-char casefolding, not for > >combining sequences, but stringprep blindly applies UAX21 into them. > >That is not the problem of UAX21, rather of the stringprep. > > > >NFCing before casefolding solves this problem, but this suggestion > >was also ignored or not discussed in depth. > > > >Without any modificationa to UAX21 and NFKC and NFC, we could cure > >this stringprep errors, simply by adding NFC in > >step zero in stringprep. > > From owner-idn@ops.ietf.org Mon May 6 12:09:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25021 for ; Mon, 6 May 2002 12:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174krD-0002ub-00 for idn-data@psg.com; Mon, 06 May 2002 08:56:59 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 174krC-0002uM-00 for idn@ops.ietf.org; Mon, 06 May 2002 08:56:58 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11525 for ; Mon, 6 May 2002 08:56:57 -0700 (PDT) Received: from lillen (vpn-129-156-96-75.EMEA.Sun.COM [129.156.96.75]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g46Furg19405 for ; Mon, 6 May 2002 17:56:54 +0200 (MEST) Date: Mon, 6 May 2002 17:56:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] IDNA questions To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Folks, I've been trying to understand certain aspects around the handling of ASCII vs. non-ASCII code points in IDNA, nameprep, and stringprep but I don't yet have good arguments for all of them. Before I start the last call I'd like to at a minimum have good arguments for why things are done the way they are. The ASCII world --------------- This is the way things look like in the non-IDN world today. We have two types of domain name labels which I'll call host name labels (HL) and non-host name labels (NHL) in this writeup. Most actual usage are HLs but e.g. SRV records are a limited extension to NHL (SRV records are named by two labels which include a leading U+005F). The syntax for NHL allows any byte value i.e. 00..FF. The syntax for HL is letter+digit+hyphen but a label can not have a leading or trailing hyphen. As I understand both HL and NHL are compared using case-insensitive matching. And case-insensitive matching is not well defined outside of 00..7F. Thus well-defined NHL seems to in practise be limited to 00..7F. The HL are compared with case-insensitive matching on DNS servers, but there might be some applications or DNS client software that modify their case which still works. If an application wants to compare two domain names it can use a fairly efficient piece of code (e.g. strcasecmp offers such a thing on certain Unix platforms). IDNA specifications ------------------- The state of the IDNA specifications is as follows. We have two new types of domain name labels which I'll call IHL and INHL in this writeup. Both IHL and INHL can be ACE encoded with the resulting label being a HL in most cases. (An INHL with ASCII characters outside of LDH will get encoded as an ACE that is a NHL; see example (S) in punycode). The difference between the allowed code points in IHL and INHL are not that great. The only difference is whether ASCII code points outside of LDH are allowed; they are allowed in INHL but not in IHL. Both IHL and INHL prohibit the same set of code points outside of the ASCII range (they are all specified in stringprep). Thus e.g. space and control characters are not allowed in INHLs. And punctuation, symbols, etc are allowed in IHLs. The handling of case is as follows: If a label consists of all ASCII code points the case is not modified - the label is not subject to nameprep. If the label consists of some ASCII code points and some non-ASCII, then all code points are case folded - including the ASCII code points. This prevents ToASCII from changing the case of an all-ASCII label. The IDNA specification says This document does not attempt to define an "internationalized host name". It is expected that protocols and name-handling bodies will want to limit the characters allowed in IDNs further than what is specified in this document, such as to prohibit additional characters that they feel are unneeded or harmful in registered domain names. The "protocol" part could be interpreted to mean (at least) two slightly different things: - That a future IETF standard will define internationalized host names and in the process exclude some code points from the set allowed in IHL. - That a future application protocol might decide that certain code points should not be allowed to specify a host name as used by that application protocol. If an application wants to compare two domain names it needs to perform ToASCII on those strings and then compare them using case-insensitive comparison. (See section 3 in the idna spec.) If the application is going to do repeated comparisons (e.g. against a list of domain names) in order for it to perform well the application is likely to end up storing the result of ToASCII for the domain names it compares against. My questions ------------ 1. Allowed characters in INHL. For some code points (like unassigned, private use, non-character, and surrogate code points) it seems to make sense to prohibit them in both IHL and IHNL. In fact, unassigned code points MUST be prohibited in both for proper handling as they get assigned. [The fact that this only applies to stored strings is critical in general, but not important in this discussion.] But why not take the same approach as for ASCII and allow space characters, control characters, etc in INHL? It might not matter much since protocols will (mostly) use IHLs but it would make things follow the same philosophy as in the ASCII case. The argument for doing things the way they are seems to be that - The goal is to enable the richer set of code points to be used by applications - The existing of of non-LDH domain names in ASCII are SRV and the data part of the SOA record. Those records work fine in this approach. - While one could worry more about non-host name syntax there aren't clear arguments for either approach (allowing as many code points as possible vs. preventing the ones that obviously don't make sense in names), so just pick the simplest approach. The current approach is simple in that nameprep/stringprep is the same for host names and non-host names. Are there other arguments for the current approach? 2. Initially allowed characters in IHL. The above quote from the IDNA specification with the possible interpretations of "protocol" doesn't provide much guidance to registries on what code points can be safely registered i.e. does not risk to be declared "not a host name" in some later IETF standard. I think there can be two different intents here: 1. The intent is that all restrictions be solely by registries ("name- handling bodies") based on their local policies of what to register. No application protocols will restrict the set of allowed code points beyond what is currently specific in IDNA+nameprep+stringprep. 2. The intent is at a later date the IETF will produce a specification for host name syntax (either for specific application protocols or in general) that will place some additional restrictions. If #1 is the case then as far as I can tell "protocol" should be removed from the sentence. If #2 is the case then I think the document needs to provide some guidance on what set of code points users and registries should use in order to minimize the risk that their domain names be declared invalid host names at a future date. Which is the intent here? If #2 then why can't the document explicitly state that the intent is that no IETF standard restrict what can be used as an internationalized host name by prohibiting ? Presumably could be a reference to a set of general categories in the Unicode standard. This would not prevent a future IETF standard to declare that a larger set of code points can be used in internationalized host names. And it would not prevent a particular registry to have a policy that only allows a smaller set of code points. 3. Downcasing of ASCII Avoiding downcasing of ASCII code points by ToASCII in an all-ASCII label seems a bit odd. I understand that this makes an IDN-aware application generate the same DNS queries on the wire as the application before it was made IDN-aware (i.e. if the application looked up "Example.COM" it would appear identically in the DNS packet after the application was made IDN-aware). But is this important? The reasons I've seen seem to be that some applications would take the result of ToASCII and use it in protocol fields such as the From: in SMTP. The effect of having ToASCII downcase an all-ASCII label is that users will see different case characters when they upgrade to IDNA-aware applications even though they do not use an IDN themselves. Thus there might be some noticeable short-term effect depending on exactly how the IDNA-aware application is coded. The reason I'm asking is because when application protocols start carrying IDNs in a non-ACE encoding (people seem to think that this will happen sooner or later - perhaps for brand new application protocols and perhaps by making some existing application protocols negotiate the encoding) there will still be a need to nameprep those domain names in order for comparisons to work. However, the ACE encode/decode isn't needed except to deal with peers that do not handle the new on-the-wire encoding. [NOTE: I'm not talking about the DNS as a potential application protocol here. But perhaps SMTP could be handled this way.] This can be simply handled when that day comes by splitting ToASCII into two parts: approximately step 1-3 to prepare in order for comparisons to work and approximately step 4-7 for ACE conversion. When that day comes the comparisons of the prepared labels still needs to use case-insensitive matching for 00..7F code points just because the preparation didn't downcase the ASCII code points. But the non-ASCII code points don't need this i.e. applying all of the Unicode Fold() isn't necessary. Thus the current approach seems a bit short-sighted unless there is a good reason that I don't understand for not case folding ASCII-only labels. 4. Comparison Section 3 item 3 seems to implicitly prevent Unicode-aware applications from comparing two nameprepped strings without first converting them to ACE. Why can't it be made explicit that, as a result of the design of the ACE algorithm being 1-1, two Unicode labels compare as equal if and only if the corresponding ACE labels compare as equal? This would mean that an application, as long as it has applied ToUnicode on the strings when received from an input method, the protocol, or some other source, it could do a comparison without ACE conversion. And if case folding was applied to ASCII-only labels just like all other labels, then the resulting comparison would just need to be a code point by code point comparison. --- Erik From owner-idn@ops.ietf.org Mon May 6 12:25:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25700 for ; Mon, 6 May 2002 12:25:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174lCx-0003Lr-00 for idn-data@psg.com; Mon, 06 May 2002 09:19:27 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 174lCw-0003Ll-00 for idn@ops.ietf.org; Mon, 06 May 2002 09:19:26 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g46GIDA13214; Tue, 7 May 2002 01:18:13 +0900 Message-ID: <00cc01c1f519$9fa235c0$2b19fea9@temp> From: "Soobok Lee" To: "Mark Davis" , "Dan Oscarsson" , , , References: <3CD6458E.58A3D737@trab.se> <00aa01c1f513$e6af5ac0$8900a8c0@c1340594a> Subject: Re: [idn] 1st stringprep issue: not answered and ignored Date: Tue, 7 May 2002 01:18:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I read in http://www.unicode.org/Public/3.2-Update/CaseFolding-3.2.0.txt 0130; F; 0069 0307; # LATIN CAPITAL LETTER I WITH DOT ABOVE 0130; T; 0069; # LATIN CAPITAL LETTER I WITH DOT ABOVE # F: full case folding, mappings that cause strings to grow in length. Multiple characters are separated by spaces. # T: special case for uppercase I and dotted uppercase I # - For non-Turkic languages, this mapping is normally not used. # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. if we choose F, and are casefolded into the same If we choose T, we get different outputs. --> , --> Even Option F makes this trouble: In Turkic language, and form the bicameral pair. If turkish people enter an IDN ???.com, they could not reach ???.com. At this very point, locale-independence objective of Stringprep casefolding is not fulfilled. and should be unified into either of them in any locale-independent casefolding. You can find about "locale-independce/non-contextual" objectives in UAX#21, in the example of -> --> casefolding. and are *NOT* the bicameral pair, but for transitive case-insensitive equivalence, those two are unified into in UAX#21. Stringprep should address this issue, and Next CaseFOlding-3.2.?.txt should clarify more about the rquired locale-indepenent/non-contextual casefoldings for . Soobok Lee ----- Original Message ----- From: "Mark Davis" To: "Dan Oscarsson" ; ; ; ; Sent: Tuesday, May 07, 2002 12:37 AM Subject: Re: [idn] 1st stringprep issue: not answered and ignored > The Unicode Consortium recommends that the tables in StringPrep be > updated to encompass Unicode 3.2, which was released in March. > > As a part of this release, there was one change (in addition to new > characters) in case folding. The situation regarding the > dotted/dotless I in the case foldings has been cleaned up by providing > several options, one of which (full case folding without option T) > preserves canonical equivalence (although not normalization forms -- > text still needs to be normalized after case folding). > > http://www.unicode.org/Public/3.2-Update/CaseFolding-3.2.0.txt > > Mark > __________ > > http://www.macchiato.com > > "Eppur si muove" > > ----- Original Message ----- > From: "Dan Oscarsson" > To: ; ; ; > ; > Sent: Monday, May 06, 2002 01:57 > Subject: Re: [idn] 1st stringprep issue: not answered and ignored > > > > > > The point that Soobok Lee shows is a very serious matter. > > The requirement on the ACE form of IDNA is that the same > > name must always result in the same ACE!!!! > > > > If doing casefolding/mapping followed by NFKC results in a > > different code point sequence than doing NFC, casefolding/mapping > and > > NFKC again, we will get DNS lookup failures due to names do not > > match. While hopefully most data entered into stringprep will > > be NFC, some will not. > > > > If the above is true, stringprep/nameprep must be changed so that > > the preparation steps for strings are: > > > > 1) See to that input strings is NFC. > > > > 2) all the steps in stringprep. > > > > > > Dan > > > > -- > > Below i Soobok Lee's text: > > >UTC casefolding (UAX21) is made for char-by-char casefolding, not > for > > >combining sequences, but stringprep blindly applies UAX21 into > them. > > >That is not the problem of UAX21, rather of the stringprep. > > > > > >NFCing before casefolding solves this problem, but this suggestion > > >was also ignored or not discussed in depth. > > > > > >Without any modificationa to UAX21 and NFKC and NFC, we could cure > > >this stringprep errors, simply by adding NFC in > > >step zero in stringprep. > > > > From owner-idn@ops.ietf.org Mon May 6 13:32:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28886 for ; Mon, 6 May 2002 13:32:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174mFC-0004eO-00 for idn-data@psg.com; Mon, 06 May 2002 10:25:50 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 174mFB-0004eI-00 for idn@ops.ietf.org; Mon, 06 May 2002 10:25:49 -0700 Received: from MASTER ([211.219.111.238]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g46HPfA13649 for ; Tue, 7 May 2002 02:25:41 +0900 Message-ID: <012c01c1f523$0a7bf1c0$2b19fea9@temp> From: "Soobok Lee" To: References: <3CD6458E.58A3D737@trab.se> <00aa01c1f513$e6af5ac0$8900a8c0@c1340594a> <00cc01c1f519$9fa235c0$2b19fea9@temp> Subject: Re: [idn] 1st stringprep issue: Date: Tue, 7 May 2002 02:25:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From now on, i would like to remove "not answered and ignored" in the subject line of this thread. Unicode 3.2 came out late March, and IDNA drafts went to IESG early March. The authors and this WG had not enough time and opportunities to discuss about the issues. Casefolding standards are out of control of IETF and often are not in sync with IETF WG activities. I have heard this kind of answer. But, I would point out that there have been hastes in proceeding with current drafts set while relevant UTC works were in progress ,without even mentioning the existence of the serious issues described below. And the *selection* of one version/candidate among many versions/options of casefolding/unicode standards have been always under control of the authors and this WG. And So does the *time* when to proceed. Pressures from outside often result in hastes and mistakes. ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" ; "Dan Oscarsson" ; ; ; Sent: Tuesday, May 07, 2002 1:18 AM Subject: Re: [idn] 1st stringprep issue: not answered and ignored > I read in http://www.unicode.org/Public/3.2-Update/CaseFolding-3.2.0.txt > > > 0130; F; 0069 0307; # LATIN CAPITAL LETTER I WITH DOT ABOVE > 0130; T; 0069; # LATIN CAPITAL LETTER I WITH DOT ABOVE > > # F: full case folding, mappings that cause strings to grow in length. Multiple characters are separated by spaces. > # T: special case for uppercase I and dotted uppercase I > # - For non-Turkic languages, this mapping is normally not used. > # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. > > > if we choose F, > and are casefolded into the same > > If we choose T, we get different outputs. > --> , --> > > Even Option F makes this trouble: > > In Turkic language, and form the bicameral pair. > If turkish people enter an IDN ???.com, they could not reach ???.com. > At this very point, locale-independence objective of Stringprep casefolding is not fulfilled. > and should be unified into either of them in any locale-independent > casefolding. You can find about "locale-independce/non-contextual" objectives in UAX#21, > in the example of -> --> casefolding. and are *NOT* the > bicameral pair, but for transitive case-insensitive equivalence, those two are unified into in UAX#21. > > Stringprep should address this issue, and > Next CaseFOlding-3.2.?.txt should clarify more about the rquired locale-indepenent/non-contextual > casefoldings for . > > > Soobok Lee > > ----- Original Message ----- > From: "Mark Davis" > To: "Dan Oscarsson" ; ; ; ; > > Sent: Tuesday, May 07, 2002 12:37 AM > Subject: Re: [idn] 1st stringprep issue: not answered and ignored > > > > The Unicode Consortium recommends that the tables in StringPrep be > > updated to encompass Unicode 3.2, which was released in March. > > > > As a part of this release, there was one change (in addition to new > > characters) in case folding. The situation regarding the > > dotted/dotless I in the case foldings has been cleaned up by providing > > several options, one of which (full case folding without option T) > > preserves canonical equivalence (although not normalization forms -- > > text still needs to be normalized after case folding). > > > > http://www.unicode.org/Public/3.2-Update/CaseFolding-3.2.0.txt > > > > Mark > > __________ > > > > http://www.macchiato.com > > > > "Eppur si muove" > > > > ----- Original Message ----- > > From: "Dan Oscarsson" > > To: ; ; ; > > ; > > Sent: Monday, May 06, 2002 01:57 > > Subject: Re: [idn] 1st stringprep issue: not answered and ignored > > > > > > > > > > The point that Soobok Lee shows is a very serious matter. > > > The requirement on the ACE form of IDNA is that the same > > > name must always result in the same ACE!!!! > > > > > > If doing casefolding/mapping followed by NFKC results in a > > > different code point sequence than doing NFC, casefolding/mapping > > and > > > NFKC again, we will get DNS lookup failures due to names do not > > > match. While hopefully most data entered into stringprep will > > > be NFC, some will not. > > > > > > If the above is true, stringprep/nameprep must be changed so that > > > the preparation steps for strings are: > > > > > > 1) See to that input strings is NFC. > > > > > > 2) all the steps in stringprep. > > > > > > > > > Dan > > > > > > -- > > > Below i Soobok Lee's text: > > > >UTC casefolding (UAX21) is made for char-by-char casefolding, not > > for > > > >combining sequences, but stringprep blindly applies UAX21 into > > them. > > > >That is not the problem of UAX21, rather of the stringprep. > > > > > > > >NFCing before casefolding solves this problem, but this suggestion > > > >was also ignored or not discussed in depth. > > > > > > > >Without any modificationa to UAX21 and NFKC and NFC, we could cure > > > >this stringprep errors, simply by adding NFC in > > > >step zero in stringprep. > > > > > > > From owner-idn@ops.ietf.org Mon May 6 16:58:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06449 for ; Mon, 6 May 2002 16:58:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174pHq-00089x-00 for idn-data@psg.com; Mon, 06 May 2002 13:40:46 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 174pHp-00089b-00 for idn@ops.ietf.org; Mon, 06 May 2002 13:40:45 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14261; Mon, 6 May 2002 14:40:54 -0600 (MDT) Received: from lillen (vpn-129-156-96-75.EMEA.Sun.COM [129.156.96.75]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g46Kefg01022; Mon, 6 May 2002 22:40:41 +0200 (MEST) Date: Mon, 6 May 2002 22:40:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] 1st stringprep issue: not answered and ignored To: Soobok Lee Cc: idn@ops.ietf.org In-Reply-To: "Your message with ID" <00c501c1f320$2f86a1e0$2b19fea9@temp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Stringprep should have contained warnings about this or included new revised > casefolding operatins/tables, but it didn't . the authors and co-chairs have > ignored this repeated warnings without any responses in this list. This is > not a theoretical issue, but a practical issue because the sequences are > used by modern east-europeans. What type of warning would make sense in stringprep? Is there some warning that makes sense in IDNA as well? Do you have suggested text that folks can review? Erik From owner-idn@ops.ietf.org Mon May 6 18:04:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08809 for ; Mon, 6 May 2002 18:04:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174qRm-0009fJ-00 for idn-data@psg.com; Mon, 06 May 2002 14:55:06 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 174qRl-0009f7-00 for idn@ops.ietf.org; Mon, 06 May 2002 14:55:05 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 174qRj-0000rd-00 for ; Mon, 06 May 2002 14:55:03 -0700 Date: Mon, 6 May 2002 21:55:03 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: [idn] rename ToUnicode? Message-ID: <20020506215503.GD2073@nicemice.net> Reply-To: IETF idn working group References: <20020505215638.GD24050@nicemice.net> <13214244.1020668149@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13214244.1020668149@localhost> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > If one is "ToASCII", then the other is either "FromASCII" or > "ToSomethingElse" (I think...). ToNonACE would work. Both operations take any label as input, so it's the output that distinguishes them, so FromWhatever doesn't make sense. The one thing you can say about the output of ToASCII is that it's always ASCII, so the name ToASCII makes perfect sense. The one thing you can say about the output of ToUnicode is that it's never an ACE (but it could be ASCII or non-ASCII), so the name UnACE or ToNonACE would seem to be the most appropriate. This is not a big deal. If people still prefer ToUnicode, that's fine, I just thought we might be able to find a name that gives the reader better intuition about what it does. AMC From owner-idn@ops.ietf.org Mon May 6 20:43:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12287 for ; Mon, 6 May 2002 20:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174sz2-000CnT-00 for idn-data@psg.com; Mon, 06 May 2002 17:37:36 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 174sz1-000CnM-00 for idn@ops.ietf.org; Mon, 06 May 2002 17:37:35 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g470ab5a003508; Tue, 7 May 2002 02:36:53 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 7 May 2002 02:36:20 +0200 Received: from [10.0.231.44] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 7 May 2002 02:36:19 +0200 Date: Mon, 06 May 2002 20:21:33 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Soobok Lee , Mark Davis , Dan Oscarsson , idn@ops.ietf.org, phoffman@imc.org, david.hopwood@zetnet.co.uk Subject: Re: [idn] 1st stringprep issue: not answered and ignored Message-ID: <14307545.1020716493@localhost> In-Reply-To: <00cc01c1f519$9fa235c0$2b19fea9@temp> References: <3CD6458E.58A3D737@trab.se> <00aa01c1f513$e6af5ac0$8900a8c0@c1340594a> <00cc01c1f519$9fa235c0$2b19fea9@temp> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 07 May 2002 00:36:20.0124 (UTC) FILETIME=[34E585C0:01C1F55F] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-07 01.18 +0900 Soobok Lee wrote: > > 0130; F; 0069 0307; # LATIN CAPITAL LETTER I WITH DOT ABOVE > 0130; T; 0069; # LATIN CAPITAL LETTER I WITH DOT ABOVE Once again (for the nth time). IETF is not to "fix issues" with Unicode. If you want changes in their mappings, go to UTC. If you want changes in for example Nameprep, please suggest changes. Pointing at codepoints doesn't make sense. paf -- feeling like a parrot From owner-idn@ops.ietf.org Mon May 6 20:43:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12300 for ; Mon, 6 May 2002 20:43:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174syf-000CnI-00 for idn-data@psg.com; Mon, 06 May 2002 17:37:13 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 174sye-000CnB-00 for idn@ops.ietf.org; Mon, 06 May 2002 17:37:12 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g470abrA003504 for ; Tue, 7 May 2002 02:36:38 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 7 May 2002 02:36:17 +0200 Received: from [10.0.231.44] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 7 May 2002 02:36:17 +0200 Date: Mon, 06 May 2002 20:20:16 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <14302905.1020716416@localhost> In-Reply-To: <20020506215503.GD2073@nicemice.net> References: <20020505215638.GD24050@nicemice.net> <13214244.1020668149@localhost> <20020506215503.GD2073@nicemice.net> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 07 May 2002 00:36:17.0452 (UTC) FILETIME=[334DCEC0:01C1F55F] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA12300 --On 2002-05-06 21.55 +0000 "Adam M. Costello" wrote: > Patrik Fältström wrote: > >> If one is "ToASCII", then the other is either "FromASCII" or >> "ToSomethingElse" (I think...). > > ToNonACE would work. Why then not "ToACE" and "FromACE". "ToNonACE" feels like double negations, and those constructions are not easy for non-english native people (like myself). paf From owner-idn@ops.ietf.org Mon May 6 21:02:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12671 for ; Mon, 6 May 2002 21:02:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174tHM-000DF8-00 for idn-data@psg.com; Mon, 06 May 2002 17:56:32 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 174tHJ-000DF2-00 for idn@ops.ietf.org; Mon, 06 May 2002 17:56:31 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 174tHI-0001PP-00 for ; Mon, 06 May 2002 17:56:28 -0700 Date: Tue, 7 May 2002 00:56:28 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <20020507005627.GC4306@nicemice.net> Reply-To: IETF idn working group References: <20020505215638.GD24050@nicemice.net> <13214244.1020668149@localhost> <20020506215503.GD2073@nicemice.net> <14302905.1020716416@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14302905.1020716416@localhost> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > Why then not "ToACE" and "FromACE". FromACE doesn't make sense because both operations accept *any* label as input, not just ACE. ToACE doesn't make sense because neither operation always outputs an ACE. ToASCII sometimes outputs an ACE, sometimes not, but it always outputs ASCII, hence the name ToASCII. I don't think there could be a better name for ToASCII than ToASCII, so let's leave that one alone. > "ToNonACE" feels like double negations, and those constructions are > not easy for non-english native people (like myself). Yeah, it is a little contorted. That's why I first thought of UnACE. UnACE is my favorite, but I would be content with any of ToNonACE, UnACE, and ToUnicode. AMC From owner-idn@ops.ietf.org Mon May 6 21:26:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13020 for ; Mon, 6 May 2002 21:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174taD-000Dfj-00 for idn-data@psg.com; Mon, 06 May 2002 18:16:01 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 174taC-000Dfd-00 for idn@ops.ietf.org; Mon, 06 May 2002 18:16:00 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g471FQtm004833 for ; Tue, 7 May 2002 03:15:26 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 7 May 2002 03:15:57 +0200 Received: from [10.0.231.44] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 7 May 2002 03:15:56 +0200 Date: Mon, 06 May 2002 21:14:30 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <14475657.1020719670@localhost> In-Reply-To: <20020507005627.GC4306@nicemice.net> References: <20020505215638.GD24050@nicemice.net> <13214244.1020668149@localhost> <20020506215503.GD2073@nicemice.net> <14302905.1020716416@localhost> <20020507005627.GC4306@nicemice.net> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 07 May 2002 01:15:57.0102 (UTC) FILETIME=[BDAF94E0:01C1F564] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-07 00.56 +0000 "Adam M. Costello" wrote: > UnACE is my favorite, but I would be content with any of ToNonACE, > UnACE, and ToUnicode. As "ToUnicode" can take non-ace as input, naming it unace is wrong as you say. So, why not keep the names we have? paf From owner-idn@ops.ietf.org Tue May 7 00:42:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18781 for ; Tue, 7 May 2002 00:42:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 174wfi-000IMS-00 for idn-data@psg.com; Mon, 06 May 2002 21:33:54 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 174wfh-000IM4-00 for idn@ops.ietf.org; Mon, 06 May 2002 21:33:53 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 174wff-0001rg-00 for ; Mon, 06 May 2002 21:33:51 -0700 Date: Tue, 7 May 2002 04:33:51 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] IDNA questions Message-ID: <20020507043351.GA6557@nicemice.net> Reply-To: IETF idn working group References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Erik Nordmark wrote: > For some code points (like unassigned, private use, non-character, and > surrogate code points) it seems to make sense to prohibit them in both > IHL and IHNL. Agreed. > But why not take the same approach as for ASCII and allow space > characters, control characters, etc in INHL? Good question. I wouldn't mind seeing those characters allowed in non-host IDNs. > The above quote from the IDNA specification with the possible > interpretations of "protocol" doesn't provide much guidance to > registries on what code points can be safely registered i.e. does not > risk to be declared "not a host name" in some later IETF standard. > > I think there can be two different intents here: > 1. The intent is that all restrictions be solely by registries ("name- > handling bodies") based on their local policies of what to register. > No application protocols will restrict the set of allowed code points > beyond what is currently specific in IDNA+nameprep+stringprep. > 2. The intent is at a later date the IETF will produce a specification > for host name syntax (either for specific application protocols > or in general) that will place some additional restrictions. The reason the intent is unclear is that the IDNA authors never agreed on the intent, so we agreed on a document that abstained from expressing the intent. I personally would like to see #2. I think the two-syntax model has served us well. Today's DNS supports an anything-goes syntax (arbitrary ASCII) and also defines a restricted well-behaved syntax (LDH host names). Having an anything-goes syntax means arbitrary protocols with bizarre names can still use the DNS. Having a restricted well-behaved syntax means people can register names that are almost certain to work in any protocols that use domain names, and protocols can use almost any characters they like to delimit names in larger structures. Notice that the additional host syntax restrictions are usually not enforced by applications as names are being passed around and compared. They are usually enforced only when names are created. > If #2 then why can't the document explicitly state that the > intent is that no IETF standard restrict what can be used as an > internationalized host name by prohibiting ? > Presumably could be a reference to a set of > general categories in the Unicode standard. That would be a good idea if we settled on #2. > This would not prevent a future IETF standard to declare that a larger > set of code points can be used in internationalized host names. And > it would not prevent a particular registry to have a policy that only > allows a smaller set of code points. Right. > Avoiding downcasing of ASCII code points by ToASCII in an all-ASCII > label seems a bit odd. > > The reasons I've seen seem to be that some applications would take > the result of ToASCII and use it in protocol fields such as the > From: in SMTP. The effect of having ToASCII downcase an all-ASCII > label is that users will see different case characters when they > upgrade to IDNA-aware applications even though they do not use an IDN > themselves. Thus there might be some noticeable short-term effect > depending on exactly how the IDNA-aware application is coded. Yes, that is my main concern. And also the general principle that extending a standard should not alter the behavior of things that were already covered in the old standard. > The reason I'm asking is because when application protocols start > carrying IDNs in a non-ACE encoding there will still be a need > to nameprep those domain names in order for comparisons to work. > > When that day comes the comparisons of the prepared labels still needs > to use case-insensitive matching for 00..7F code points just because > the preparation didn't downcase the ASCII code points. The IDNA spec does not require applications to actually perform ToASCII and actually perform a case-insensitive ASCII comparison when comparing labels. It merely requires applications to use a procedure that yields the same answer as that procedure. One procedure that meets the requirement is to perform a modified ToASCII that always outputs lower case everything, and then perform an exact comparison. Would you like us to mention that optimization in the spec? We have generally decided not to describe optimizations in the spec, but rather let the spec define correct externally-visible behavior and not concern itself with internal implementation issues. > Thus the current approach seems a bit short-sighted unless there is a > good reason that I don't understand for not case folding ASCII-only > labels. I think maintaining the current behavior for existing names is a good reason. > Section 3 item 3 seems to implicitly prevent Unicode-aware > applications from comparing two nameprepped strings without first > converting them to ACE. Why can't it be made explicit that, as a > result of the design of the ACE algorithm being 1-1, two Unicode > labels compare as equal if and only if the corresponding ACE labels > compare as equal? Correction: Two non-ACE labels compare as equal if and only if the corresponding ACE labels compare as equal. It's a subtle but important distinction. > This would mean that an application, as long as it has applied > ToUnicode on the strings when received from an input method, the > protocol, or some other source, it could do a comparison without ACE > conversion. > > And if case folding was applied to ASCII-only labels just like all > other labels, then the resulting comparison would just need to be a > code point by code point comparison. Be careful. Comparing ToUnicode(X) with ToUnicode(Y) is not a valid comparison of X and Y, because the output of ToUnicode is not necessarily nameprepped. An exact comparison of Nameprep(ToUnicode(X)) and Nameprep(ToUnicode(Y)) is the same as a case-insensitive ASCII comparison of ToASCII(X) and ToASCII(Y) when X and Y are valid labels. But when X and Y are invalid, the former comparison might return a match when the latter comparison would not (because ToASCII would fail). If you don't care about the result of comparing two invalid labels (and I suppose you often wouldn't), then you could use the former comparison. Would you like this alternate comparison procedure described in the spec? Some might see it as unnecessary bloat. I know a faster but more complex method of performing ToUnicode, and I once suggested including both versions in the spec, but we ultimately decided to keep the spec short and leave optimizations to the implementors. Maybe an informational RFC full of optimizations could be drafted after the standard is out of the way. AMC From owner-idn@ops.ietf.org Tue May 7 04:33:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00162 for ; Tue, 7 May 2002 04:33:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1750Az-000Mmu-00 for idn-data@psg.com; Tue, 07 May 2002 01:18:25 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 1750Ay-000Mmo-00 for idn@ops.ietf.org; Tue, 07 May 2002 01:18:24 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01968 for ; Tue, 7 May 2002 02:18:22 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g478ILg23818 for ; Tue, 7 May 2002 10:18:21 +0200 (MEST) Date: Tue, 7 May 2002 10:17:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] IDNA questions To: IETF idn working group In-Reply-To: "Your message with ID" <20020507043351.GA6557@nicemice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > The IDNA spec does not require applications to actually perform ToASCII > and actually perform a case-insensitive ASCII comparison when comparing > labels. It merely requires applications to use a procedure that yields > the same answer as that procedure. One procedure that meets the > requirement is to perform a modified ToASCII that always outputs lower > case everything, and then perform an exact comparison. > > Would you like us to mention that optimization in the spec? We have > generally decided not to describe optimizations in the spec, but rather > let the spec define correct externally-visible behavior and not concern > itself with internal implementation issues. In general I don't think the spec needs to list all possible optimizations. But the fact that the spec says 3) Whenever two labels are compared, they MUST be considered to match if and only if their ASCII forms (obtained by applying ToASCII) match using a case-insensitive ASCII comparison. it would be helpful to point out that this doesn't require applying ToASCII for every comparison. > Be careful. Comparing ToUnicode(X) with ToUnicode(Y) is not a > valid comparison of X and Y, because the output of ToUnicode is not > necessarily nameprepped. An exact comparison of Nameprep(ToUnicode(X)) > and Nameprep(ToUnicode(Y)) is the same as a case-insensitive ASCII > comparison of ToASCII(X) and ToASCII(Y) when X and Y are valid labels. I think this makes sense pointing out in the above text. > But when X and Y are invalid, the former comparison might return a match > when the latter comparison would not (because ToASCII would fail). If > you don't care about the result of comparing two invalid labels (and I > suppose you often wouldn't), then you could use the former comparison. Erik From owner-idn@ops.ietf.org Wed May 8 00:11:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02816 for ; Wed, 8 May 2002 00:11:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 175IUp-000LCq-00 for idn-data@psg.com; Tue, 07 May 2002 20:52:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 175IUo-000LCX-00 for idn@ops.ietf.org; Tue, 07 May 2002 20:52:06 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 91753 for idn@ops.ietf.org; Tue, 07 May 2002 22:52:03 -0500 Message-ID: <3CD8A0E2.BA91AE77@ehsco.com> Date: Tue, 07 May 2002 22:52:03 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] IDNA questions References: <20020507043351.GA6557@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A couple of comments on this discussion. "Adam M. Costello" wrote: > Erik Nordmark wrote: > > But why not take the same approach as for ASCII and allow space > > characters, control characters, etc in INHL? > > Good question. I wouldn't mind seeing those characters allowed in > non-host IDNs. Let me also add my support for this. Protocols should be able to use the full US-ASCII range of 0x00-0x7F if they really have a need to do so. This is already supported in STD13, so not allowing them is guaranteeing eventual problems. > > Avoiding downcasing of ASCII code points by ToASCII in an all-ASCII > > label seems a bit odd. > > > > The reasons I've seen seem to be that some applications would take > > the result of ToASCII and use it in protocol fields such as the > > From: in SMTP. The effect of having ToASCII downcase an all-ASCII > > label is that users will see different case characters when they > > upgrade to IDNA-aware applications even though they do not use an > > IDN themselves. Thus there might be some noticeable short-term > > effect depending on exactly how the IDNA-aware application is coded. > > Yes, that is my main concern. And also the general principle that > extending a standard should not alter the behavior of things that were > already covered in the old standard. Dan O also brought up the issue wrt PTR labels providing domain names as RR data which are sometimes used with case-sensitive access maps. Probably not the best programming in the world but it's out there and also supported by STD13. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 9 08:16:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16961 for ; Thu, 9 May 2002 08:16:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 175mUi-000HT5-00 for idn-data@psg.com; Thu, 09 May 2002 04:54:00 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 175mUh-000HSz-00; Thu, 09 May 2002 04:53:59 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16369; Thu, 9 May 2002 07:53:50 -0400 (EDT) Message-Id: <200205091153.HAA16369@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: idn@ops.ietf.org, ietf-provreg@cafax.se, intloc@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-jseng-idn-admin-00.txt Date: Thu, 09 May 2002 07:53:49 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Name Administration Guideline Author(s) : J. Seng Filename : draft-jseng-idn-admin-00.txt Pages : Date : 08-May-02 There are many complex issues revolving around the internationalized access to domain names (IDN) such as the IDN protocol, IDN deployment, IDN transition and IDN administration. While the IDN working group focuses on the standard track specification on access to IDN, the administration guideline is also necessary to ensure a smooth deployment and transition. This document provides a guideline for all zone administrators, including but not limited to registry/registrars operators and all domain names holders on the administration of these domain names. Comments on this document can send to the authors at idn-admin@jdna.jp. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jseng-idn-admin-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jseng-idn-admin-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020508135851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jseng-idn-admin-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jseng-idn-admin-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020508135851.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri May 10 13:40:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07469 for ; Fri, 10 May 2002 13:40:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176EBs-000I00-00 for idn-data@psg.com; Fri, 10 May 2002 10:28:24 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 176EBr-000Hzs-00 for idn@ops.ietf.org; Fri, 10 May 2002 10:28:23 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/Zus60V0oxiFkFpqbT8xYjA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2GDTCSB; Fri, 10 May 2002 13:27:45 EDT To: idn@ops.ietf.org Cc: idn@ops.ietf.org Date: Fri, 10 May 2002 10:27:20 -0700 Subject: Re: [idn] rename ToUnicode? Message-ID: <20020510.102720.-272797.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Another thought, may be ToNonLDH is a more accurate name. Liana ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Fri May 10 13:46:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07708 for ; Fri, 10 May 2002 13:46:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176E7u-000HwU-00 for idn-data@psg.com; Fri, 10 May 2002 10:24:18 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 176E7t-000HwO-00 for idn@ops.ietf.org; Fri, 10 May 2002 10:24:17 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/w99QBpDkAqawsm8dDNZSMg=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2GDKBVG; Fri, 10 May 2002 13:23:22 EDT To: idn@ops.ietf.org Date: Fri, 10 May 2002 10:22:18 -0700 Subject: Re: [idn] rename ToUnicode? Message-ID: <20020510.102219.-272797.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-45,47-72 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think ToNonAscii is much better than ToUnicode. Since the current ToUnicode protocol can contain other codes such as GB, JIS and many others for localized display puposes and trademark matches. We know that trademarks started as regional issues (Refer to WIPO RFCs). So besides the issue of internationalized tradenames, such as TC/SC, Latin/Greek, Latin/Armenia and Upper/Lower character set insensive issue right now in debate, GB code tradename matches to BIG5 is an issue even we ignore the TC/SC issue of the 20% of the world population problem in this WG. The protocol ToGB, ToBig5, ToJIS, ToKSC, ToISO8859 will be co-exist with ToUnicode. Thus, ToNonAscii is much better in describing what we have in stringprep, where ToUnicode is the forwarding one the existing servers are convergent to. The process could be (screen/keyboard/sound) Input buffer in whatever 1. apply ToGB/ToBIG5/ToUnicode ... for trademark check 2. apply ToACE (or ToUTF-8, ToUTF-16 for whatever ) output unchanged or ACEd 3. apply gethostid/gethostname for tradename match When received from transmission: ToNonAscii if NLDH refuse it (may it be UTF-8, GB, BIG5, JIS, Unicode, ...); if ACEd, decode it with ToUnicode, ToGB, ToJIS, ToUTF-8 ... (for another tradmark match check here before display them?) else unchanged DNS tradenames. Thus ToUnicode should be reserved for higher level trademark matching in the future. Liana On Mon, 6 May 2002 21:55:03 +0000 "Adam M. Costello" writes: > Patrik Fältström wrote: > > > If one is "ToASCII", then the other is either "FromASCII" or > > "ToSomethingElse" (I think...). > > ToNonACE would work. > > Both operations take any label as input, so it's the output that > distinguishes them, so FromWhatever doesn't make sense. > > The one thing you can say about the output of ToASCII is that it's > always ASCII, so the name ToASCII makes perfect sense. > > The one thing you can say about the output of ToUnicode is that it's > never an ACE (but it could be ASCII or non-ASCII), so the name UnACE > or > ToNonACE would seem to be the most appropriate. > > This is not a big deal. If people still prefer ToUnicode, that's > fine, > I just thought we might be able to find a name that gives the reader > better intuition about what it does. > > AMC > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Fri May 10 14:05:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08897 for ; Fri, 10 May 2002 14:05:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176EdH-000IQ4-00 for idn-data@psg.com; Fri, 10 May 2002 10:56:43 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #1) id 176EdG-000IPy-00 for idn@ops.ietf.org; Fri, 10 May 2002 10:56:42 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 6BD2D2E84; Fri, 10 May 2002 19:57:03 +0200 (CEST) Date: Fri, 10 May 2002 19:57:03 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <20020510175703.GA19300@rap.rap.dk> References: <20020505215638.GD24050@nicemice.net> <13214244.1020668149@localhost> <20020506215503.GD2073@nicemice.net> <14302905.1020716416@localhost> <20020507005627.GC4306@nicemice.net> <14475657.1020719670@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14475657.1020719670@localhost> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, May 06, 2002 at 09:14:30PM -0400, Patrik Fältström wrote: > --On 2002-05-07 00.56 +0000 "Adam M. Costello" > wrote: > > > UnACE is my favorite, but I would be content with any of ToNonACE, > > UnACE, and ToUnicode. > > As "ToUnicode" can take non-ace as input, naming it unace is wrong as you > say. > > So, why not keep the names we have? I don't think that ToUnicode is the correct name, as it is really 10646 that it is defined for. So maybe To10646 or ToUcs. Best regards Keld From owner-idn@ops.ietf.org Fri May 10 15:41:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14239 for ; Fri, 10 May 2002 15:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176GB0-000Jn7-00 for idn-data@psg.com; Fri, 10 May 2002 12:35:38 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 176GAz-000Jmo-00 for idn@ops.ietf.org; Fri, 10 May 2002 12:35:37 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 176GAt-0000pf-00 for ; Fri, 10 May 2002 12:35:31 -0700 Date: Fri, 10 May 2002 19:35:31 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] rename ToUnicode? Message-ID: <20020510193531.GA2801@nicemice.net> Reply-To: IETF idn working group References: <20020505215638.GD24050@nicemice.net> <13214244.1020668149@localhost> <20020506215503.GD2073@nicemice.net> <14302905.1020716416@localhost> <20020507005627.GC4306@nicemice.net> <14475657.1020719670@localhost> <20020510175703.GA19300@rap.rap.dk> <20020510.102720.-272797.1.liana.ydisg@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020510.102219.-272797.0.liana.ydisg@juno.com> <20020510175703.GA19300@rap.rap.dk> <20020510.102720.-272797.1.liana.ydisg@juno.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Another thought, may be ToNonLDH is a more accurate name. No, because the output of ToUnicode sometimes is LDH. > I think ToNonAscii is much better than ToUnicode. No, because the output of ToUnicode sometimes is ASCII. The only thing we can say for sure about the output of ToUnicode is that it is never ACE. (Well, and that it's Unicode, but all strings in the IDNA spec are Unicode. Even ASCII strings are Unicode, because Unicode is an extension of ASCII.) The only names I can think of that might be better than ToUnicode are ToNonACE and UnACE. Since no one has expressed support for either of those, I guess we're sticking with ToUnicode. Keld Jørn Simonsen wrote: > I don't think that ToUnicode is the correct name, as it is really > 10646 that it is defined for. The difference between ISO-10646 and Unicode is not relevant here. Both use the same table that maps between code points and characters. The difference (as I understand it) is that Unicode defines lots of additional information about the characters and how to handle them, while ISO-10646 is little more than a table and some encoding forms. AMC From owner-idn@ops.ietf.org Fri May 10 16:15:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15483 for ; Fri, 10 May 2002 16:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176GfA-000KHC-00 for idn-data@psg.com; Fri, 10 May 2002 13:06:48 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 176Gf9-000KH6-00 for idn@ops.ietf.org; Fri, 10 May 2002 13:06:48 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/qKNXuq4FarMpKuOMFIjyJw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2GNVQZC; Fri, 10 May 2002 16:06:21 EDT To: idn@ops.ietf.org Date: Fri, 10 May 2002 13:05:55 -0700 Subject: Re: [idn] rename ToUnicode? Message-ID: <20020510.130555.-426073.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-3,5-38 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would support ToNonACE. Liana On Fri, 10 May 2002 19:35:31 +0000 "Adam M. Costello" writes: > > Another thought, may be ToNonLDH is a more accurate name. > > No, because the output of ToUnicode sometimes is LDH. > > > I think ToNonAscii is much better than ToUnicode. > > No, because the output of ToUnicode sometimes is ASCII. > > The only thing we can say for sure about the output of ToUnicode is > that > it is never ACE. (Well, and that it's Unicode, but all strings in > the > IDNA spec are Unicode. Even ASCII strings are Unicode, because > Unicode > is an extension of ASCII.) > > The only names I can think of that might be better than ToUnicode are > ToNonACE and UnACE. Since no one has expressed support for either of > those, I guess we're sticking with ToUnicode. > > Keld Jørn Simonsen wrote: > > > I don't think that ToUnicode is the correct name, as it is really > > 10646 that it is defined for. > > The difference between ISO-10646 and Unicode is not relevant here. > Both use the same table that maps between code points and characters. > The difference (as I understand it) is that Unicode defines lots of > additional information about the characters and how to handle them, > while ISO-10646 is little more than a table and some encoding forms. > > AMC > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Fri May 10 17:15:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18203 for ; Fri, 10 May 2002 17:15:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176Hbm-000LDD-00 for idn-data@psg.com; Fri, 10 May 2002 14:07:22 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 176Hbl-000LD0-00 for idn@ops.ietf.org; Fri, 10 May 2002 14:07:21 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA06957; Fri, 10 May 2002 14:08:05 -0700 Message-Id: <5.1.0.14.2.20020510135412.0351e080@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 13:54:50 -0700 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Dave Crocker Subject: Re: [idn] Editorial comments on idna Cc: IETF idn working group , "Paul Hoffman / IMC" In-Reply-To: <13214244.1020668149@localhost> References: <20020505215638.GD24050@nicemice.net> <20020505215638.GD24050@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA18203 At 06:55 AM 5/6/2002 +0200, Patrik Fältström wrote: >--On 2002-05-05 21.56 +0000 "Adam M. Costello" > > First, a quick small proposal: The name "UnACE" would more accurately > > reflect the behavior and purpose of ToUnicode. Should we rename it? > >If one is "ToASCII", then the other is either "FromASCII" or >"ToSomethingElse" (I think...). yes. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Fri May 10 17:16:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18298 for ; Fri, 10 May 2002 17:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176Hbm-000LDB-00 for idn-data@psg.com; Fri, 10 May 2002 14:07:22 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 176Hbl-000LCz-00 for idn@ops.ietf.org; Fri, 10 May 2002 14:07:21 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA06960; Fri, 10 May 2002 14:08:05 -0700 Message-Id: <5.1.0.14.2.20020510135543.01da0970@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 14:01:44 -0700 To: Erik Nordmark From: Dave Crocker Subject: Re: [idn] Editorial comments on stringprep Cc: idn@ops.ietf.org In-Reply-To: References: <"Your message with ID" <11503195.1020511069@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:07 PM 5/6/2002 +0200, Erik Nordmark wrote: > > Historically, Unicode Consortium has always stated that mapping to > > lowercase were more consistent and better than mapping to uppercase. At > > least for Unicode before version 2. Don't remember any exact reasons, but > > we can dig it up if you want us to. > >*If* there is such additional reasons it wouldn't >hurt to state that as part of the motivation in the draft. Erik, et al, IETF specifications sometimes explain the reasons for particular choices, but mostly they don't. On the average, we explain far more than ITU or ISO specifications, but far less that a complete historical narrative. I think that the typical guidance is to provide whatever explanation that will help people understand WHAT the specification is, and to avoid explaining the WHY behind a choice unless the choice is so unusual readers will be distracted until they understand the reason for the choice. That is, a specification could explain every decision in great detail, and it always is helpful to explain reasons... or is it? All that explanation can get in the way of reading the actual specification. And the explanation for my sending this long-winded note is that the recent postings on the mailing list frankly seem to be focusing on minor items. All are valid but many/most are minor. Your formal editorial comments were wonderfully diligent. Far better than the IETF norm for Area Director feedback. In such documents, adding minor suggestions is fine, because they are only part of a comprehensive set of comments. The issue is follow-on discussion. We should leave handling of the minor items to the document editors. The minor items do not really affect normative content of the specifications. I find myself wishing that the online discussion would focus only on the essentials, in order to get the specifications published sometime soon. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Fri May 10 18:24:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21212 for ; Fri, 10 May 2002 18:24:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176Ic2-000MJL-00 for idn-data@psg.com; Fri, 10 May 2002 15:11:42 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 176Ic1-000MJE-00 for idn@ops.ietf.org; Fri, 10 May 2002 15:11:41 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/salfsIYn8oXFwEXuNAIlqw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2GV2N76; Fri, 10 May 2002 18:11:23 EDT To: idn@ops.ietf.org Cc: paf@cisco.com, phoffman@imc.org Date: Fri, 10 May 2002 15:09:55 -0700 Subject: Re: [idn] Editorial comments on idna Message-ID: <20020510.150955.-453917.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 1-21 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 10 May 2002 13:54:50 -0700 Dave Crocker writes: > At 06:55 AM 5/6/2002 +0200, Patrik Fältström wrote: > >--On 2002-05-05 21.56 +0000 "Adam M. Costello" > > > First, a quick small proposal: The name "UnACE" would more > accurately > > > reflect the behavior and purpose of ToUnicode. Should we rename > it? > > > >If one is "ToASCII", then the other is either "FromASCII" or > >"ToSomethingElse" (I think...). > > > yes. > > d/ > I start to like to and from. How about ToACE and FromACE, then local implementors can use fromGB-toACE, fromACE-toUnicode etc. without confusion. Liana ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Fri May 10 22:48:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02511 for ; Fri, 10 May 2002 22:48:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176Mje-000PtB-00 for idn-data@psg.com; Fri, 10 May 2002 19:35:50 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 176Mjd-000Psf-00 for idn@ops.ietf.org; Fri, 10 May 2002 19:35:49 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 176MjY-0001hG-00 for ; Fri, 10 May 2002 19:35:44 -0700 Date: Sat, 11 May 2002 02:35:44 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Editorial comments on idna Message-ID: <20020511023544.GA6496@nicemice.net> Reply-To: IETF idn working group References: <20020510.150955.-453917.0.liana.ydisg@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020510.150955.-453917.0.liana.ydisg@juno.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk liana Ye wrote: > How about ToACE and FromACE No, because the output of ToUnicode is not always ACE, and the input of ToASCII is not always ACE. AMC From owner-idn@ops.ietf.org Sat May 11 09:01:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28054 for ; Sat, 11 May 2002 09:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176WEJ-00089v-00 for idn-data@psg.com; Sat, 11 May 2002 05:44:07 -0700 Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu) by psg.com with esmtp (Exim 3.36 #1) id 176WEH-00089k-00 for idn@ops.ietf.org; Sat, 11 May 2002 05:44:06 -0700 Received: from bamdad.org ([194.225.40.24]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g4BCi0E00747 for ; Sat, 11 May 2002 17:14:00 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id g4BD14020917 for ; Sat, 11 May 2002 17:31:05 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Sat, 11 May 2002 17:31:03 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: IDN Subject: [idn] charset for "draft-jseng-idn-admin-00.txt" In-Reply-To: <200205091153.HAA16369@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk After a lot of playing with my browser's charset menu, I still can't find what is the character set for this document: http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-00.txt Would someone help? roozbeh From owner-idn@ops.ietf.org Sat May 11 21:53:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22956 for ; Sat, 11 May 2002 21:53:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 176iLp-000IfO-00 for idn-data@psg.com; Sat, 11 May 2002 18:40:41 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 176iLo-000IfI-00 for idn@ops.ietf.org; Sat, 11 May 2002 18:40:40 -0700 Received: (qmail 97814 invoked from network); 12 May 2002 01:44:22 -0000 Received: from bb-203-125-4-222.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.4.222) by sentosa.post1.com with SMTP; 12 May 2002 01:44:22 -0000 Message-ID: <037e01c1f955$e684e510$4700a8c0@JAMESSONYVAIO> From: "James Seng" To: "Roozbeh Pournader" , "IDN" References: Subject: Re: [idn] charset for "draft-jseng-idn-admin-00.txt" Date: Sun, 12 May 2002 09:39:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, the encoding was UTF-16. I will update it as UTF-8 in the next version. In the meantime, if you need a utf8 version, please see: http://www.spsoft.co.kr/~newcat/newscript/draft-jseng-idn-admin-00.utf8.txt ps: This is not a IDN WG document. Please direct all comments to idn-admin@jdna.jp -James Seng ----- Original Message ----- From: "Roozbeh Pournader" To: "IDN" Sent: Saturday, May 11, 2002 9:01 PM Subject: [idn] charset for "draft-jseng-idn-admin-00.txt" > > After a lot of playing with my browser's charset menu, I still can't find > what is the character set for this document: > > http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-00.txt > > Would someone help? > > roozbeh > > > From owner-idn@ops.ietf.org Mon May 13 02:58:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29225 for ; Mon, 13 May 2002 02:58:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1779YZ-000HTZ-00 for idn-data@psg.com; Sun, 12 May 2002 23:43:39 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 1779YY-000HTT-00 for idn@ops.ietf.org; Sun, 12 May 2002 23:43:39 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g4D6hb619268 for ; Mon, 13 May 2002 08:43:37 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g4D6haj19264 for ; Mon, 13 May 2002 08:43:36 +0200 (METDST) Message-ID: <3CDF6098.4AE5ACC6@trab.se> Date: Mon, 13 May 2002 08:43:36 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] rename ToUnicode? Content-Type: text/plain; charset=iso-8859-1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29225 Adam M. Costello wrote: >Keld Jørn Simonsen wrote: > >> I don't think that ToUnicode is the correct name, as it is really >> 10646 that it is defined for. > >The difference between ISO-10646 and Unicode is not relevant here. >Both use the same table that maps between code points and characters. >The difference (as I understand it) is that Unicode defines lots of >additional information about the characters and how to handle them, >while ISO-10646 is little more than a table and some encoding forms. IETF should refer to official standards organisations if possible. So ToUCS is better than ToUnicode. Dan From owner-idn@ops.ietf.org Mon May 13 07:03:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02953 for ; Mon, 13 May 2002 07:03:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177DUi-000Lxs-00 for idn-data@psg.com; Mon, 13 May 2002 03:55:56 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 177DUh-000Lxl-00 for idn@ops.ietf.org; Mon, 13 May 2002 03:55:55 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 177DUg-0007xk-00 for ; Mon, 13 May 2002 03:55:54 -0700 Date: Mon, 13 May 2002 10:55:53 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] rename ToUnicode? Message-ID: <20020513105553.GC28509@nicemice.net> Reply-To: IETF idn working group References: <3CDF6098.4AE5ACC6@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CDF6098.4AE5ACC6@trab.se> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Oscarsson wrote: > IETF should refer to official standards organisations if possible. Correct me if I'm wrong, but I think ISO-10646 does not define normalization forms or case folding. Therefore IDNA cannot avoid referencing Unicode. Once we reference Unicode, there's no point in referencing ISO-10646, because it doesn't contain anything of interest that isn't already in Unicode. Wouldn't it be ironic for the IETF to dismiss another standard-producing organization as not being official enough? Hasn't that same charge historically been made against the IETF itself? For practical reasons, isn't it preferable to reference a spec that's easily available? The Unicode standard is on the web for anyone to view at no charge. Is the same true of ISO-10646? AMC From owner-idn@ops.ietf.org Mon May 13 07:44:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04268 for ; Mon, 13 May 2002 07:44:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177E1a-000MJL-00 for idn-data@psg.com; Mon, 13 May 2002 04:29:54 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #1) id 177E1Z-000MJF-00 for idn@ops.ietf.org; Mon, 13 May 2002 04:29:54 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 40F772E82; Mon, 13 May 2002 13:30:16 +0200 (CEST) Date: Mon, 13 May 2002 13:30:16 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <20020513113016.GA11208@rap.rap.dk> References: <3CDF6098.4AE5ACC6@trab.se> <20020513105553.GC28509@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020513105553.GC28509@nicemice.net> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, May 13, 2002 at 10:55:53AM +0000, Adam M. Costello wrote: > Dan Oscarsson wrote: > > > IETF should refer to official standards organisations if possible. > > Correct me if I'm wrong, but I think ISO-10646 does not define > normalization forms or case folding. Therefore IDNA cannot avoid > referencing Unicode. Once we reference Unicode, there's no point in > referencing ISO-10646, because it doesn't contain anything of interest > that isn't already in Unicode. ISO does define case folding, and ISO says that given a specific repertoire of 10646 for identifiers you need no normalization. > For practical reasons, isn't it preferable to reference a spec that's > easily available? The Unicode standard is on the web for anyone to view > at no charge. Is the same true of ISO-10646? the ISO 10646 case folding data is available from the web too. It is included in the ISO 14651 standard. Keld From owner-idn@ops.ietf.org Mon May 13 07:46:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04326 for ; Mon, 13 May 2002 07:46:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177E9H-000MPf-00 for idn-data@psg.com; Mon, 13 May 2002 04:37:51 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 177E9H-000MPZ-00 for idn@ops.ietf.org; Mon, 13 May 2002 04:37:51 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 177E9G-0000WL-00 for idn@ops.ietf.org; Mon, 13 May 2002 11:37:50 +0000 Date: Mon, 13 May 2002 07:37:49 -0400 From: John C Klensin To: IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <48374344.1021275469@localhost> In-Reply-To: <20020513105553.GC28509@nicemice.net> References: <20020513105553.GC28509@nicemice.net> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 13 May, 2002 10:55 +0000 "Adam M. Costello" wrote: > Dan Oscarsson wrote: > >> IETF should refer to official standards organisations if >> possible. > > Correct me if I'm wrong, but I think ISO-10646 does not define > normalization forms or case folding. Therefore IDNA cannot > avoid referencing Unicode. Once we reference Unicode, there's > no point in referencing ISO-10646, because it doesn't contain > anything of interest that isn't already in Unicode. > > Wouldn't it be ironic for the IETF to dismiss another > standard-producing organization as not being official enough? > Hasn't that same charge historically been made against the > IETF itself? Adam, for whatever it is worth, a distinction IETF has traditionally made is between public-consensus, open-standards bodies and consortia. We've tried to be especially careful about consortia that have high barriers to entry by interested parties who are not large and well-funded corporations, since such bodies are notoriously subject to capture by their member companies. We've also looked, at least implicitly, at the stability of the materials we are contemplating referencing. E.g., whether the organization, in practice, is committed enough to stability to not change important elements of a referenced document out from under us. Note that the above paragraph doesn't say a thing about the Unicode Consortium or UTC. These are tradeoffs about which the IESG and RFC Editor ultimately need to decide on a case by case basis. The same type of observation applies, I think, to your position that, if we reference one UTC document, we might as well reference Unicode documents exclusively and forget about ISO 10646: Dan's preference, and probably mine (see below), differ from yours, but it is important to see this as a tradeoff, not a hard, fast, or obvious decision. john p.s. If I were making the decisions around here, I'd reference the code point set as "UCS" and then indicate, in the reference text, a pointer to 10646 as authoritative and that the Unicode spec contains the same set of code point mappings. That is more or less what the Unicode spec, as I read it, seems to say. And I'd say that as neutrally as possible. But that is just my personal taste in the matter. From owner-idn@ops.ietf.org Mon May 13 09:38:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09564 for ; Mon, 13 May 2002 09:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177Fu1-000NuD-00 for idn-data@psg.com; Mon, 13 May 2002 06:30:13 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 177Fu0-000Nu6-00 for idn@ops.ietf.org; Mon, 13 May 2002 06:30:13 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14295; Mon, 13 May 2002 07:30:33 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4DDU4g09846; Mon, 13 May 2002 15:30:04 +0200 (MEST) Date: Mon, 13 May 2002 15:29:16 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Editorial comments on stringprep To: Dave Crocker Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.2.20020510135543.01da0970@jay.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Dave, I agree with the essence of your note. This issue is a minor editorial one. So let's move on. Erik >----- Begin Included Message -----< Date: Fri, 10 May 2002 14:01:44 -0700 From: "Dave Crocker" Subject: Re: [idn] Editorial comments on stringprep To: "Erik Nordmark" Cc: idn@ops.ietf.org At 12:07 PM 5/6/2002 +0200, Erik Nordmark wrote: > > Historically, Unicode Consortium has always stated that mapping to > > lowercase were more consistent and better than mapping to uppercase. At > > least for Unicode before version 2. Don't remember any exact reasons, but > > we can dig it up if you want us to. > >*If* there is such additional reasons it wouldn't >hurt to state that as part of the motivation in the draft. Erik, et al, IETF specifications sometimes explain the reasons for particular choices, but mostly they don't. On the average, we explain far more than ITU or ISO specifications, but far less that a complete historical narrative. I think that the typical guidance is to provide whatever explanation that will help people understand WHAT the specification is, and to avoid explaining the WHY behind a choice unless the choice is so unusual readers will be distracted until they understand the reason for the choice. That is, a specification could explain every decision in great detail, and it always is helpful to explain reasons... or is it? All that explanation can get in the way of reading the actual specification. And the explanation for my sending this long-winded note is that the recent postings on the mailing list frankly seem to be focusing on minor items. All are valid but many/most are minor. Your formal editorial comments were wonderfully diligent. Far better than the IETF norm for Area Director feedback. In such documents, adding minor suggestions is fine, because they are only part of a comprehensive set of comments. The issue is follow-on discussion. We should leave handling of the minor items to the document editors. The minor items do not really affect normative content of the specifications. I find myself wishing that the online discussion would focus only on the essentials, in order to get the specifications published sometime soon. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 >----- End Included Message -----< From owner-idn@ops.ietf.org Mon May 13 10:12:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11432 for ; Mon, 13 May 2002 10:12:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177GRn-000OWI-00 for idn-data@psg.com; Mon, 13 May 2002 07:05:07 -0700 Received: from rwcrmhc53.attbi.com ([204.127.198.39]) by psg.com with esmtp (Exim 3.36 #1) id 177GRm-000OW9-00 for idn@ops.ietf.org; Mon, 13 May 2002 07:05:06 -0700 Received: from c1340594a ([12.234.220.89]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020513140503.BRKN22408.rwcrmhc53.attbi.com@c1340594a>; Mon, 13 May 2002 14:05:03 +0000 Message-ID: <003701c1fa87$4ad84160$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Keld Jørn Simonsen" , "IETF idn working group" References: <3CDF6098.4AE5ACC6@trab.se> <20020513105553.GC28509@nicemice.net> <20020513113016.GA11208@rap.rap.dk> Subject: Re: [idn] rename ToUnicode? Date: Mon, 13 May 2002 07:05:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit There is no ISO Standard for case folding; ISO 14651 is for collation. It doesn't provide a case folding; it maps characters to weights, not to other characters. You are wrong about normalization. Many languages require combining marks for correct representation, and once you have more than one combining mark you need a mechanism for determining the ordering. For more about collation, case mapping, and normalization, I suggest you read: http://www.unicode.org/reports/tr10/ http://www.unicode.org/reports/tr21/ http://www.unicode.org/reports/tr15/ Mark (P.S. I will be unable to reply to any answer to this message, since I will be en route to Dublin.) __________ http://www.macchiato.com "Eppur si muove" ----- Original Message ----- From: "Keld Jørn Simonsen" To: "IETF idn working group" Sent: Monday, May 13, 2002 04:30 Subject: Re: [idn] rename ToUnicode? > On Mon, May 13, 2002 at 10:55:53AM +0000, Adam M. Costello wrote: > > Dan Oscarsson wrote: > > > > > IETF should refer to official standards organisations if possible. > > > > Correct me if I'm wrong, but I think ISO-10646 does not define > > normalization forms or case folding. Therefore IDNA cannot avoid > > referencing Unicode. Once we reference Unicode, there's no point in > > referencing ISO-10646, because it doesn't contain anything of interest > > that isn't already in Unicode. > > ISO does define case folding, and ISO says that given a specific > repertoire of 10646 for identifiers you need no normalization. > > > For practical reasons, isn't it preferable to reference a spec that's > > easily available? The Unicode standard is on the web for anyone to view > > at no charge. Is the same true of ISO-10646? > > the ISO 10646 case folding data is available from the web too. > It is included in the ISO 14651 standard. > > Keld > > From owner-idn@ops.ietf.org Mon May 13 10:27:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12400 for ; Mon, 13 May 2002 10:27:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177GiY-000OqL-00 for idn-data@psg.com; Mon, 13 May 2002 07:22:26 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #1) id 177GiX-000OqE-00 for idn@ops.ietf.org; Mon, 13 May 2002 07:22:26 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 086E32E82; Mon, 13 May 2002 16:22:47 +0200 (CEST) Date: Mon, 13 May 2002 16:22:47 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Mark Davis Cc: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen , IETF idn working group Subject: Re: [idn] rename ToUnicode? Message-ID: <20020513142247.GB11478@rap.rap.dk> References: <3CDF6098.4AE5ACC6@trab.se> <20020513105553.GC28509@nicemice.net> <20020513113016.GA11208@rap.rap.dk> <003701c1fa87$4ad84160$8900a8c0@c1340594a> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003701c1fa87$4ad84160$8900a8c0@c1340594a> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, May 13, 2002 at 07:05:49AM -0700, Mark Davis wrote: > There is no ISO Standard for case folding; ISO 14651 is for collation. > It doesn't provide a case folding; it maps characters to weights, not > to other characters. ISO 14651 can also be used for case folding, or for comparison of two strings regardless of case. Best regards keld From owner-idn@ops.ietf.org Mon May 13 16:47:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02343 for ; Mon, 13 May 2002 16:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 177MOJ-0004GB-00 for idn-data@psg.com; Mon, 13 May 2002 13:25:55 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 177MOH-0004G1-00 for idn@ops.ietf.org; Mon, 13 May 2002 13:25:54 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/zgMhxZDT+I9BNlTkMyGCQw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2QE2MCJ; Mon, 13 May 2002 16:23:08 EDT To: idn@ops.ietf.org Date: Mon, 13 May 2002 13:21:49 -0700 Subject: Re: [idn] Editorial comments on idna Message-ID: <20020513.132150.-261611.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-22,24-49 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > How about ToACE and FromACE > > No, because the output of ToUnicode is not always ACE, and the input > of > ToASCII is not always ACE. > My choice of using ACE due to that we are dealing with a new form of encoding - punycode in ASCII. ( By the way, I like punycode, it is technically sounding and cute to be used among programmers.) It is another level of encoding using ASCII. Traditionally (in the last three decades), we call them input-encodings, Big5 encoding, Chinese telegram code, keyboard encoding, Five-Strok code, ... it is easily to name a thousand of them, since there are over 600 such recorded names eight years ago in China when I did the research. While ToASCII and FromASCII may win more vote on this list, but the output/input implys it may contain NLDH following your reasoning, which contradicts to Stringprep/nameprep spec! Since the name will never match exactly what it is anyway, giving some consideration to existing usages of the terms should have a little more weight than we are giving them at this point. Afterall this will be the interface between IDN to all applications for many different natural languages as well as programming langages, especially related to the existing usage on Unicode, GB, Big5, JIS, KSC, ISO8859... At this stage, we may consider it is a minor difference among us, but it is an interface we are designing for a huge mess we know very well is out there watching and waiting. I don't consider the naming is a minor subject in discussing. Another note regarding the use of Unicode in China, it is a table of a supper set of Han characters including CJK and many other human characters( a glyph with sound and name). It is used as the character set standard for newly published dictionaries already. If our naming use toUnicode, then it says two things: 1. We allow the complete set of USC to be published at this time, in fact, only Latin code blocks are in nameprep and able to pass the examination. Which the Chinese user community already has raised complain and have asked CJK to be formally exculded at this time. 2. It excludes other possible encoding forms. Since DNS does not forbit other encoding to pass through, we will have to provide more explanation regarding the undefined area of IDN. Liana From owner-idn@ops.ietf.org Thu May 16 12:14:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00513 for ; Thu, 16 May 2002 12:14:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178NKw-00063Q-00 for idn-data@psg.com; Thu, 16 May 2002 08:38:38 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 178NKv-00063K-00 for idn@ops.ietf.org; Thu, 16 May 2002 08:38:37 -0700 Received: (qmail 67759 invoked from network); 16 May 2002 15:41:58 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.7.219) by sentosa.post1.com with SMTP; 16 May 2002 15:41:58 -0000 Message-ID: <02f401c1fcef$bcd3e070$5500a8c0@JAMESSONYVAIO> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] meeting in Yokohama Date: Thu, 16 May 2002 23:38:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am wondering if people thinks we should have a meeting in IETF Yokohama? If we meet up, I forsee the discussion would be a) What do we do next with the working group b) What about outstanding drafts still in the pool, e.g. IRI, DM-IDNS etc. Whats your opinion? -James Seng From owner-idn@ops.ietf.org Thu May 16 13:26:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03035 for ; Thu, 16 May 2002 13:26:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178OXZ-0007Wm-00 for idn-data@psg.com; Thu, 16 May 2002 09:55:45 -0700 Received: from [66.123.187.68] (helo=bean.ar.com) by psg.com with esmtp (Exim 3.36 #1) id 178OXY-0007Wg-00 for idn@ops.ietf.org; Thu, 16 May 2002 09:55:44 -0700 Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g4GGthIL026247; Thu, 16 May 2002 09:55:43 -0700 (PDT) Date: Thu, 16 May 2002 09:55:43 -0700 (PDT) From: Rick Wesson To: James Seng cc: IETF/IDN WG Subject: Re: [idn] meeting in Yokohama In-Reply-To: <02f401c1fcef$bcd3e070$5500a8c0@JAMESSONYVAIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, 16 May 2002, James Seng wrote: > I am wondering if people thinks we should have a meeting in IETF Yokohama? no. > If we meet up, I forsee the discussion would be > > a) What do we do next with the working group shut it down. -rick From owner-idn@ops.ietf.org Thu May 16 13:38:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03538 for ; Thu, 16 May 2002 13:38:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178OjS-0007in-00 for idn-data@psg.com; Thu, 16 May 2002 10:08:02 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 178OjR-0007if-00 for idn@ops.ietf.org; Thu, 16 May 2002 10:08:01 -0700 Message-ID: <01ac01c1fcfc$172d56d0$0b01a8c0@neteka.inc> From: "Ketu Patel" To: "Rick Wesson" , "James Seng" Cc: "IETF/IDN WG" References: Subject: Re: [idn] meeting in Yokohama Date: Thu, 16 May 2002 13:06:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Rick. ----- Original Message ----- From: "Rick Wesson" To: "James Seng" Cc: "IETF/IDN WG" Sent: May 16, 2002 12:55 PM Subject: Re: [idn] meeting in Yokohama > > > On Thu, 16 May 2002, James Seng wrote: > > > I am wondering if people thinks we should have a meeting in IETF Yokohama? > > no. > > > If we meet up, I forsee the discussion would be > > > > a) What do we do next with the working group > > shut it down. > > -rick > > > > From owner-idn@ops.ietf.org Thu May 16 14:41:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05840 for ; Thu, 16 May 2002 14:41:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178Poi-00090T-00 for idn-data@psg.com; Thu, 16 May 2002 11:17:32 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 178Poh-00090N-00 for idn@ops.ietf.org; Thu, 16 May 2002 11:17:31 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/c7cC0ImPscwuQJI5rCcebw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2XWZUWX; Thu, 16 May 2002 14:17:01 EDT To: wessorh@ar.com Cc: idn@ops.ietf.org Date: Thu, 16 May 2002 11:16:39 -0700 Subject: Re: [idn] meeting in Yokohama Message-ID: <20020516.111639.1744.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 1-25 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 16 May 2002 09:55:43 -0700 (PDT) Rick Wesson writes: > > > On Thu, 16 May 2002, James Seng wrote: > > > I am wondering if people thinks we should have a meeting in IETF > Yokohama? > > no. > > > If we meet up, I forsee the discussion would be > > > > a) What do we do next with the working group > > shut it down. > > -rick If this is what you think, then you may leave the list at anytime, there is no reason for you continue subscribe the list. However, I doubt the above is your comment is about. Could you please give us a little more explaination about your opinion? Liana From owner-idn@ops.ietf.org Thu May 16 15:37:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08234 for ; Thu, 16 May 2002 15:37:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178Qdl-0009r8-00 for idn-data@psg.com; Thu, 16 May 2002 12:10:17 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 178Qdk-0009qw-00 for idn@ops.ietf.org; Thu, 16 May 2002 12:10:16 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA29752; Thu, 16 May 2002 12:11:24 -0700 Message-Id: <5.1.0.14.2.20020516114521.02840418@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 May 2002 11:49:01 -0700 To: Rick Wesson From: Dave Crocker Subject: Re: [idn] meeting in Yokohama Cc: James Seng , IETF/IDN WG In-Reply-To: References: <02f401c1fcef$bcd3e070$5500a8c0@JAMESSONYVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:55 AM 5/16/2002 -0700, Rick Wesson wrote: > > If we meet up, I forsee the discussion would be > > a) What do we do next with the working group > >shut it down. Let me be typically more verbose, while supporting Rick's view: This working group has realistically had only one goal, namely adding support for an international range of characters in domain name strings. That work is completed. The only issue is getting the specifications published. We should focus only on that last task. When it is achieved, this working group will have completed its goal. There well might be follow-on working groups to charter, but they should be treated as entirely independent of the IDN working group. d/ ps. What IS worth pursuing, I think, is orchestrating interoperability testing of the specifications, as soon as is possible. ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Thu May 16 15:52:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08958 for ; Thu, 16 May 2002 15:52:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178R0L-000AEg-00 for idn-data@psg.com; Thu, 16 May 2002 12:33:37 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 178R0L-000AEa-00 for idn@ops.ietf.org; Thu, 16 May 2002 12:33:37 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 178R08-000EI9-00; Thu, 16 May 2002 19:33:24 +0000 Date: Thu, 16 May 2002 15:33:23 -0400 From: John C Klensin To: Dave Crocker cc: James Seng , "IETF/IDN WG" Subject: Re: [idn] meeting in Yokohama Message-ID: <74334510.1021563203@localhost> In-Reply-To: <5.1.0.14.2.20020516114521.02840418@jay.songbird.com> References: <5.1.0.14.2.20020516114521.02840418@jay.songbird.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If only to demonstrate that it does happen occasionally, Dave and I are in complete agreement. john --On Thursday, 16 May, 2002 11:49 -0700 Dave Crocker wrote: > At 09:55 AM 5/16/2002 -0700, Rick Wesson wrote: >> > If we meet up, I forsee the discussion would be >> > a) What do we do next with the working group >> >> shut it down. > > Let me be typically more verbose, while supporting Rick's view: > > This working group has realistically had only one goal, namely > adding support for an international range of characters in > domain name strings. > > That work is completed. The only issue is getting the > specifications published. We should focus only on that last > task. When it is achieved, this working group will have > completed its goal. > > There well might be follow-on working groups to charter, but > they should be treated as entirely independent of the IDN > working group. From owner-idn@ops.ietf.org Thu May 16 17:45:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11743 for ; Thu, 16 May 2002 17:45:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178SmO-000C45-00 for idn-data@psg.com; Thu, 16 May 2002 14:27:20 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 178SmN-000C3y-00 for idn@ops.ietf.org; Thu, 16 May 2002 14:27:19 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/EiLAefUB8OshM4CY6As8CQ=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2X9RGJN; Thu, 16 May 2002 17:24:40 EDT To: dhc@dcrocker.net Cc: idn@ops.ietf.org Date: Thu, 16 May 2002 14:23:39 -0700 Subject: Re: [idn] meeting in Yokohama Message-ID: <20020516.142340.1744.4.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-8,10-46 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In that case, then an IDN2 WG may start and transfers the documents in the IDN pool to IDN2 to deal with. The current IDN WG can finish up and start testing the current specifications, with notice that the code blocks are not published in nameprep (includes CJK code blocks) are not available for testing, and will be transferred to IDN2 for further discussion. Liana On Thu, 16 May 2002 11:49:01 -0700 Dave Crocker writes: > At 09:55 AM 5/16/2002 -0700, Rick Wesson wrote: > > > If we meet up, I forsee the discussion would be > > > a) What do we do next with the working group > > > >shut it down. > > Let me be typically more verbose, while supporting Rick's view: > > This working group has realistically had only one goal, namely > adding > support for an international range of characters in domain name > strings. > > That work is completed. The only issue is getting the > specifications > published. We should focus only on that last task. When it is > achieved, > this working group will have completed its goal. > > There well might be follow-on working groups to charter, but they > should be > treated as entirely independent of the IDN working group. > > d/ > > ps. What IS worth pursuing, I think, is orchestrating > interoperability > testing of the specifications, as soon as is possible. > > > ---------- > Dave Crocker > TribalWise, Inc. > tel +1.408.246.8253; fax +1.408.850.1850 > > From owner-idn@ops.ietf.org Thu May 16 18:18:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12264 for ; Thu, 16 May 2002 18:18:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178TAQ-000CR6-00 for idn-data@psg.com; Thu, 16 May 2002 14:52:10 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 178TAP-000CQw-00 for idn@ops.ietf.org; Thu, 16 May 2002 14:52:10 -0700 Received: from MASTER ([211.197.15.17]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4GLpUA22984; Fri, 17 May 2002 06:51:30 +0900 Message-ID: <02ad01c1fd23$cea7a320$2b19fea9@temp> From: "Soobok Lee" To: "Rick Wesson" , "Dave Crocker" Cc: "James Seng" , "IETF/IDN WG" References: <02f401c1fcef$bcd3e070$5500a8c0@JAMESSONYVAIO> <5.1.0.14.2.20020516114521.02840418@jay.songbird.com> Subject: Re: [idn] meeting in Yokohama Date: Fri, 17 May 2002 06:51:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > > That work is completed. The only issue is getting the specifications > published. This is not true. This WG has no consensus on the problematic drafts, which have failed to reach the level of quality that any mission critical use of IDN requires. From owner-idn@ops.ietf.org Thu May 16 21:13:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16313 for ; Thu, 16 May 2002 21:13:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178Vvf-000Es3-00 for idn-data@psg.com; Thu, 16 May 2002 17:49:07 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 178Vve-000Erv-00 for idn@ops.ietf.org; Thu, 16 May 2002 17:49:06 -0700 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GW8CYL00.0IU; Fri, 17 May 2002 08:49:33 +0800 Message-ID: <001501c1fd3c$73e2e800$4607e29f@xiaodonglee> Reply-To: "Xiaodong LEE" From: "xiaodong lee" To: "James Seng" , "IETF/IDN WG" References: <02f401c1fcef$bcd3e070$5500a8c0@JAMESSONYVAIO> Subject: Re: [idn] meeting in Yokohama Date: Fri, 17 May 2002 08:47:42 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA16313 I think it is necessary to meet each other, coz there maybe some other things to be decided in face to face meeting for so many active persons in IDN WG, e.g. next step for IDN. And with that, we should absorb more people to complete the idn-admin which is the great job. xiaodong ----- 原始邮件 ----- å‘件人: "James Seng" 收件人: "IETF/IDN WG" å‘é€æ—¶é—´: 2002å¹´5月16æ—¥ ä¸‹åˆ 11:38 主题: [idn] meeting in Yokohama | I am wondering if people thinks we should have a meeting in IETF Yokohama? | | If we meet up, I forsee the discussion would be | | a) What do we do next with the working group | b) What about outstanding drafts still in the pool, e.g. IRI, DM-IDNS etc. | | Whats your opinion? | | -James Seng | | | ________________________________________ XiaoDong LEE ( X.D. Lee ) ________________________________________ Chinese Academy of Sciences(CAS)&CNNIC Tel. (O): +86-10-62619750-3020 Email (O): Lee@cnnic.net.cn (P): XiaoDong.Lee@computer.org Homepage : http://xiaodong.n3.net ________________________________________ From owner-idn@ops.ietf.org Thu May 16 21:23:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16490 for ; Thu, 16 May 2002 21:23:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178WIx-000FDh-00 for idn-data@psg.com; Thu, 16 May 2002 18:13:11 -0700 Received: from [66.123.187.68] (helo=bean.ar.com) by psg.com with esmtp (Exim 3.36 #1) id 178WIw-000FDa-00 for idn@ops.ietf.org; Thu, 16 May 2002 18:13:10 -0700 Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g4H1CwIL021427; Thu, 16 May 2002 18:12:58 -0700 (PDT) Date: Thu, 16 May 2002 18:12:58 -0700 (PDT) From: Rick Wesson To: xiaodong lee cc: James Seng , IETF/IDN WG Subject: Re: [idn] meeting in Yokohama In-Reply-To: <001501c1fd3c$73e2e800$4607e29f@xiaodonglee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT xiaodong, just a reminder. no wg decisions are ever decided at face to face meetings in the IETF. if there is more work to be done please state it so that we can decide if we need to continue with the work here or propose another wg and have it fall under a new charter. best, -rick On Fri, 17 May 2002, xiaodong lee wrote: > I think it is necessary to meet each other, coz there maybe some > other things to be decided in face to face meeting for so many > active persons in IDN WG, e.g. next step for IDN. > And with that, we should absorb more people to complete the idn-admin > which is the great job. > > xiaodong > > ----- 原始邮件 ----- > å‘件人: "James Seng" > 收件人: "IETF/IDN WG" > å‘é€æ—¶é—´: 2002å¹´5月16æ—¥ ä¸‹åˆ 11:38 > 主题: [idn] meeting in Yokohama > > > | I am wondering if people thinks we should have a meeting in IETF Yokohama? > | > | If we meet up, I forsee the discussion would be > | > | a) What do we do next with the working group > | b) What about outstanding drafts still in the pool, e.g. IRI, DM-IDNS etc. > | > | Whats your opinion? > | > | -James Seng > | > | > | > > ________________________________________ > > XiaoDong LEE ( X.D. Lee ) > ________________________________________ > Chinese Academy of Sciences(CAS)&CNNIC > Tel. (O): +86-10-62619750-3020 > Email (O): Lee@cnnic.net.cn > (P): XiaoDong.Lee@computer.org > Homepage : http://xiaodong.n3.net > ________________________________________ > From owner-idn@ops.ietf.org Thu May 16 21:40:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16691 for ; Thu, 16 May 2002 21:40:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178WUc-000FRq-00 for idn-data@psg.com; Thu, 16 May 2002 18:25:14 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 178WUb-000FRh-00 for idn@ops.ietf.org; Thu, 16 May 2002 18:25:13 -0700 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GW8EMT00.2KK; Fri, 17 May 2002 09:25:41 +0800 Message-ID: <008c01c1fd41$8081db20$4607e29f@xiaodonglee> Reply-To: "Xiaodong LEE" From: "xiaodong lee" To: "Rick Wesson" Cc: "James Seng" , "IETF/IDN WG" References: Subject: Re: [idn] meeting in Yokohama Date: Fri, 17 May 2002 09:23:51 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA16691 hi, rick, Thanks for your reminder, I know there are many procedures for wg decisions, but face to face meeting is useful for that, right? or no IETF meeting is necessary, right? I have state that we have work to do, I think you didn't review the idn-admin draft, why not read it. though it is not wg draft, it is a complement draft for IDN WG work. xiaodong xiaodong, just a reminder. no wg decisions are ever decided at face to face meetings in the IETF. if there is more work to be done please state it so that we can decide if we need to continue with the work here or propose another wg and have it fall under a new charter. best, -rick On Fri, 17 May 2002, xiaodong lee wrote: > I think it is necessary to meet each other, coz there maybe some > other things to be decided in face to face meeting for so many > active persons in IDN WG, e.g. next step for IDN. > And with that, we should absorb more people to complete the idn-admin > which is the great job. > > xiaodong > > ----- åZYå§<é,®ä»¶ ----- > å'件人: "James Seng" > æ"¶ä»¶äºº: "IETF/IDN WG" > å'é?æ-¶é-´: 2002å¹´5æo^16æ-¥ ä¸<å^ 11:38 > 主é¢~: [idn] meeting in Yokohama > > > | I am wondering if people thinks we should have a meeting in IETF Yokohama? > | > | If we meet up, I forsee the discussion would be > | > | a) What do we do next with the working group > | b) What about outstanding drafts still in the pool, e.g. IRI, DM-IDNS etc. > | > | Whats your opinion? > | > | -James Seng > | > | > | > > ________________________________________ > > XiaoDong LEE ( X.D. Lee ) > ________________________________________ > Chinese Academy of Sciences(CAS)&CNNIC > Tel. (O): +86-10-62619750-3020 > Email (O): Lee@cnnic.net.cn > (P): XiaoDong.Lee@computer.org > Homepage : http://xiaodong.n3.net > ________________________________________ > From owner-idn@ops.ietf.org Thu May 16 21:41:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16743 for ; Thu, 16 May 2002 21:41:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178WYm-000FW4-00 for idn-data@psg.com; Thu, 16 May 2002 18:29:32 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 178WYm-000FVx-00 for idn@ops.ietf.org; Thu, 16 May 2002 18:29:32 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 178WYG-000FDD-00; Fri, 17 May 2002 01:29:00 +0000 Date: Thu, 16 May 2002 21:28:45 -0400 From: John C Klensin To: Xiaodong LEE , James Seng , "IETF/IDN WG" Subject: Re: [idn] meeting in Yokohama Message-ID: <95659266.1021584525@localhost> In-Reply-To: <001501c1fd3c$73e2e800$4607e29f@xiaodonglee> References: <001501c1fd3c$73e2e800$4607e29f@xiaodonglee> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 17 May, 2002 08:47 +0800 xiaodong lee wrote: > I think it is necessary to meet each other, coz there maybe > some other things to be decided in face to face meeting for so > many active persons in IDN WG, e.g. next step for IDN. > And with that, we should absorb more people to complete the > idn-admin which is the great job. For whatever it is worth, and with the understanding that I'm speaking only for myself, I'd suggest a different model. We should finish the small amount of work that is clearly on IDN's agenda and shut it down. The WG has just dragged on too long and accumulated too much baggage and debris. Then, if you (or others) have other agenda items (I know I do), it would be good write the ideas down in the form of a proposal for a BOF or a draft charter for another WG. In other words, shutting IDN down doesn't terminate all of the work that will now have to be done with these names, including examining how they fit into applications and how selected applications protocols should be extended or modified. That work is important and should be done somewhere. But there are few, if any, advantages of trying to fit it into the IDN WG and we have all observed the disadvantages of trying to do so. regards, john From owner-idn@ops.ietf.org Thu May 16 21:52:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17804 for ; Thu, 16 May 2002 21:52:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178WgO-000Fcr-00 for idn-data@psg.com; Thu, 16 May 2002 18:37:24 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 178WgN-000Fck-00 for idn@ops.ietf.org; Thu, 16 May 2002 18:37:23 -0700 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GW8F7N00.VJN; Fri, 17 May 2002 09:38:11 +0800 Message-ID: <00cc01c1fd43$3f5fbe80$4607e29f@xiaodonglee> Reply-To: "Xiaodong LEE" From: "xiaodong lee" To: "John C Klensin" , "James Seng" , "IETF/IDN WG" References: <001501c1fd3c$73e2e800$4607e29f@xiaodonglee> <95659266.1021584525@localhost> Subject: Re: [idn] meeting in Yokohama Date: Fri, 17 May 2002 09:36:20 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA17804 Dear John, Thank you for the suggestion, I see. I think there are one point to be make clear. Just shut it down? how about the four drafts? xiaodong ________________________________________ ----- 原始邮件 ----- å‘件人: "John C Klensin" 收件人: "Xiaodong LEE" ; "James Seng" ; "IETF/IDN WG" å‘é€æ—¶é—´: 2002å¹´5月17æ—¥ ä¸Šåˆ 09:28 主题: Re: [idn] meeting in Yokohama | | | --On Friday, 17 May, 2002 08:47 +0800 xiaodong lee | wrote: | | > I think it is necessary to meet each other, coz there maybe | > some other things to be decided in face to face meeting for so | > many active persons in IDN WG, e.g. next step for IDN. | > And with that, we should absorb more people to complete the | > idn-admin which is the great job. | | For whatever it is worth, and with the understanding that I'm | speaking only for myself, I'd suggest a different model. We | should finish the small amount of work that is clearly on IDN's | agenda and shut it down. The WG has just dragged on too long | and accumulated too much baggage and debris. Then, if you (or | others) have other agenda items (I know I do), it would be good | write the ideas down in the form of a proposal for a BOF or a | draft charter for another WG. In other words, shutting IDN down | doesn't terminate all of the work that will now have to be done | with these names, including examining how they fit into | applications and how selected applications protocols should be | extended or modified. That work is important and should be done | somewhere. But there are few, if any, advantages of trying to | fit it into the IDN WG and we have all observed the | disadvantages of trying to do so. | | regards, | john | | From owner-idn@ops.ietf.org Thu May 16 22:04:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17952 for ; Thu, 16 May 2002 22:04:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178WtL-000Fpg-00 for idn-data@psg.com; Thu, 16 May 2002 18:50:47 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 178WtL-000Fpa-00 for idn@ops.ietf.org; Thu, 16 May 2002 18:50:47 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 178Wt6-000FH0-00; Fri, 17 May 2002 01:50:32 +0000 Date: Thu, 16 May 2002 21:50:31 -0400 From: John C Klensin To: Xiaodong LEE , James Seng , "IETF/IDN WG" Subject: Re: [idn] meeting in Yokohama Message-ID: <96966195.1021585831@localhost> In-Reply-To: <00cc01c1fd43$3f5fbe80$4607e29f@xiaodonglee> References: <00cc01c1fd43$3f5fbe80$4607e29f@xiaodonglee> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 17 May, 2002 09:36 +0800 xiaodong lee wrote: > Thank you for the suggestion, I see. > I think there are one point to be make clear. > Just shut it down? how about the four drafts? I would assume that the current WG isn't going anywhere before the IESG has signed off on the drafts it is now processing. But that end-game state is not justification for holding a meeting in Yokohama unless the ADs conclude that they need one to deal with outstanding issues in the document. And nothing in the various notes Erik has circulated would lead me to predict that, although I could, of course, be wrong. I would think that any new, or so-far-incomplete, work would benefit from being put into the context of a new WG which was chartered and focused on that work. john From owner-idn@ops.ietf.org Thu May 16 22:09:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17993 for ; Thu, 16 May 2002 22:09:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178X2x-000Fzk-00 for idn-data@psg.com; Thu, 16 May 2002 19:00:43 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 178X2w-000Fzd-00 for idn@ops.ietf.org; Thu, 16 May 2002 19:00:43 -0700 Received: from MASTER ([211.197.15.17]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4H20GA24880; Fri, 17 May 2002 11:00:16 +0900 Message-ID: <034001c1fd46$8f21ce60$2b19fea9@temp> From: "Soobok Lee" To: "John C Klensin" , "Xiaodong LEE" , "James Seng" , "IETF/IDN WG" References: <001501c1fd3c$73e2e800$4607e29f@xiaodonglee> <95659266.1021584525@localhost> Subject: Re: [idn] meeting in Yokohama Date: Fri, 17 May 2002 11:00:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dynamic DNS Update (RFC2137) features allow some similar/identically-looking IDN ACE labels to be inserted without any intervention from human administrators. IDN-administration draft efforts, most of which have focus on the idn REGISTRATION, may be ignoring those protocol/security/architectural issues. ACE labels are to be treated and trusted as ASCII ones but it shouldn't . That will be a great blow to the stability,trustworthiness and security of global DNS systems. ----- Original Message ----- From: "John C Klensin" To: "Xiaodong LEE" ; "James Seng" ; "IETF/IDN WG" Sent: Friday, May 17, 2002 10:28 AM Subject: Re: [idn] meeting in Yokohama > > > --On Friday, 17 May, 2002 08:47 +0800 xiaodong lee > wrote: > > > I think it is necessary to meet each other, coz there maybe > > some other things to be decided in face to face meeting for so > > many active persons in IDN WG, e.g. next step for IDN. > > And with that, we should absorb more people to complete the > > idn-admin which is the great job. > > For whatever it is worth, and with the understanding that I'm > speaking only for myself, I'd suggest a different model. We > should finish the small amount of work that is clearly on IDN's > agenda and shut it down. The WG has just dragged on too long > and accumulated too much baggage and debris. Then, if you (or > others) have other agenda items (I know I do), it would be good > write the ideas down in the form of a proposal for a BOF or a > draft charter for another WG. In other words, shutting IDN down > doesn't terminate all of the work that will now have to be done > with these names, including examining how they fit into > applications and how selected applications protocols should be > extended or modified. That work is important and should be done > somewhere. But there are few, if any, advantages of trying to > fit it into the IDN WG and we have all observed the > disadvantages of trying to do so. > > regards, > john > From owner-idn@ops.ietf.org Thu May 16 22:21:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18115 for ; Thu, 16 May 2002 22:21:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178XFT-000GGl-00 for idn-data@psg.com; Thu, 16 May 2002 19:13:39 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 178XFS-000GGf-00 for idn@ops.ietf.org; Thu, 16 May 2002 19:13:39 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 178XF3-000FKC-00; Fri, 17 May 2002 02:13:13 +0000 Date: Thu, 16 May 2002 22:13:13 -0400 From: John C Klensin To: Soobok Lee cc: Xiaodong LEE , James Seng , "IETF/IDN WG" Subject: Re: [idn] meeting in Yokohama Message-ID: <98327985.1021587193@localhost> In-Reply-To: <034001c1fd46$8f21ce60$2b19fea9@temp> References: <034001c1fd46$8f21ce60$2b19fea9@temp> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 17 May, 2002 11:00 +0900 Soobok Lee wrote: > Dynamic DNS Update (RFC2137) features allow some > similar/identically-looking IDN ACE labels to be inserted > without any intervention from human administrators. > IDN-administration draft efforts, most of which have focus on > the idn REGISTRATION, may be ignoring those > protocol/security/architectural issues. ACE labels are to be > treated and trusted as ASCII ones but it shouldn't . That will > be a great blow to the stability,trustworthiness and security > of global DNS systems. I don't know quite how to say this politely, but, so? More specifically and to review the procedures as I understand them: * If you think this is an argument that the current drafts should not be approved, or even subject to an IETF Last Call, try to convince the ADs. If they ignore you and issue a Last Call anyway, you could presumably appeal their decision, although (speaking as an individual), I wouldn't particularly recommend that. * If you believe when an IETF Last Call opens that there are important issues that the WG had declined, or been unable, to address effectively, you should raise the issues --forcefully and with good and specific documentation-- at that point. If you conclude that there is no adequate response, you have the right to use the appeal mechanism at that stage. * If you believe that there are technical issues that should be addressed in a WG, you should propose an appropriate WG with an appropriate charter. It seems very clear to me that the current IDN group, having not been willing to address these issues in the past (at least partially because many people believe they are not within the charter), is not going to address them in useful ways in the future. But the current WG, I believe, should be around long enough to get the documents that are now in front of the IESG finished, and then should be shut down rather than looking for new tasks or picking up discarded ones. Just my opinion. john From owner-idn@ops.ietf.org Fri May 17 04:03:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05305 for ; Fri, 17 May 2002 04:03:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178cPv-000KrL-00 for idn-data@psg.com; Fri, 17 May 2002 00:44:47 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 178cPu-000KrF-00 for idn@ops.ietf.org; Fri, 17 May 2002 00:44:46 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/ZRtXux2U9NIgUySpJLmLgA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G2ZC6USA; Fri, 17 May 2002 03:43:39 EDT To: phoffman@imc.org Cc: idn@ops.ietf.org Date: Fri, 17 May 2002 00:42:45 -0700 Subject: Re: [idn] spelling of Chinese names Message-ID: <20020517.004246.1744.6.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The word "SPELL" in Sprintprep-02 is not correctly describing how concept is used in practise for Chinese: 1. Introduction Other examples are simplified Chinese spellings of names (for example, "") vs. the equivalent traditional Chinese spelling (for example, ""). Different "Spellings" of Chinese names means the following: Hung vs. Huang Wang vs. Wong Yee vs. Yu Xiu vs. Chiu ... These are the "different spellings" of the same characters. I suggest change the sentense to: Other examples are Chinese charater string (for example, "") vs. the other Chinese character string (for example, ""). Which is not touch the TC/SC issue neither to use the word "spelling". Liana From owner-idn@ops.ietf.org Fri May 17 05:57:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06874 for ; Fri, 17 May 2002 05:57:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178eMZ-000MAe-00 for idn-data@psg.com; Fri, 17 May 2002 02:49:27 -0700 Received: from bartok.sidn.nl ([193.176.144.164]) by psg.com with esmtp (Exim 3.36 #1) id 178eMW-000MAL-00 for idn@ops.ietf.org; Fri, 17 May 2002 02:49:25 -0700 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.2/8.12.2) with ESMTP id g4H9nJKF076794; Fri, 17 May 2002 11:49:20 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200205170949.g4H9nJKF076794@bartok.sidn.nl> To: "Soobok Lee" cc: "IETF/IDN WG" Subject: Re: [idn] meeting in Yokohama In-reply-to: Your message of Fri, 17 May 2002 11:00:02 +0900. <034001c1fd46$8f21ce60$2b19fea9@temp> Date: Fri, 17 May 2002 11:49:19 +0200 From: Jaap Akkerhuis Sender: owner-idn@ops.ietf.org Precedence: bulk Dynamic DNS Update (RFC2137) features allow some similar/identically-looking IDN ACE labels to be inserted without any intervention from human administrators. IDN-administration draft efforts, most of which have focus on the idn REGISTRATION, may be ignoring those protocol/security/architectural issues. ACE labels are to be treated and trusted as ASCII ones but it shouldn't . That will be a great blow to the stability,trustworthiness and security of global DNS systems. No sensible registry should allow dynamic updates bypass the registration process. This has nothing to do with IDN. jaap From owner-idn@ops.ietf.org Fri May 17 10:40:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16004 for ; Fri, 17 May 2002 10:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178iYU-000Pos-00 for idn-data@psg.com; Fri, 17 May 2002 07:18:02 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 178iYT-000Pom-00 for idn@ops.ietf.org; Fri, 17 May 2002 07:18:01 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09388; Fri, 17 May 2002 08:17:58 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4HEHvg03498; Fri, 17 May 2002 16:17:57 +0200 (MEST) Date: Fri, 17 May 2002 16:17:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] meeting in Yokohama To: John C Klensin Cc: Xiaodong LEE , James Seng , IETF/IDN WG In-Reply-To: "Your message with ID" <96966195.1021585831@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > I would assume that the current WG isn't going anywhere before > the IESG has signed off on the drafts it is now processing. But > that end-game state is not justification for holding a meeting > in Yokohama unless the ADs conclude that they need one to deal > with outstanding issues in the document. And nothing in the > various notes Erik has circulated would lead me to predict that, > although I could, of course, be wrong. Correct, this AD has no such concerns. My hope is to see I-D versions that address (or explicitly choose to not address :-) my suggestions for editorial clarifications real soon so that we can start the IETF-wide last call. *If* those last calls result in significant issues then the WG will need to decide how to handle them. At which point the WG might decide it needs the high bandwidth communication of a meeting. But it would be useful to be able to make that decision sooner rather than later by getting updated I-Ds out. Erik From owner-idn@ops.ietf.org Mon May 20 08:11:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09641 for ; Mon, 20 May 2002 08:11:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 179llJ-000BfR-00 for idn-data@psg.com; Mon, 20 May 2002 04:55:37 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 179llI-000BfL-00 for idn@ops.ietf.org; Mon, 20 May 2002 04:55:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08377; Mon, 20 May 2002 07:55:17 -0400 (EDT) Message-Id: <200205201155.HAA08377@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-10.txt Date: Mon, 20 May 2002 07:55:17 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Nameprep: A Stringprep Profile for Internationalized Domain Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-10.txt Pages : Date : 17-May-02 This document describes how to prepare internationalized domain name labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-nameprep-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-nameprep-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020517135203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-nameprep-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-nameprep-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517135203.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu May 23 07:48:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05188 for ; Thu, 23 May 2002 07:48:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Aqn4-000ELp-00 for idn-data@psg.com; Thu, 23 May 2002 04:29:54 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17Aqn3-000ELj-00 for idn@ops.ietf.org; Thu, 23 May 2002 04:29:53 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04661; Thu, 23 May 2002 07:29:32 -0400 (EDT) Message-Id: <200205231129.HAA04661@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Date: Thu, 23 May 2002 07:29:31 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Domain Names In Applications (IDNA) Author(s) : P. Faltstrom, P. Hoffman, A. Costello Filename : draft-ietf-idn-idna-08.txt Pages : Date : 22-May-02 Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called IDNA for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using the same octets used in so-called host names today. This representation allows IDNs to be introduced with minimal changes to the existing DNS infrastructure. IDNA is only meant for processing domain names, not free text A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-idna-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-idna-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020522145546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020522145546.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu May 23 10:15:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11483 for ; Thu, 23 May 2002 10:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17AtE1-000H8C-00 for idn-data@psg.com; Thu, 23 May 2002 07:05:53 -0700 Received: from mail.imc.org ([208.184.76.43] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17AtE1-000H85-00 for idn@ops.ietf.org; Thu, 23 May 2002 07:05:53 -0700 Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NE5oL01648 for ; Thu, 23 May 2002 07:05:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200205231129.HAA04661@ietf.org> References: <200205231129.HAA04661@ietf.org> Date: Thu, 23 May 2002 07:05:34 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. This version of the document (hopefully) addresses the issues that Erik Nordmark, our Area Director, brought up after the WG last call. It clarifies some of the topics that we in the Working Group didn't notice were not covered well, and there is much more overview material in the document. There is one significant technical change in the document: it now specifies how to break up a domain name into labels. Earlier drafts said that this had to be done before using ToASCII and ToUnicode, but didn't say how to do it. IDNA now lists the full-stop characters that are used to break up a name. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu May 23 14:16:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21469 for ; Thu, 23 May 2002 14:16:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Awss-000LkI-00 for idn-data@psg.com; Thu, 23 May 2002 11:00:18 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Awsr-000LkC-00 for idn@ops.ietf.org; Thu, 23 May 2002 11:00:17 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93619 for idn@ops.ietf.org; Thu, 23 May 2002 13:00:20 -0500 Message-ID: <3CED2E2D.830FB7BD@ehsco.com> Date: Thu, 23 May 2002 13:00:13 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > Title : Internationalizing Domain Names In Applications (IDNA) This is really close to being a simple codec. The expanded character repertoire and the removal of the mandatory transliteration "requirement" is helpful, as those were both big problems. However, the text still presents some of these issues: | 6.4 Avoiding exposing users to the raw ACE encoding | | All applications that might show the user a domain name obtained from a | domain name slot, such as from gethostbyaddr or part of a mail header, | SHOULD be updated as soon as possible in order to prevent users from | seeing the ACE. This rule still requires transliteration. As has been discussed extensively on this list, this will cause problems with data-types which must never be transliterated. Also interesting that a recent discussion on the ietf-822@imc.org mailing list showed that email people prefer to see the encoding form directly, rather than the original value (at a minimum, this means that users have one preference while admins have a different preference, and that these are different). Also interesting that the URI i18n draft is specifically avoiding the use of transliteration. In light of those facts, I will repeat my multiple earlier statements that this text should state that transliteration MUST NOT occur unless the governing protocols and/or data-types specifications explicitly allow it. The text as written above is an implicit update to these specifications, even though the authoritative parties don't want it. | 1.1 Brief overview for application developers | IDNA requires that implementations process input strings with Nameprep | [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with | Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement | Nameprep and Punycode; neither Nameprep nor Punycode are optional. IDNA needs to be available as a generic codec for use with any profile of stringprep that works with domain names. If another WG needs to develop a stringprep profile (eg, Kerberos), they should not be required to develop another encoding syntax. As such, the dependancy on nameprep should be lightened, perhaps saying "the IDNA algorithms are specifically designed for use with nameprep but can be used with any suitable stringprep profile which requires conversion." Very close otherwise. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 23 20:48:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02045 for ; Thu, 23 May 2002 20:48:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17B33Z-0004zB-00 for idn-data@psg.com; Thu, 23 May 2002 17:35:45 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17B33Y-0004z5-00 for idn@ops.ietf.org; Thu, 23 May 2002 17:35:44 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17B33X-0000PK-00 for ; Thu, 23 May 2002 17:35:43 -0700 Date: Fri, 24 May 2002 00:35:43 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020524003543.GF31836@nicemice.net> Reply-To: IETF idn working group References: <200205231129.HAA04661@ietf.org> <3CED2E2D.830FB7BD@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CED2E2D.830FB7BD@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > | All applications that might show the user a domain name obtained > | from a domain name slot, such as from gethostbyaddr or part of a > | mail header, SHOULD be updated as soon as possible in order to > | prevent users from seeing the ACE. > > this text should state that transliteration MUST NOT occur unless > the governing protocols and/or data-types specifications explicitly > allow it. The text as written above is an implicit update to these > specifications, There is a rule that *requires* the ASCII form to be used in all legacy protocols and data types, and that rule explicitly overrides the rule about hiding ACEs from users. IDNA does not recommend altering protocols or data types in any way; it recommends altering user interfaces. That is what the text you quoted is doing. Applications are welcome to allow users to set their own user interface preferences. For example, most mail applications hide most header fields by default, but allow users to see the full header if they want. This is the same sort of thing. Show the non-ACE form by default, and allow users to see the ACE form if they want. > the dependancy on nameprep should be lightened, perhaps saying "the > IDNA algorithms are specifically designed for use with nameprep but > can be used with any suitable stringprep profile A Stringprep profile suitable for use with domain names would have to be equivalent to Nameprep-followed-by-additional-prohibitions. Otherwise names wouldn't compare correctly when they moved between applications using one profile and applications using another profile. Therefore, it is correct to say that Nameprep is mandatory for IDNA. The specialized versions that you envision would still include Nameprep, even if it's disguised as part of a larger Stringprep profile. AMC From owner-idn@ops.ietf.org Thu May 23 21:37:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03050 for ; Thu, 23 May 2002 21:37:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17B3u0-0006HH-00 for idn-data@psg.com; Thu, 23 May 2002 18:29:56 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17B3u0-0006HB-00 for idn@ops.ietf.org; Thu, 23 May 2002 18:29:56 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93709 for idn@ops.ietf.org; Thu, 23 May 2002 20:29:59 -0500 Message-ID: <3CED9791.F461CBE8@ehsco.com> Date: Thu, 23 May 2002 20:29:53 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> <3CED2E2D.830FB7BD@ehsco.com> <20020524003543.GF31836@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > There is a rule that *requires* the ASCII form to be used in all legacy > protocols and data types, and that rule explicitly overrides the rule > about hiding ACEs from users. > > IDNA does not recommend altering protocols or data types in any way; it > recommends altering user interfaces. That is what the text you quoted > is doing. The delineation between transport and display data is normally clear within a single constrained function or service. The problems occur when display data is used to feed another function. The only way that we can reduce these risks is for the specification to take the safest, most conservative stance -- no default conversions -- and then let the authoritative bodies implement overrides when they know it will be safe, or where *they* are willing to risk any problems which may result from a looser stance. It is beyond the authority of this WG to impose these risks on the rest of the Internet community. I don't expect this to get changed by this team, but I am obligated to go on record with my concerns again. > A Stringprep profile suitable for use with domain names would have to be > equivalent to Nameprep-followed-by-additional-prohibitions. The profiles do not have to be subsets of nameprep. Case variance and character variance are both likely to occur. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri May 24 04:53:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20563 for ; Fri, 24 May 2002 04:53:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BAav-000FF4-00 for idn-data@psg.com; Fri, 24 May 2002 01:38:41 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17BAav-000FEy-00 for idn@ops.ietf.org; Fri, 24 May 2002 01:38:41 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29693; Fri, 24 May 2002 02:39:25 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4O8ccg26877; Fri, 24 May 2002 10:38:38 +0200 (MEST) Date: Fri, 24 May 2002 10:37:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt To: Paul Hoffman / IMC Cc: idn@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Oops - notice the number 1 below: > label. When requirements 2 and 3 both apply, requirement 1 takes > precedence. s/1/2/ Erik From owner-idn@ops.ietf.org Fri May 24 04:54:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20576 for ; Fri, 24 May 2002 04:54:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BAgC-000FLC-00 for idn-data@psg.com; Fri, 24 May 2002 01:44:08 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17BAgB-000FL6-00 for idn@ops.ietf.org; Fri, 24 May 2002 01:44:07 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03513; Fri, 24 May 2002 02:44:06 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4O8i5g27379; Fri, 24 May 2002 10:44:05 +0200 (MEST) Date: Fri, 24 May 2002 10:43:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt To: "Eric A. Hall" Cc: IETF idn working group In-Reply-To: "Your message with ID" <3CED9791.F461CBE8@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > The delineation between transport and display data is normally clear > within a single constrained function or service. The problems occur when > display data is used to feed another function. The only way that we can > reduce these risks is for the specification to take the safest, most > conservative stance -- no default conversions -- and then let the > authoritative bodies implement overrides when they know it will be safe, > or where *they* are willing to risk any problems which may result from a > looser stance. It is beyond the authority of this WG to impose these risks > on the rest of the Internet community. Eric, The way I take this is that *if* we believe there is a strict line between protocols and user-interfaces the document presents a reasonable compromise: No implicit change to the protocols i.e. an authoriative body needs to make an explicit decision to change the protocol, but user-interfaces are changed so that the user sees the friendlier name. It turns out that there isn't such a strict line - one can debate forever e.g. whether the output of a Unix command line tool that can be piped to another tool is a protocol or a user interface; same for the cut&paste buffer. Given this blurring we have the choice between your conservative approach and what the document says. The conservative approach assumes that there are authoritaive bodies for all applications and their user-interfaces, which in many (most?) cases do not exist. So the likely effect of the conservative approach is either that no application user interface is converted to display non-ACE forms (because of wide-spread concern), or that folks do it all over the place because they do not see the concern. Neither would be a good result. So I don't see how the document can provide any more useful advise to developpers with user-interface issues than it does by e.g. saying: > 3) ACE labels obtained from domain name slots SHOULD be hidden from > users except when the use of the non-ASCII form would cause problems or > when the ACE form is explicitly requested. Any more informative advise would have to try to enumerate places (such as cut&paste, Unix commands using stdout, etc) where implementors should think more carefully about this issue. But such a list would by its nature be incomplete, and I don't see how it can say anything more than "think more carefully". Thus I think we need to defer to the judgement of the user interface designers/implementers for this issue in all cases. Erik From owner-idn@ops.ietf.org Fri May 24 04:56:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20637 for ; Fri, 24 May 2002 04:56:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BAjA-000FPd-00 for idn-data@psg.com; Fri, 24 May 2002 01:47:12 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17BAj9-000FPP-00 for idn@ops.ietf.org; Fri, 24 May 2002 01:47:11 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04691 for ; Fri, 24 May 2002 02:47:10 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4O8l9g27892 for ; Fri, 24 May 2002 10:47:09 +0200 (MEST) Date: Fri, 24 May 2002 10:46:12 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk I've asked the IESG secretariat to start one IETF-wide last call on stringprep (by itself) and one IETF-wide last call on the set of idna+nameprep+punycode. Erik From owner-idn@ops.ietf.org Fri May 24 07:28:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23623 for ; Fri, 24 May 2002 07:27:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BD98-000IIA-00 for idn-data@psg.com; Fri, 24 May 2002 04:22:10 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17BD97-000II3-00 for idn@ops.ietf.org; Fri, 24 May 2002 04:22:10 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23451; Fri, 24 May 2002 07:21:47 -0400 (EDT) Message-Id: <200205241121.HAA23451@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-punycode-02.txt Date: Fri, 24 May 2002 07:21:47 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Punycode: An encoding of Unocode for use with IDNA Author(s) : A. Costello Filename : draft-ietf-idn-punycode-02.txt Pages : Date : 23-May-02 Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications [IDNA]. It uniquely and reversibly transforms a Unicode string [UNICODE] into an ASCII string [ASCII]. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-punycode-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-punycode-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020523132710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-punycode-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-punycode-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132710.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri May 24 08:10:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24993 for ; Fri, 24 May 2002 08:10:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BDo9-000J78-00 for idn-data@psg.com; Fri, 24 May 2002 05:04:33 -0700 Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu) by psg.com with esmtp (Exim 3.36 #1) id 17BDo7-000J71-00 for idn@ops.ietf.org; Fri, 24 May 2002 05:04:32 -0700 Received: from bamdad.org (IDENT:root@[194.225.40.24]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g4OC4OE20111; Fri, 24 May 2002 16:34:24 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id g4OCOTc22472; Fri, 24 May 2002 16:54:29 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Fri, 24 May 2002 16:54:29 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: Internet-Drafts@ietf.org cc: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-punycode-02.txt In-Reply-To: <200205241121.HAA23451@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, 24 May 2002 Internet-Drafts@ietf.org wrote: > Title : Punycode: An encoding of Unocode for use with IDNA ^ I really hope this is not in the real title, but just a mistake. roozeh From owner-idn@ops.ietf.org Fri May 24 08:42:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25861 for ; Fri, 24 May 2002 08:42:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BEI3-000JjT-00 for idn-data@psg.com; Fri, 24 May 2002 05:35:27 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17BEI2-000JjM-00 for idn@ops.ietf.org; Fri, 24 May 2002 05:35:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25667; Fri, 24 May 2002 08:35:04 -0400 (EDT) Message-Id: <200205241235.IAA25667@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-punycode-02.txt Date: Fri, 24 May 2002 08:35:03 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Punycode:An encoding of Unicode for use with IDNA Author(s) : A. Costello Filename : draft-ietf-idn-punycode-02.txt Pages : Date : 23-May-02 Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications [IDNA]. It uniquely and reversibly transforms a Unicode string [UNICODE] into an ASCII string [ASCII]. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-punycode-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-punycode-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020524084240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-punycode-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-punycode-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020524084240.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri May 24 09:11:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27195 for ; Fri, 24 May 2002 09:11:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BEhE-000KH3-00 for idn-data@psg.com; Fri, 24 May 2002 06:01:28 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17BEhD-000KGe-00 for idn@ops.ietf.org; Fri, 24 May 2002 06:01:28 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93750; Fri, 24 May 2002 08:01:31 -0500 Message-ID: <3CEE39A4.9FC73403@ehsco.com> Date: Fri, 24 May 2002 08:01:24 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > The conservative approach assumes that there are authoritaive bodies > for all applications and their user-interfaces, which in many (most?) > cases do not exist. Clarification. I do not make any such assumption, and am fully aware that many Internet services do not have any authoritative bodies. But let's be realistic, if nobody is going to step up to modernize the service, then it doesn't really need fixing does it? How hard is it to write an update to finger and get it passed? On the contrary, I am clinging to the robustness principle. Be conservative in what you SEND. We're in heavy and deep violation of that principle when we say it's okay to transliterate any data that looks like a domain name. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri May 24 10:38:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00302 for ; Fri, 24 May 2002 10:38:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BFtT-000Lqw-00 for idn-data@psg.com; Fri, 24 May 2002 07:18:11 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17BFtS-000Lqq-00 for idn@ops.ietf.org; Fri, 24 May 2002 07:18:10 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04742; Fri, 24 May 2002 08:18:09 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4OEI7g27920; Fri, 24 May 2002 16:18:08 +0200 (MEST) Date: Fri, 24 May 2002 16:17:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt To: "Eric A. Hall" Cc: Erik Nordmark , IETF idn working group In-Reply-To: "Your message with ID" <3CEE39A4.9FC73403@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > Clarification. I do not make any such assumption, and am fully aware that > many Internet services do not have any authoritative bodies. But let's be > realistic, if nobody is going to step up to modernize the service, then it > doesn't really need fixing does it? How hard is it to write an update to > finger and get it passed? finger is associated with an over-the-wire procotol, so this might make sense. But what about nslookup, dig, the addresses logged by inetd in a logfile? I read your note as assuming that some authoritative body would make decisions for such things as well, which might be associated with one or more protocols, but unlike finger, isn't the embodiment of the protocol or the main implementation of the protocol. > On the contrary, I am clinging to the robustness principle. Be > conservative in what you SEND. We're in heavy and deep violation of that > principle when we say it's okay to transliterate any data that looks like > a domain name. The robustness principle makes sense in many places, but the IETF (primarely) cares about it being applied to protocols and not APIs or user interfaces. I think the situation is rather analogous to the IPv6 transition. In that space many vendors made user-interfaces (such as netstat, or telnet printing "Trying 1.2.3.4 ...") start outputting IPv6 addresses to the unsuspecting user. The IETF provided no recommendations in this space. To the extent that piping netstat output to an application which barfs on the IPv6 addresses, this is a vendor problem and not an IETF problem. In the IDNA space the document at least point out that implementors should consider the effect of outputting non-ASCII at the user interface. Having the specification mandate UI behavior seems out of place to me. Erik From owner-idn@ops.ietf.org Fri May 24 10:46:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00570 for ; Fri, 24 May 2002 10:46:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BGDj-000MKX-00 for idn-data@psg.com; Fri, 24 May 2002 07:39:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17BGDj-000MKQ-00 for idn@ops.ietf.org; Fri, 24 May 2002 07:39:07 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93765; Fri, 24 May 2002 09:39:11 -0500 Message-ID: <3CEE5088.58E636D0@ehsco.com> Date: Fri, 24 May 2002 09:39:04 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > finger is associated with an over-the-wire procotol, so this might > make sense. Well, a better choice is WHOIS, but I don't want to go there because of there are current activities which murk up the issues. Finger has the same kind of issues though. There are domain names for input (user@domain@proxy), domain names for output (last logged into hostname), and domain names in the protocol message (the input and output). The default condition as specified in IDNA is for the input and output mechanisms to perform conversion, but for the protocol to reuse the legacy format. This is a fine and dandy solution for this particular application, but it should be stated in a standards-track update to the Finger spec, not by us. > But what about nslookup, dig, the addresses logged by inetd in > a logfile? Whatever position we take will bleed over to these other applications. They will look at the spec and say "SHOULD do conversion" and break everything that depends on them. If we embraced the robustness principle, they would look at the spec and say "MUST NOT do conversion" and they would break nothing. To be fair, additional wording about treatment of connection identifiers, structured data and unstructured data is probably required if we want to be thorough. > Having the specification mandate UI behavior seems out of place to me. That is exactly what it does now: SHOULD transliterate anything that looks like an ACE domain name. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri May 24 17:35:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15710 for ; Fri, 24 May 2002 17:35:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BMSW-000H1r-00 for idn-data@psg.com; Fri, 24 May 2002 14:18:48 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17BMSU-000H1f-00 for idn@ops.ietf.org; Fri, 24 May 2002 14:18:46 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17BMST-0004Xf-00 for ; Fri, 24 May 2002 14:18:45 -0700 Date: Fri, 24 May 2002 21:18:45 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-punycode-02.txt Message-ID: <20020524211844.GD16421@nicemice.net> Reply-To: IETF idn working group References: <200205241121.HAA23451@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Roozbeh Pournader wrote: > > Title: Punycode: An encoding of Unocode for use with IDNA > ^ > I really hope this is not in the real title, but just a mistake. It's a typo in the announcement (and on the IDN WG charter page), not in the draft itself. AMC From owner-idn@ops.ietf.org Fri May 24 17:41:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16024 for ; Fri, 24 May 2002 17:41:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BMe5-000HM3-00 for idn-data@psg.com; Fri, 24 May 2002 14:30:45 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17BMe4-000HLx-00 for idn@ops.ietf.org; Fri, 24 May 2002 14:30:45 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17BMe4-0004ed-00 for ; Fri, 24 May 2002 14:30:44 -0700 Date: Fri, 24 May 2002 21:30:44 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: [idn] summary of Punycode changes Message-ID: <20020524213043.GE16421@nicemice.net> Reply-To: IETF idn working group References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk The changes from Punycode draft 01 to 02 are all editorial, not technical. Almost all were motivated by Erik Nordmark's comments, shown below. > The introduction of "bootstring" in the abstract is a bit odd - almost > made me look for bootstring in the references section. Fixed. > Section 4 talks about mixed-case annotations but it hasn't been > mentioned earlier in the document It was mentioned at the end of section 1.1, but not described at all. Now it is briefly described there. > Section 6.2 says at the end what the decoder need not re-encode its > output. Why would it ever need that? That is now explained. > Section 6.3 talks about overflow - but is the information in that > paragraph common to the decoder and encoder? (The text lives only in > the encoder section.) Yes. That information has been relocated to section 6.4 "Overflow handling". > Section 7.1 talks about "the IDNA signature prefix" but the IDNA > spec uses the term "ACE prefix". Fixed. > Split normative vs. non-normative references. All references are non-normative, and the section title now reflects that. Additional changes: A reference to ASCII has been added (RFC 20). The description of example S has been fixed to remove an erroneous claim that it breaks the rules of Nameprep. AMC From owner-idn@ops.ietf.org Fri May 24 18:01:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16796 for ; Fri, 24 May 2002 18:01:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BMzz-000HqT-00 for idn-data@psg.com; Fri, 24 May 2002 14:53:23 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17BMzy-000HqN-00 for idn@ops.ietf.org; Fri, 24 May 2002 14:53:22 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17BMzx-0004l0-00 for ; Fri, 24 May 2002 14:53:21 -0700 Date: Fri, 24 May 2002 21:53:21 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020524215321.GF16421@nicemice.net> Reply-To: IETF idn working group References: <3CEE5088.58E636D0@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <200205231129.HAA04661@ietf.org> <3CED2E2D.830FB7BD@ehsco.com> <20020524003543.GF31836@nicemice.net> <3CED9791.F461CBE8@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CEE5088.58E636D0@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <3CED9791.F461CBE8@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > The profiles do not have to be subsets of nameprep. Case variance and > character variance are both likely to occur. If one application is using Nameprep and another application is using some other profile with different normalization or a different mapping table, then there are going to be pairs of names that match according to one application and don't match according to the other. What good can come of that? "Eric A. Hall" wrote: > If we embraced the robustness principle, they would look at the spec > and say "MUST NOT do conversion" and they would break nothing. > > > Having the specification mandate UI behavior seems out of place to > > me. > > That is exactly what it does now: SHOULD transliterate anything that > looks like an ACE domain name. "SHOULD" is less of a mandate than "MUST NOT", and we leave a big escape hatch: "except when the use of the non-ASCII form would cause problems or when the ACE form is explicitly requested". And by the way, the recommendation does not apply to "anything that looks like an ACE domain name". It applies to "ACE labels obtained from domain name slots". Domain name slots are parts of structured data/interfaces. If something comes from a domain name slot, then it is a domain name, with certainty. If a domain label passes all the checks performed by ToUnicode, then it is an ACE label by definition. There is no guessing. AMC From owner-idn@ops.ietf.org Fri May 24 19:51:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20265 for ; Fri, 24 May 2002 19:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BOjd-000K0G-00 for idn-data@psg.com; Fri, 24 May 2002 16:44:37 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17BOjc-000K0A-00 for idn@ops.ietf.org; Fri, 24 May 2002 16:44:36 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93821 for idn@ops.ietf.org; Fri, 24 May 2002 18:44:40 -0500 Message-ID: <3CEED061.9DD6071B@ehsco.com> Date: Fri, 24 May 2002 18:44:33 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CEE5088.58E636D0@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <200205231129.HAA04661@ietf.org> <3CED2E2D.830FB7BD@ehsco.com> <20020524003543.GF31836@nicemice.net> <3CED9791.F461CBE8@ehsco.com> <20020524215321.GF16421@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > "Eric A. Hall" wrote: > > > The profiles do not have to be subsets of nameprep. Case variance and > > character variance are both likely to occur. > > If one application is using Nameprep and another application is using > some other profile with different normalization or a different mapping > table, then there are going to be pairs of names that match according to > one application and don't match according to the other. What good can > come of that? There is no reason that such a scenario must occur. Applications can and do define their own domain name syntaxes (localpart is different from hostnames, is different from SRV, is different from NetBIOS, is different from Kerberos, and so forth). There is no reason to believe that this scenario will not continue into the future. Under the current wording, all of the applications must use the nameprep rules to use IDNA encoding, even if those rules are not applicable to the application at hand. > "Eric A. Hall" wrote: > > > If we embraced the robustness principle, they would look at the spec > > and say "MUST NOT do conversion" and they would break nothing. > > > > > Having the specification mandate UI behavior seems out of place to > > > me. > > > > That is exactly what it does now: SHOULD transliterate anything that > > looks like an ACE domain name. > > "SHOULD" is less of a mandate than "MUST NOT", RFC 2119: | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there | may exist valid reasons in particular circumstances to ignore a | particular item, but the full implications must be understood and | carefully weighed before choosing a different course. It is not any less of a mandate for the normal case. The normal case is precisely the scenario I am worried with. > and we leave a big escape > hatch: "except when the use of the non-ASCII form would cause problems > or when the ACE form is explicitly requested". IE, people can break stuff all they want until the authoritative body says to stop it. That is exactly the wrong approach. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri May 24 20:25:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21598 for ; Fri, 24 May 2002 20:25:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BPHs-000Kfw-00 for idn-data@psg.com; Fri, 24 May 2002 17:20:00 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17BPHr-000Kfq-00 for idn@ops.ietf.org; Fri, 24 May 2002 17:19:59 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17BPHq-0005Qi-00 for ; Fri, 24 May 2002 17:19:58 -0700 Date: Sat, 25 May 2002 00:19:58 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020525001958.GJ16421@nicemice.net> Reply-To: IETF idn working group References: <3CEE39A4.9FC73403@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <200205231129.HAA04661@ietf.org> <3CED2E2D.830FB7BD@ehsco.com> <20020524003543.GF31836@nicemice.net> <3CED9791.F461CBE8@ehsco.com> <20020524215321.GF16421@nicemice.net> <3CEED061.9DD6071B@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CEED061.9DD6071B@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > Applications can and do define their own domain name syntaxes > (localpart is different from hostnames, is different from SRV, is > different from NetBIOS, is different from Kerberos, and so forth). Maybe you are using the term "domain name" in a more general sense than the rest of us, but domain names are compared in a particular way (for example, they are case insensitive) and are subject to certain constraints (for example, their labels do not exceed 63 bytes). If an application's identifiers conform to all the rules for domain names, they can be called domain names, but if they have their own syntax rules that are incompatible with domain names (for example, if they are case sensitive or if they contain strings longer than 63 bytes) then they are not domain names. > Under the current wording, all of the applications must use the nameprep > rules to use IDNA encoding, even if those rules are not applicable to the > application at hand. If the email folks want to use something similar to IDNA for email address local parts, they can. Their spec can reference IDNA normatively, borrow from it, or even describe only its differences from IDNA, but it will be a standard distinct from IDNA. IDNA itself is for domain names. (By the way, the method of representing email address local parts as domain labels is a limited hack. It cannot support general email addresses, only those whose local parts are case-insensitive and no more than 63 bytes. When this hack is used, local parts get treated like domain labels; the domain name syntax rules don't change.) AMC From owner-idn@ops.ietf.org Sat May 25 20:48:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03091 for ; Sat, 25 May 2002 20:48:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Blsv-0002t5-00 for idn-data@psg.com; Sat, 25 May 2002 17:27:45 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Blsu-0002sz-00 for idn@ops.ietf.org; Sat, 25 May 2002 17:27:44 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93845 for idn@ops.ietf.org; Sat, 25 May 2002 19:27:44 -0500 Message-ID: <3CF02BF8.81D94040@ehsco.com> Date: Sat, 25 May 2002 19:27:36 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CEE39A4.9FC73403@ehsco.com> <3CEE39A4.9FC73403@ehsco.com> <200205231129.HAA04661@ietf.org> <3CED2E2D.830FB7BD@ehsco.com> <20020524003543.GF31836@nicemice.net> <3CED9791.F461CBE8@ehsco.com> <20020524215321.GF16421@nicemice.net> <3CEED061.9DD6071B@ehsco.com> <20020525001958.GJ16421@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > Maybe you are using the term "domain name" in a more general sense > than the rest of us, but domain names are compared in a particular way > (for example, they are case insensitive) and are subject to certain > constraints (for example, their labels do not exceed 63 bytes). I don't want to get pedantic about this, but you are incorrect. Queries treat labels as case-insensitive for comparison purposes but the data is not case-neutral. Data must be provided in the capitalization it was entered. There are applications which are picky about case, and this is supported by STD13. This says nothing about the interpretation of binary data in the eight-bit range. Length has not and will not be an issue in the same way as capitalization, but you are wrong about that as well. The official hostname syntax has at times defined minimum and maximum lengths which were different from the domain name restrictions. EG, maximum of 24 characters for hostnames in RFC 952, even though 63 character domain names were allowed in DNS by RFC 883. These were both synchronized to 63 characters max in RFC1123 although they still have different minimums. > If an > application's identifiers conform to all the rules for domain names, > they can be called domain names, but if they have their own syntax rules > that are incompatible with domain names (for example, if they are case > sensitive or if they contain strings longer than 63 bytes) then they are > not domain names. A domain name is any sequence of labels that can be stored in the DNS. An i18n domain name should be any sequence of labels which can be encoded with IDNA. Currently, you are recursively defining i18n domain names as anything which complies with nameprep, even though we already know that there are applications which will not do so. > > Under the current wording, all of the applications must use the > > nameprep rules to use IDNA encoding, even if those rules are not > > applicable to the application at hand. > > If the email folks want to use something similar to IDNA for email > address local parts, they can. At least naming it will be easy: yacm [yet another codec for mail] -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat May 25 22:09:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04149 for ; Sat, 25 May 2002 22:09:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17BnMX-0004n9-00 for idn-data@psg.com; Sat, 25 May 2002 19:02:25 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17BnMX-0004n3-00 for idn@ops.ietf.org; Sat, 25 May 2002 19:02:25 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA31421; Sat, 25 May 2002 19:04:26 -0700 Message-Id: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 25 May 2002 18:50:12 -0700 To: Erik Nordmark From: Dave Crocker Subject: [idn] protocol vs. UI Cc: "Eric A. Hall" , IETF idn working group In-Reply-To: References: <"Your message with ID" <3CED9791.F461CBE8@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:43 AM 5/24/2002 +0200, Erik Nordmark wrote: >No implicit change to the protocols i.e. an authoriative body needs to >make an explicit decision to change the protocol, but user-interfaces >are changed so that the user sees the friendlier name. Erik, et al, A fun topic, though perhaps academic for this working group. But since the thread has cropped up: Strictly speaking, IDNA very much involves a protocol change. Specifically, it invents a new protocol. One that is layered on top of the existing DNS (and still below the application layer.) That it does not call for a change to the installed DNS base is, of course, fundamental, but IDNA is far more than a UI change. It specifies rules for interaction between independent Internet systems. It's difficult to imagine a better operational definition for "protocol". >It turns out that there isn't such a strict line - one can debate >forever e.g. whether the output of a Unix command line tool that can be piped >to another tool is a protocol or a user interface; same for the cut&paste >buffer. One can define a UI to be sufficiently limited -- and the API between processes to be sufficiently textual -- so that, yes, an interprocess communication convention can be the same as a UI. That trick has served Internet protocols well, but we should not carry it too far. (FTP was expected to be a direct UI. Didn't work, very well, did it?) In reality, the model of Unix piping being a UI is not much of a UI. That style of Unix use a classic batch system: specify the job. Hope it works right. If it doesn't, specify the job all over again. As we have come to expect in the world of GUI's, a UI that pays attention to the needs and capabilities of the U(ser) is pretty poor for interprocess communication. At its best, a good IPC has truly terrible human factors. So let's not get confused. Protocols that use textual strings and human-typable commands are still protocols, not UI's. There is enormous benefit in engineering the protocol to have certain human-friendly characteristics, but that is a long way from being realistically useful as a complete user interface. >So I don't see how the document can provide any more useful advise to >developpers with user-interface issues than it does by e.g. saying: >... >Any more informative advise would have to try to enumerate places (such >as cut&paste, Unix commands using stdout, etc) where implementors should >think >more carefully about this issue. Might be useful for some industrious folk to write a document to assist implementors. It would not be a normative specification of the protocol, but could look at the various choices and implications. This would probably expedite deployment and successful interoperability of IDNA. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon May 27 09:51:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18861 for ; Mon, 27 May 2002 09:51:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CKVQ-0004Ue-00 for idn-data@psg.com; Mon, 27 May 2002 06:25:48 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17CKVP-0004UR-00 for idn@ops.ietf.org; Mon, 27 May 2002 06:25:48 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4RDPfWa000773 for ; Mon, 27 May 2002 15:25:41 +0200 To: idn@ops.ietf.org Subject: [idn] Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> From: Simon Josefsson Date: Mon, 27 May 2002 15:25:40 +0200 In-Reply-To: <200205231129.HAA04661@ietf.org> (Internet-Drafts@ietf.org's message of "Thu, 23 May 2002 07:29:31 -0400") Message-ID: Lines: 33 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) X-Face: %bo>yc#X1.-jVa-; Mon, 27 May 2002 10:10:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CL08-0004t9-00 for idn-data@psg.com; Mon, 27 May 2002 06:57:32 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17CL07-0004t2-00 for idn@ops.ietf.org; Mon, 27 May 2002 06:57:31 -0700 Received: (qmail 11047 invoked from network); 27 May 2002 13:59:57 -0000 Received: from bb-203-125-5-84.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.5.84) by sentosa.post1.com with SMTP; 27 May 2002 13:59:57 -0000 Message-ID: <001701c20586$5eae4130$5b00a8c0@JAMESSONYVAIO> From: "James Seng" To: , "Simon Josefsson" References: <200205231129.HAA04661@ietf.org> Subject: Re: [idn] Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Mon, 27 May 2002 21:56:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit - mapping to/from legacy encoding to ISO/IEC 10646 is available on the CDROM, if you buy the CDROM version from your standard body. - IDNA already specify (or suggested) that if the apps is using legacy encodings, it should transcode to Unicode first. -James Seng > This last sentence seem to brush a practical problem under the rug. > Most systems aren't Unicode based today, so in fact most systems will > have to implement this unspecified transcoding. The Unicode > consortium has not specified how to transform Unicode to/from legacy > encodings. There are some unofficial mappings for ISO 8859-1 charsets > on www.unicode.org/Public/MAPPINGS/, but even unofficial mappings for > other charsets (in particular CJK) is not present. > > Real world scenario: My machine uses ISO-8859-1. I enter 0xB5. How > is this transcoded into Unicode? U+00B5 or U+03BC? There are many > similar examples. > > I think the third paragraph of the security consideration should more > clearly express that IDNA actually is vulnerable to the attack if > machines, like most machines on the Internet, use legacy encodings. > > Some high-level insight on the problem: > http://www.cl.cam.ac.uk/~mgk25/unicode.html#conv > > > From owner-idn@ops.ietf.org Mon May 27 11:06:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20128 for ; Mon, 27 May 2002 11:06:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CLov-0005cB-00 for idn-data@psg.com; Mon, 27 May 2002 07:50:01 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17CLot-0005c1-00 for idn@ops.ietf.org; Mon, 27 May 2002 07:50:00 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4REnvWa001490; Mon, 27 May 2002 16:49:58 +0200 To: "James Seng" Cc: Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> <001701c20586$5eae4130$5b00a8c0@JAMESSONYVAIO> From: Simon Josefsson Date: Mon, 27 May 2002 16:49:57 +0200 In-Reply-To: <001701c20586$5eae4130$5b00a8c0@JAMESSONYVAIO> ("James Seng"'s message of "Mon, 27 May 2002 21:56:46 +0800") Message-ID: Lines: 50 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk "James Seng" writes: > - mapping to/from legacy encoding to ISO/IEC 10646 is available on the > CDROM, if you buy the CDROM version from your standard body. Does the CD include more than what is available on the net from www.unicode.org/Public/MAPPINGS/? I can't find offical mappings for, e.g., ISO-2022 (RFC 1468) online. > - IDNA already specify (or suggested) that if the apps is using legacy > encodings, it should transcode to Unicode first. Yes, but I cannot find where it says how to do it, or where it cites a reference that explains how to do it. That's why I think the security consideration should be more clear that the standard will enable trivial attacks that have security consequences if the document is implemented, because the details of legacy transcoding is left unspecified. If there is no standard way to translate ISO-2022-JP into Unicode, won't different applications implement it differently? Many machines use legacy encodings, how IDNA ends up being implemented on such systems seems to be up to the implementor right now. > > -James Seng > >> This last sentence seem to brush a practical problem under the rug. >> Most systems aren't Unicode based today, so in fact most systems will >> have to implement this unspecified transcoding. The Unicode >> consortium has not specified how to transform Unicode to/from legacy >> encodings. There are some unofficial mappings for ISO 8859-1 charsets >> on www.unicode.org/Public/MAPPINGS/, but even unofficial mappings for >> other charsets (in particular CJK) is not present. >> >> Real world scenario: My machine uses ISO-8859-1. I enter 0xB5. How >> is this transcoded into Unicode? U+00B5 or U+03BC? There are many >> similar examples. >> >> I think the third paragraph of the security consideration should more >> clearly express that IDNA actually is vulnerable to the attack if >> machines, like most machines on the Internet, use legacy encodings. >> >> Some high-level insight on the problem: >> http://www.cl.cam.ac.uk/~mgk25/unicode.html#conv >> >> >> From owner-idn@ops.ietf.org Mon May 27 11:21:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20331 for ; Mon, 27 May 2002 11:21:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CM6i-0005u5-00 for idn-data@psg.com; Mon, 27 May 2002 08:08:24 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17CM6h-0005tz-00 for idn@ops.ietf.org; Mon, 27 May 2002 08:08:23 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g4RF8KR19168 for ; Mon, 27 May 2002 17:08:20 +0200 (METDST) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g4RF8Fs19148; Mon, 27 May 2002 17:08:15 +0200 (METDST) Message-ID: <3CF24C00.3186F15F@trab.se> Date: Mon, 27 May 2002 17:08:48 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org, paf@cisco.com, phoffman@imc.org, idna-spec.amc@nicemice.net Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments on draft-ietf-idn-idna-08.txt - Section 1: Introduction Here it is stated that IDNA does not require changes in any infrastructure and that the existing ASCII name service of DNS is sufficient. This is wrong. Regarding the ASCII names of DNS is sufficient you probably mean that it is sufficient for IDNA. It is not generally sufficient. As DNS allowes non-ASCII octet values in names, IDNA require changes in the infrastructure as IDNA prohibits non-ASCII octet values which in turn breaks backward compatibility. Also, it is stated that resolvers do not need to be changed. But it is probably the resolver libraries that should be changed. By changing the resolver libraries on my system so that applications are not aware of ACE-encoded names, there is a good possibility for me to use domain names containg non-ASCII very quickly as all applications will get it at the same time. If it is implemented using new application code I am not sure I can use non-ASCII in my names, even 10 years in the future. - The definition of what IDN means is complex. It is defined to be a domain name on which ToASCII can be applied without failing. And then in the text IDN is sometimes used to mean a ACE-encoded name and sometimes to mean a UCS-encoded name. This can easily confuse the reader. The basic definition for domain names should be something like: A domain name is a sequence of hierachicaly orderd labels, each label being a sequence of characters. Note: characters, not octets. A domain name must always use the character set of its context! Using the above two rules you get domain names working as most people expect them. Section 3 says in requirement 1) that several different "dots" are allowed between labels when written that way. There are probably more "dots" in UCS that could work. I see no reason to forbid them, unless all are forbidden exepct U+002E. Only one type of dots simplifies comparing of names. Only one type of "dot" should be used in each context. In a Latin based context only U+002E should be used. Most of Section 3 is directly given by the two rules above. 2) If a name is put into an ASCII context, it will have to be converterd into ACE using ToASCII. 3) If a name is put an a non_ASCII context it must be changed to the character set of that context (ToUnicode is not enough, all context are Unicode). 4) When two names are compared they must both be in the same context and be normalised. IDNA mandates (probably) that a domain name used in a link in a html document must be ACE encoded. This is not what is natural for people to use. People will expect a domain name in a html document to use the same character set as the rest of the text. Expect conflicts here. People will not ACE-encode names. It is important for everybody to immediately accept non-ASCII characters in domain names, even though standards are not fully up to date. - Section 6.3 and Section 6.6 In the beginning of the document it is stated that IDNA do not change the DNS system. But in Section 6.3 and 6.6 this draft states a change to DNS conflicting with the existing standard. It says: domain names conating non-ASCII characters must use ACE encoded labels. This is in conflict with current DNS RFCs which allowes domain names containing non-ASCII. It also breaks backward compatibility as that type of domain names are in use today. The difficulty of the current DNS standard is that it does not define what octet values should be used for characters outside the ASCII range. As ISO 01646 is the most recommended form of code point values, the current DNS standard should be updated defining that octet values outside the ASCII range are UTF-8 or ISO 8859-1 (as both are ASCII compatible). Best would be if DNS labels were updated to use UTF-8 or ISO 8859-1 (both can be used as they can easily be identified and handled by the same decoder code). IDNA must NOT restrict current usage and DNS standards making it impossible to update the DNS standard later with a suitable defined handling of non-ASCII octet values! IDNA is not an update of the DNS standard. IDNA is a way to put one more layer on top of DNS by encoding names into ASCII code values. DNS itself must be allowed to evolve in a simple easy manner. Dan From owner-idn@ops.ietf.org Mon May 27 12:02:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21130 for ; Mon, 27 May 2002 12:02:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CMqx-0006b5-00 for idn-data@psg.com; Mon, 27 May 2002 08:56:11 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17CMqw-0006az-00 for idn@ops.ietf.org; Mon, 27 May 2002 08:56:10 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RFu1J17168; Mon, 27 May 2002 08:56:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <200205231129.HAA04661@ietf.org> Date: Mon, 27 May 2002 08:55:59 -0700 To: Simon Josefsson , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Legacy charset conversion in draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:25 PM +0200 5/27/02, Simon Josefsson wrote: >I think the third paragraph of the security consideration should more >clearly express that IDNA actually is vulnerable to the attack if >machines, like most machines on the Internet, use legacy encodings. It isn't clear what "the attack" is. There is clearly a problem for the user when System A transcodes text from Encoding X into Unicode differently than System B does, but I don't see what the security issue is. Could you provide some suggested wording for the security consideration? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon May 27 12:50:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21764 for ; Mon, 27 May 2002 12:50:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CNZl-0007Jf-00 for idn-data@psg.com; Mon, 27 May 2002 09:42:29 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17CNZk-0007JZ-00 for idn@ops.ietf.org; Mon, 27 May 2002 09:42:28 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4RGeiQQ012494; Mon, 27 May 2002 18:40:52 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 27 May 2002 18:41:21 +0200 Received: from [10.0.1.14] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 27 May 2002 18:41:19 +0200 Date: Mon, 27 May 2002 18:18:56 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Dan Oscarsson , idn@ops.ietf.org, phoffman@imc.org, idna-spec.amc@nicemice.net Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <13839118.1022523536@localhost> In-Reply-To: <3CF24C00.3186F15F@trab.se> References: <3CF24C00.3186F15F@trab.se> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 27 May 2002 16:41:20.0588 (UTC) FILETIME=[548630C0:01C2059D] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-27 17.08 +0200 Dan Oscarsson wrote: > As DNS allowes non-ASCII octet values in names, IDNA require > changes in the infrastructure as IDNA prohibits non-ASCII > octet values which in turn breaks backward compatibility. No, it doesn't prohibit non-ASCII in DNS. It only say that labels which pass ToUnicode function are legal IDN names and that other labels which start with the ACE prefix SHOULD be avoided. It is very explicitly stated this way so (a) IDN version 2 (whoever dare to talk about it) can use a different ACE prefix and (b) some different binary encoding of whatever charset can be used in labels. IDNA does NOT change the definition of DNS labels. It only says that labels with a specific prefix are said to be "IDN labels". paf From owner-idn@ops.ietf.org Mon May 27 12:51:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21794 for ; Mon, 27 May 2002 12:51:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CNbV-0007LP-00 for idn-data@psg.com; Mon, 27 May 2002 09:44:17 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17CNbU-0007LJ-00 for idn@ops.ietf.org; Mon, 27 May 2002 09:44:16 -0700 Received: from ns.jck.com ([209.187.148.211] helo=localhost.jck.com) by bs.jck.com with esmtp (Exim 3.35 #1) id 17CNb5-000BsO-00; Mon, 27 May 2002 16:43:51 +0000 Date: Mon, 27 May 2002 12:43:50 -0400 From: John C Klensin To: Dave Crocker cc: Erik Nordmark , "Eric A. Hall" , IETF idn working group Subject: Re: [idn] protocol vs. UI Message-ID: <3611664.1022503430@localhost> In-Reply-To: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> References: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, May 25, 2002 6:50 PM -0700 Dave Crocker wrote: >... > (FTP was expected to be a direct UI. Didn't work, very well, > did it?) >... Dave, Regardless of how I might feel about the rest of your analysis (I'll let you and Erik debate that), the above is just not correct. While FTP apparently lends itself to "direct UI", it was never intended that way. Indeed, features of the protocol, especially some that are not widely implemented of late, _require_ some machinery in the server and client, rather than being "direct" protocol features. For example, use of "TYPE ASCII" transfers requires translation between the character set of the sender and network ASCII and translation by the receiver from network ASCII to local character set and formats. Even when those hosts use ASCII, the translations must accomodate, e.g., conversion of end of line conventions. Better FTP implementations also support asynchronous command operation, reformatting of other external data types, and so on. But the protocol is no more designed as a "direct UI" than SMTP or POP3 (which are at least synchronous) or IMAP (which is still a text-based protocol). And, for whatever it is worth, the first FTP implementations I remember (Tenex, Multics, ITS) all used user interfaces that were different in style from the protocol and, generally, even in the names of some of the verbs (where a command sequence was used, rather than a single command with several qualifiers, as was the normal usage on Tenex). Of course, Whois or Finger might be better examples of your point, but those protocols did not specify the details of either the input or output formats. john From owner-idn@ops.ietf.org Mon May 27 13:07:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21947 for ; Mon, 27 May 2002 13:07:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CNoA-0007bz-00 for idn-data@psg.com; Mon, 27 May 2002 09:57:22 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17CNo9-0007bU-00 for idn@ops.ietf.org; Mon, 27 May 2002 09:57:21 -0700 Received: (qmail 13473 invoked from network); 27 May 2002 16:59:48 -0000 Received: from bb-203-125-5-84.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.5.84) by sentosa.post1.com with SMTP; 27 May 2002 16:59:48 -0000 Message-ID: <005601c2059f$7e12b790$5b00a8c0@JAMESSONYVAIO> From: "James Seng" To: "Simon Josefsson" Cc: "IETF/IDN WG" References: <200205231129.HAA04661@ietf.org><001701c20586$5eae4130$5b00a8c0@JAMESSONYVAIO> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Tue, 28 May 2002 00:56:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Does the CD include more than what is available on the net from > www.unicode.org/Public/MAPPINGS/? Yes and No. I know there are very well documented mappings between ISO 10646 and national standards encoding in CDROM. There are some mappings which is on Unicode website which is not in the CDROM. > I can't find offical mappings for, e.g., ISO-2022 (RFC 1468) online. > > > - IDNA already specify (or suggested) that if the apps is using legacy > > encodings, it should transcode to Unicode first. > > Yes, but I cannot find where it says how to do it, or where it cites a > reference that explains how to do it. That's why I think the security > consideration should be more clear that the standard will enable > trivial attacks that have security consequences if the document is > implemented, because the details of legacy transcoding is left > unspecified. No. ISO-2022 specify a mechanism for encoding reportairs using code switching. The transcoding varies depending on the reportairs (up to 4) you select. And it is not a 1-to-1 mapping with Unicode. Do you mean you want IDNA to specify transcoding algoirthm too? Then how many do you want to support? And why only these set? What if some one creates another encoding? IDNA already say we start from Unicode. How you do the trancoding from your encoding to Unicode is up to you so long you have the right Unicode to start with, ie, the original legacy encoding is irrelevant from IDN perspective. If you did not do your transcoding from legacy to Unicode, then there is a security problem. But the beast you describe is not IDNA. IDNA specifically say it operates from/to Unicode only. > If there is no standard way to translate ISO-2022-JP into Unicode, > won't different applications implement it differently? There are many ways to implement an algorithm. It does not matter how you do it, so long the end results is the same. > Many machines use legacy encodings, how IDNA ends up being implemented > on such systems seems to be up to the implementor right now. Yes and yes. And Toolkits are available for implementors to transcode, MS APIs, ICU, Java I18N API etc. Lets leave the implementation issues to the implementors. -James Seng From owner-idn@ops.ietf.org Mon May 27 13:07:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21962 for ; Mon, 27 May 2002 13:07:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CNtC-0007hV-00 for idn-data@psg.com; Mon, 27 May 2002 10:02:34 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17CNtB-0007hP-00 for idn@ops.ietf.org; Mon, 27 May 2002 10:02:33 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA03594; Mon, 27 May 2002 10:04:54 -0700 Message-Id: <5.1.1.2.2.20020527094736.0346a678@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 27 May 2002 09:58:49 -0700 To: John C Klensin From: Dave Crocker Subject: [idn] FTP history Cc: IETF idn working group In-Reply-To: <3611664.1022503430@localhost> References: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:43 PM 5/27/2002 -0400, John C Klensin wrote: > While FTP apparently lends itself to "direct UI", it >was never intended that way. John, I have a pretty clear recollection that when FTP first came out the folks who wrote the spec honestly expected to be able to sit at a TIP, telnet over to an FTP server, and type commands that would effect file transfers. I even have a vague recollection that this was used to send data to a printer attached to the TIP on another port. >For example, use of "TYPE ASCII" transfers requires translation >between the character set of the sender and network ASCII and >translation by the receiver from network ASCII to local >character set and formats. Not if the receiver can process network ASCII directly, as some did. > Even when those hosts use ASCII, the >translations must accomodate, e.g., conversion of end of line >conventions. Not if they supported CRLF directly, as some did. In fact, that was why CRLF was chosen and end of line, rather than a single character. A single character would have made lexical analysis notably simpler. >But the protocol is no more designed as a "direct UI" than SMTP SMTP came around 10 years later. However, the original MAIL command in FTP was explicitly intended to permit direct typing over a telnet connection. And it was in fact used that way. (That was why there was a distinction between MAIL and MLFL which did the data transfer over a separate FTP data connection.) d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon May 27 13:51:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23043 for ; Mon, 27 May 2002 13:51:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17COQs-0008Gh-00 for idn-data@psg.com; Mon, 27 May 2002 10:37:22 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17COQr-0008Gb-00 for idn@ops.ietf.org; Mon, 27 May 2002 10:37:21 -0700 Received: from ns.jck.com ([209.187.148.211] helo=localhost.jck.com) by bs.jck.com with esmtp (Exim 3.35 #1) id 17COQo-000C2G-00; Mon, 27 May 2002 17:37:19 +0000 Date: Mon, 27 May 2002 13:37:18 -0400 From: John C Klensin To: Dave Crocker cc: IETF idn working group Subject: [idn] Re: FTP history Message-ID: <6819218.1022506638@localhost> In-Reply-To: <5.1.1.2.2.20020527094736.0346a678@jay.songbird.com> References: <5.1.1.2.2.20020527094736.0346a678@jay.songbird.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, May 27, 2002 9:58 AM -0700 Dave Crocker wrote: > At 12:43 PM 5/27/2002 -0400, John C Klensin wrote: >> While FTP apparently lends itself to "direct UI", it >> was never intended that way. > > John, > > I have a pretty clear recollection that when FTP first came > out the folks who wrote the spec honestly expected to be able > to sit at a TIP, telnet over to an FTP server, and type > commands that would effect file transfers. Well, I was part of that working group. Yes, many things were designed so that one could do them from TIPs, however painfully. We could debate about whether it was a primary goal; my recollection about FTP was that it was _designed_ for transfers between hosts with file systems, which the TIP definitely did not have. One might rationally argue that the notion that Internet protocols be based on ASCII verbs and command strings, rather than binary ones, originated in the desire for TIP compatibility, with the debugging and clarity advantages being noticed later (I'm not competent to debate that either way). But, unless I have lost all memory in the ensuing years, the two-stream model was designed to permit asynchronous operation (in particular, to permit the STAT and ABOR commands to operate accurately while data were moving). The ability to do tricks with TIPs was, if anything, secondary. > I even have a vague recollection that this was used to send > data to a printer attached to the TIP on another port. Certainly possible, but I would think somewhat later. >> For example, use of "TYPE ASCII" transfers requires >> translation between the character set of the sender and >> network ASCII and translation by the receiver from network >> ASCII to local character set and formats. > > Not if the receiver can process network ASCII directly, as > some did. If by "process directly" you would include processing in their TTY drivers, certainly so. But the protocol specified that such processing had to be possible. Note that even "translation" of network ASCII into the 4x7+1 format used on most of the PDP-10 derived machines and into the 4x9 format used on Multics, still required some processing at the receiving end: as far as I recall, there were no 28 bit machines on the network. >> Even when those hosts use ASCII, the >> translations must accomodate, e.g., conversion of end of line >> conventions. > > Not if they supported CRLF directly, as some did. In fact, > that was why CRLF was chosen and end of line, rather than a > single character. A single character would have made lexical > analysis notably simpler. Again, our recollections differ. Multics used LF only because the original version of ASCII defined it as a "new line" (first character position on next line) character. It was changed to optional interpretation as an "index" character (same character position on next line) with the first revision of ASCII, in order to accomodate some issues with EBCDIC translation as well as better compatibility with TOPS-10, which used CR internally, at least in its terminal interfaces (another long story, if I recall). CRLF was chosen as end of line in network ASCII because it was reasonably safe (not-data-destructive) under either local interpretation. If I recall, like many other systems before and since, the TIP accepted commands to specify what it would send when it received a raw CR or LF. >> But the protocol is no more designed as a "direct UI" than >> SMTP > > SMTP came around 10 years later. Yes, of course. I didn't mean to suggest otherwise. > However, the original MAIL command in FTP was explicitly > intended to permit direct typing over a telnet connection. > And it was in fact used that way. (That was why there was a > distinction between MAIL and MLFL which did the data transfer > over a separate FTP data connection.) Indeed. And that direct use of the command connection permitted both the use of TIPs and the use of very low-end implementations for sending mail that could not handle two-stream FTP. But I would have thought that would support my point that the protocol was not designed for general direct use as a UI. john From owner-idn@ops.ietf.org Mon May 27 14:02:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23250 for ; Mon, 27 May 2002 14:02:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17COjp-0008bG-00 for idn-data@psg.com; Mon, 27 May 2002 10:56:57 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17COjo-0008bA-00 for idn@ops.ietf.org; Mon, 27 May 2002 10:56:57 -0700 Received: (qmail 13850 invoked from network); 27 May 2002 17:59:22 -0000 Received: from bb-203-125-5-84.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.5.84) by sentosa.post1.com with SMTP; 27 May 2002 17:59:22 -0000 Message-ID: <00b701c205a7$d012de50$5b00a8c0@JAMESSONYVAIO> From: "James Seng" To: "James Seng" , "Simon Josefsson" Cc: "IETF/IDN WG" References: <200205231129.HAA04661@ietf.org><001701c20586$5eae4130$5b00a8c0@JAMESSONYVAIO> <005601c2059f$7e12b790$5b00a8c0@JAMESSONYVAIO> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Tue, 28 May 2002 01:56:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me clarify myself: If you looking for a 1-to-1 code point mapping between ISO-2022 and ISO 10646, then there is no such table. ISO-2022 is design quite differently, depending on the set of reportairs you operate upon. -James Seng > No. ISO-2022 specify a mechanism for encoding reportairs using code > switching. The transcoding varies depending on the reportairs (up to 4) you > select. And it is not a 1-to-1 mapping with Unicode. From owner-idn@ops.ietf.org Mon May 27 14:14:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23359 for ; Mon, 27 May 2002 14:14:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17COqw-0008kH-00 for idn-data@psg.com; Mon, 27 May 2002 11:04:18 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17COqw-0008kB-00 for idn@ops.ietf.org; Mon, 27 May 2002 11:04:18 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA04999; Mon, 27 May 2002 11:06:38 -0700 Message-Id: <5.1.0.14.2.20020527104508.02b34800@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 May 2002 11:02:23 -0700 To: John C Klensin From: Dave Crocker Subject: [idn] Re: FTP history Cc: IETF idn working group In-Reply-To: <6819218.1022506638@localhost> References: <5.1.1.2.2.20020527094736.0346a678@jay.songbird.com> <5.1.1.2.2.20020527094736.0346a678@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk ain't history fun... At 01:37 PM 5/27/2002 -0400, John C Klensin wrote: > Yes, many things were >designed so that one could do them from TIPs, however painfully. >We could debate about whether it was a primary goal; Consideration of the ability to enter user commands "directly" via TIP Telnet was an explicit consideration in specification meetings in those days. That was my only point: Folks thought that they were providing a UI environment. In fact they were not. They were providing an environment that permitting human data entry, which is a far cry from anything that can be called a UI for anything other than programmers, and not really even then. > my >recollection about FTP was that it was _designed_ for transfers >between hosts with file systems, which the TIP definitely did >not have. That statement does not contradict my observation about the design of the command and response interface. In fact, that was the whole point: The work at that time was an experiment in defining protocols that were simultaneously inter-system communication interfaces AND user interfaces. > One might rationally argue that the notion that >Internet protocols be based on ASCII verbs and command strings, >rather than binary ones, originated in the desire for TIP >compatibility, and TIP compatibility was not for programmatic interfacing. it was for humans. That was the simplistic definition of 'user interface' back then. Now, usability work pays more attention to a richer range of cognitive factors. >But, unless I have lost all memory in the ensuing years, the >two-stream model was designed to permit asynchronous operation >(in particular, to permit the STAT and ABOR commands to operate >accurately while data were moving). right. sit on a tip. direct transfer between two remote machines. have the ability to issue commands over the command channel while the transfer is taking place between the two remote servers. > The ability to do tricks >with TIPs was, if anything, secondary. > > > I even have a vague recollection that this was used to send > > data to a printer attached to the TIP on another port. > >Certainly possible, but I would think somewhat later. I recall it in the 1973 timeframe. I only went to the last FTP specification meeting. It was in 1973. >If by "process directly" you would include processing in their >TTY drivers, certainly so. But the protocol specified that such >processing had to be possible. Note that even "translation" of >network ASCII into the 4x7+1 format used on most of the PDP-10 >derived machines and into the 4x9 format used on Multics, still >required some processing at the receiving end: as far as I >recall, there were no 28 bit machines on the network. There were all sorts of machines on the net. I did not say that all of them processed CRLF directly. I said that some of them did. To be more precise, some of them could productively take raw data from the net and shove it to a destination like a printer or a TTY, with no translation. >Again, our recollections differ. Multics used LF only because >the original version of ASCII defined it as a "new line" Again, I did not say that all machines handled crlf unchanged. I said that some did. And I said that that was a factor in the choice of crlf as eol character, rather than choosing the much more convenient model of a single character. > >> But the protocol is no more designed as a "direct UI" than > >> SMTP > > > > SMTP came around 10 years later. > >Yes, of course. I didn't mean to suggest otherwise. Forgive my confusion. You were introducing a number of protocol references as countering my claim that application protocol work in the early/mid-70's was trying to make protocol command environments work both for IPC and for UIs. Since I was not claiming that all Internet protocols were designed with this intent, I am unclear how my point is supported or refuted by citing protocols that were not designed with this intent, especially when they were designed 10 years later. One should note, however, that SMTP did not retain the two-channel model and that typability was part of the factor. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon May 27 14:29:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23456 for ; Mon, 27 May 2002 14:29:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CP6s-00094d-00 for idn-data@psg.com; Mon, 27 May 2002 11:20:46 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17CP6r-00094X-00 for idn@ops.ietf.org; Mon, 27 May 2002 11:20:45 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4RIKZWa002851; Mon, 27 May 2002 20:20:35 +0200 To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> From: Simon Josefsson Date: Mon, 27 May 2002 20:20:35 +0200 In-Reply-To: (Paul Hoffman / IMC's message of "Mon, 27 May 2002 08:55:59 -0700") Message-ID: Lines: 121 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Paul Hoffman / IMC writes: > At 3:25 PM +0200 5/27/02, Simon Josefsson wrote: >>I think the third paragraph of the security consideration should more >>clearly express that IDNA actually is vulnerable to the attack if >>machines, like most machines on the Internet, use legacy encodings. > > It isn't clear what "the attack" is. There is clearly a problem for > the user when System A transcodes text from Encoding X into Unicode > differently than System B does, but I don't see what the security > issue is. Could you provide some suggested wording for the security > consideration? The basic attack: Alice runs on host that uses Latin-1 for input/output and enters www.µbank.com (where µ is 8859-1 0xB5). The domain is registered using U+00B5, but Alice's application transcode the string using U+03BC. Either Alice can't connect (if the other domain doesn't exist) or she ends up talking to someone else (if the other domain does exist). There are many arguments that can be raised on the applicability of the simple attack: 1 You shouldn't map ISO-8859-1 0xB5 into U+03BC, the application is broken and should map it into U+00B5. My reply: This might be true, but this doesn't follow from IDNA as IDNA leaves the transcoding issue open to the implementator. It seems as if either IDNA need to reference mapping tables that MUST be used for legacy encodings, or state that IDNA enables the attack. 2 So what if Alice talks to someone else? DNS can be spoofed anyway, so this isn't a new problem. My reply: Such problems in DNS can be solved with DNSSEC. However, even if DNSSEC is used, IDNA would enable this new attack => same conclusion as in 1. 3 Still, so what if Alice talks to someone else? Alice should use TLS or IPSEC or SSH or CMS or Kerberos or SASL or something else to authenticate the endpoints and protect data. My reply: This is where the subtle problems appears, and I think more investigations are needed here. A (probably flawed) initial attempt: 1 TLS and PKIX certs does not support IDNA, so we must first assume they are extended to support IDNA. The security implications might be different depending on how IDNA is implemented, so we must study each approach individually. Some approaches I can see: 1 Put IDNA strings in DN/subjectAltName of the PKIX cert. Alice compares IDNA in cert with the IDNA used to contact the host. While this appear to solve the problem, it really only moves the transcoding problem elsewhere. Perhaps the CA had to convert an ISO-8859-1 string it received in mail into the IDNA when generating the cert. Perhaps the machine used to apply for the certificate used ISO-8859-1 and had to convert it into an IDNA. Unless you assume the whole world switches to Unicode the day IDNA hits the street, the transcoding problem is present in at least one step in the chain, and has to be solved there. Point is, the mapping tables must be standardized or you open up for attacks. 2 Put IDNA strings in DN/subjectAltName of the PKIX cert. Alice compares decoded IDNA in cert with the name used to contact the host. Decoding from Unicode into legacy encodings is tricky. Alice must have mapping tables here as well. 3 Use UTF-8 strings in DN/subjectAltName of the PKIX cert. Alice compares ToASCII(name-in-cert) with IDNA used to contact host. This seems similar as 1, in that unless the whole world uses UTF-8, the mapping has to be done somewhere and must be well defined there to be secure. 4 Add {charset, string} elements indicating the character set used, and the string in DN/subjectAltName of the PKIX cert. If charset is the same as the charset that Alice uses, it will work fine. However, in all other cases, mapping tables are needed, but this time O(n^2) tables must exist. 2 SASL is just a framework, so it is each SASL mechanism that has to be studied. Several SASL mechanisms (HMAC-MD5, DIGEST-MD5, SRP) does not include names of the endpoints, so the identity of the other end is only implicitly known after a succesful authentication. Thus it only makes man-in-the-middle attacks or password cracking slightly easier, no real security impact. ... etc, the cases for Kerberos, IPSEC and SSH seems to only repeat the discussions above. I have not slept for a long time, so I'll spare you the discussion and me the typing. :-) Suggested modified security consideration below. It essentially says that unless everyone switches to UTF-8, IDNA will enable new attacks that has security implications. --- draft-ietf-idn-idna-08.txt.orig Mon May 27 18:18:58 2002 +++ draft-ietf-idn-idna-08.txt Mon May 27 20:08:44 2002 @@ -690,10 +690,24 @@ are introduced by the encoding process or the use of these encoded values, apart from those introduced by the ACE encoding itself. -Domain names are used by users to connect to Internet servers. The -security of the Internet would be compromised if a user entering a -single internationalized name could be connected to different servers -based on different interpretations of the internationalized domain name. +Domain names are used by users to identify and connect to Internet +servers. The security of the Internet is compromised if a user +entering a single internationalized name is connected to different +servers based on different interpretations of the internationalized +domain name. When all systems use ASCII or Unicode, different +interpretations are not allowed in this specification. + +When involved systems use non-ASCII and non-Unicode characters (such +as ISO-8859-1 and ISO-2022-JP, which are common on the Internet), +however, this specification leaves the transcoding problem up to the +application. Thus there can not be any assurance that two +applications will not implement different transcoding rules. When two +applications implement different transcoding rules, they will +(assuming both domains exists) contact different servers. Note that +the problem can not just easily be solved by using a security protocol +such as TLS to identify and authenticate to end points, unless these +protocols have already solved the problem which IDNA is trying to +solve. Because this document normatively refers to [NAMEPREP], it includes the security considerations from that document as well. From owner-idn@ops.ietf.org Mon May 27 15:08:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23859 for ; Mon, 27 May 2002 15:08:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CPff-0009jv-00 for idn-data@psg.com; Mon, 27 May 2002 11:56:43 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17CPff-0009jo-00 for idn@ops.ietf.org; Mon, 27 May 2002 11:56:43 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4RIufWa003058; Mon, 27 May 2002 20:56:41 +0200 To: "James Seng" Cc: "IETF/IDN WG" Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> <001701c20586$5eae4130$5b00a8c0@JAMESSONYVAIO> <005601c2059f$7e12b790$5b00a8c0@JAMESSONYVAIO> From: Simon Josefsson Date: Mon, 27 May 2002 20:56:41 +0200 In-Reply-To: <005601c2059f$7e12b790$5b00a8c0@JAMESSONYVAIO> ("James Seng"'s message of "Tue, 28 May 2002 00:56:48 +0800") Message-ID: Lines: 56 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk "James Seng" writes: >> I can't find offical mappings for, e.g., ISO-2022 (RFC 1468) online. >> >> > - IDNA already specify (or suggested) that if the apps is using legacy >> > encodings, it should transcode to Unicode first. >> >> Yes, but I cannot find where it says how to do it, or where it cites a >> reference that explains how to do it. That's why I think the security >> consideration should be more clear that the standard will enable >> trivial attacks that have security consequences if the document is >> implemented, because the details of legacy transcoding is left >> unspecified. > > No. ISO-2022 specify a mechanism for encoding reportairs using code > switching. The transcoding varies depending on the reportairs (up to 4) you > select. And it is not a 1-to-1 mapping with Unicode. > > Do you mean you want IDNA to specify transcoding algoirthm too? Then how > many do you want to support? And why only these set? What if some one > creates another encoding? > > IDNA already say we start from Unicode. How you do the trancoding from your > encoding to Unicode is up to you so long you have the right Unicode to start > with, ie, the original legacy encoding is irrelevant from IDN perspective. > > If you did not do your transcoding from legacy to Unicode, then there is a > security problem. But the beast you describe is not IDNA. IDNA specifically > say it operates from/to Unicode only. But the Internet is not Unicode only. I don't want to get into the design of IDNA, I only want the security consideration to accurately reflect reality, whatever it may be. My interpretation of reality is that IDNA has a limitation (that it does not define mapping tables for legacy encodings) that can be exploited on hosts that do not use ASCII/Unicode for user input/output. >> If there is no standard way to translate ISO-2022-JP into Unicode, >> won't different applications implement it differently? > > There are many ways to implement an algorithm. It does not matter how you do > it, so long the end results is the same. Yes! But since it isn't specified, different applications may generate different output, which in turn could be exploited. >> Many machines use legacy encodings, how IDNA ends up being implemented >> on such systems seems to be up to the implementor right now. > > Yes and yes. And Toolkits are available for implementors to transcode, MS > APIs, ICU, Java I18N API etc. Lets leave the implementation issues to the > implementors. Fine. From owner-idn@ops.ietf.org Mon May 27 15:08:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23881 for ; Mon, 27 May 2002 15:08:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CPe3-0009i0-00 for idn-data@psg.com; Mon, 27 May 2002 11:55:03 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17CPe2-0009hn-00 for idn@ops.ietf.org; Mon, 27 May 2002 11:55:02 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RIstJ24367; Mon, 27 May 2002 11:54:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <200205231129.HAA04661@ietf.org> Date: Mon, 27 May 2002 11:54:49 -0700 To: Simon Josefsson From: Paul Hoffman / IMC Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Thanks, those are very good points. A few notes on your proposed changes to the security considerations: At 8:20 PM +0200 5/27/02, Simon Josefsson wrote: >+Domain names are used by users to identify and connect to Internet >+servers. The security of the Internet is compromised if a user >+entering a single internationalized name is connected to different >+servers based on different interpretations of the internationalized >+domain name. That seems fine, and expands from what we had before to cover your larger concern. > When all systems use ASCII or Unicode, different >+interpretations are not allowed in this specification. I think that goes too far. A user system that "uses Unicode" could still make wrong judgements between the keyboard and the encoding. For example, on the Mac, typing Option-8 inserts a bullet character. There are many different bullet characters in the Unicode character repertoire, so entering a host name that includes one of those bullet symbols might get the wrong result. Thus, I'd rather not use that last sentence. >+When involved systems use non-ASCII and non-Unicode characters (such >+as ISO-8859-1 and ISO-2022-JP, which are common on the Internet), We're not concerned with what is common on the Internet, but what is common in systems. >+however, this specification leaves the transcoding problem up to the >+application. Thus there can not be any assurance that two >+applications will not implement different transcoding rules. When two >+applications implement different transcoding rules, they will >+(assuming both domains exists) contact different servers. Note that >+the problem can not just easily be solved by using a security protocol >+such as TLS to identify and authenticate to end points, unless these >+protocols have already solved the problem which IDNA is trying to >+solve. That seems like a good addition. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon May 27 15:09:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23896 for ; Mon, 27 May 2002 15:09:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CPnK-0009tn-00 for idn-data@psg.com; Mon, 27 May 2002 12:04:38 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17CPnJ-0009th-00 for idn@ops.ietf.org; Mon, 27 May 2002 12:04:37 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4RJ4XWa003119; Mon, 27 May 2002 21:04:34 +0200 To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> From: Simon Josefsson Date: Mon, 27 May 2002 21:03:27 +0200 In-Reply-To: (Paul Hoffman / IMC's message of "Mon, 27 May 2002 11:54:49 -0700") Message-ID: Lines: 24 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC writes: >> When all systems use ASCII or Unicode, different >>+interpretations are not allowed in this specification. > > I think that goes too far. A user system that "uses Unicode" could > still make wrong judgements between the keyboard and the encoding. For > example, on the Mac, typing Option-8 inserts a bullet character. There > are many different bullet characters in the Unicode character > repertoire, so entering a host name that includes one of those bullet > symbols might get the wrong result. Thus, I'd rather not use that last > sentence. Yes, I agree. >>+When involved systems use non-ASCII and non-Unicode characters (such >>+as ISO-8859-1 and ISO-2022-JP, which are common on the Internet), > > We're not concerned with what is common on the Internet, but what is > common in systems. Make it "common in systems on the Internet" then. I doubt you care about how I handle IDN's in my own disconnected system? Or just "common". From owner-idn@ops.ietf.org Mon May 27 15:43:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24139 for ; Mon, 27 May 2002 15:43:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CQJ8-000AcS-00 for idn-data@psg.com; Mon, 27 May 2002 12:37:30 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #1) id 17CQJ7-000AbC-00 for idn@ops.ietf.org; Mon, 27 May 2002 12:37:29 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 5DBE34070; Mon, 27 May 2002 21:37:52 +0200 (CEST) Date: Mon, 27 May 2002 21:37:52 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Paul Hoffman / IMC Cc: Simon Josefsson , idn@ops.ietf.org Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Message-ID: <20020527193752.GA25688@rap.rap.dk> References: <200205231129.HAA04661@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, May 27, 2002 at 11:54:49AM -0700, Paul Hoffman / IMC wrote: > Thanks, those are very good points. A few notes on your proposed > changes to the security considerations: > > > When all systems use ASCII or Unicode, different > >+interpretations are not allowed in this specification. > > I think that goes too far. A user system that "uses Unicode" could > still make wrong judgements between the keyboard and the encoding. > For example, on the Mac, typing Option-8 inserts a bullet character. > There are many different bullet characters in the Unicode character > repertoire, so entering a host name that includes one of those bullet > symbols might get the wrong result. Thus, I'd rather not use that > last sentence. Well, I dont think the bullets should be in the repertoire for IDN. > >+When involved systems use non-ASCII and non-Unicode characters (such > >+as ISO-8859-1 and ISO-2022-JP, which are common on the Internet), > > We're not concerned with what is common on the Internet, but what is > common in systems. And there we have a strong correlation, ISO-8859-1 and ISO-2022 are very common on systems. Kind regards keld From owner-idn@ops.ietf.org Mon May 27 17:05:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25023 for ; Mon, 27 May 2002 17:05:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CRVi-000C7V-00 for idn-data@psg.com; Mon, 27 May 2002 13:54:34 -0700 Received: from nod.reston.mci.net ([166.60.6.38]) by psg.com with esmtp (Exim 3.36 #1) id 17CRVi-000C7M-00 for idn@ops.ietf.org; Mon, 27 May 2002 13:54:34 -0700 Received: from vint.wcom.com ([209.190.228.45]) by shoe.reston.mci.net (PMDF V6.1-1 #39689) with ESMTPA id <01KI89VSB9GA934YFC@shoe.reston.mci.net> for idn@ops.ietf.org; Mon, 27 May 2002 16:54:32 -0500 (EST) Date: Mon, 27 May 2002 16:54:26 -0400 From: vint cerf Subject: Re: [idn] FTP history In-reply-to: <5.1.1.2.2.20020527094736.0346a678@jay.songbird.com> X-Sender: vcerf@shoe.reston.mci.net To: Dave Crocker , John C Klensin Cc: IETF idn working group Message-id: <5.0.2.1.2.20020527164916.0523a478@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <3611664.1022503430@localhost> <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Dave, isn't there a distinction to be made between the client and the server here? The results of the user interaction were exchanges over a TCP connection distinct from the control connection - that was so even before TCP/IP (with NCP). The fact that we used TELNET to drive the FTP control doesn't make the design any less a protocol. TELNET was a convenient way of implementing the text-based exchanges - but they had formats that included error numbers as well as text in the expectation that some implementations of the the client would be machine driven, I thought. The server side plainly had to deal with protocol exchanges between the ftp data transfer servers on source and sink machines, in addition to the control server exchanges carried over the TELNET protocol. I'm not sure whether this thread/debate is necessarily useful, is it?? vint At 09:58 AM 5/27/2002 -0700, Dave Crocker wrote: >At 12:43 PM 5/27/2002 -0400, John C Klensin wrote: >> While FTP apparently lends itself to "direct UI", it >>was never intended that way. > >John, > >I have a pretty clear recollection that when FTP first came out the folks who wrote the spec honestly expected to be able to sit at a TIP, telnet over to an FTP server, and type commands that would effect file transfers. > >I even have a vague recollection that this was used to send data to a printer attached to the TIP on another port. > > >>For example, use of "TYPE ASCII" transfers requires translation >>between the character set of the sender and network ASCII and >>translation by the receiver from network ASCII to local >>character set and formats. > >Not if the receiver can process network ASCII directly, as some did. > > >> Even when those hosts use ASCII, the >>translations must accomodate, e.g., conversion of end of line >>conventions. > >Not if they supported CRLF directly, as some did. In fact, that was why CRLF was chosen and end of line, rather than a single character. A single character would have made lexical analysis notably simpler. > > >>But the protocol is no more designed as a "direct UI" than SMTP > >SMTP came around 10 years later. > >However, the original MAIL command in FTP was explicitly intended to permit direct typing over a telnet connection. And it was in fact used that way. (That was why there was a distinction between MAIL and MLFL which did the data transfer over a separate FTP data connection.) > >d/ > >---------- >Dave Crocker >TribalWise, Inc. >tel +1.408.246.8253; fax +1.408.850.1850 > From owner-idn@ops.ietf.org Mon May 27 21:47:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27661 for ; Mon, 27 May 2002 21:47:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CVow-000IM3-00 for idn-data@psg.com; Mon, 27 May 2002 18:30:42 -0700 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]) by psg.com with esmtp (Exim 3.36 #1) id 17CVov-000ILv-00 for idn@ops.ietf.org; Mon, 27 May 2002 18:30:41 -0700 Received: from m4.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id KAA15803 for ; Tue, 28 May 2002 10:30:39 +0900 (JST) (envelope-from seki@jp.fujitsu.com) Received: from poi.sysrap.cs.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0205-Fujitsu Domain Master) id KAA23373 for ; Tue, 28 May 2002 10:30:38 +0900 (JST) (envelope-from seki@jp.fujitsu.com) Received: from roan (dhcp123.sysrap.cs.fujitsu.co.jp [10.35.109.123]) by poi.sysrap.cs.fujitsu.co.jp (Postfix) with SMTP id 0EED51EC3 for ; Tue, 28 May 2002 10:30:38 +0900 (JST) Message-ID: <006601c205e7$45443f40$7b6d230a@sysrap.cs.fujitsu.co.jp> From: "Masahiro Sekiguchi" To: References: <200205231129.HAA04661@ietf.org> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Tue, 28 May 2002 10:30:36 +0900 Organization: Fujitsu Limited MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > The basic attack: Alice runs on host that uses Latin-1 for > input/output and enters www.µbank.com (where µ is 8859-1 0xB5). The > domain is registered using U+00B5, but Alice's application transcode > the string using U+03BC. Either Alice can't connect (if the other > domain doesn't exist) or she ends up talking to someone else (if the > other domain does exist). I agree the case you described is a problem. However, I don't agree on the point you state is the cause, i.e., I don't think it is a transcoding problem. Please imagine that we are living in a ideal Unicode-only world. Assume the bank registers its domain name using Unicode U+00B5, intending "micro-bank." Alice *may* type a key for U+00B5 is she is a computer engineer, but she may type U+03BC in if she is a Greek linguist, because her keyboard (or input mapper) will be optimized for Greek typing, or because her thinking is biased by her Greek familiarity (She probably read the name as "mu bank", being puzzled what it means.) Someone might say this is a Unicode problem. Well, partly. For this particular case, Unicode could have eliminated one of U+00B5 and U+03BC. However, there are a lot of similar cases: l and 1, 0 and O, ´ and ', or ° and o, even in the 8859-1 range. We can't eliminate all of these similar lookings. Hence, I consider the basic problem is in our writing systems and I don't think it's feasible to fix them. > Suggested modified security consideration below. It essentially says > that unless everyone switches to UTF-8, IDNA will enable new attacks > that has security implications. Mentioning the security implications is good. Blaming it on transcoding is irrelevant. Revilutionalize the world to use UTF-8 only doesn't completely eliminate the problem, IMHO. > -Domain names are used by users to connect to Internet servers. The > -security of the Internet would be compromised if a user entering a > -single internationalized name could be connected to different servers > -based on different interpretations of the internationalized domain name. > +Domain names are used by users to identify and connect to Internet > +servers. The security of the Internet is compromised if a user > +entering a single internationalized name is connected to different > +servers based on different interpretations of the internationalized > +domain name. When all systems use ASCII or Unicode, different > +interpretations are not allowed in this specification. > + > +When involved systems use non-ASCII and non-Unicode characters (such > +as ISO-8859-1 and ISO-2022-JP, which are common on the Internet), > +however, this specification leaves the transcoding problem up to the > +application. Thus there can not be any assurance that two > +applications will not implement different transcoding rules. When two > +applications implement different transcoding rules, they will > +(assuming both domains exists) contact different servers. Note that > +the problem can not just easily be solved by using a security protocol > +such as TLS to identify and authenticate to end points, unless these > +protocols have already solved the problem which IDNA is trying to > +solve. Comparing these two wordings, I support the original one, although the best would be something in between. From owner-idn@ops.ietf.org Tue May 28 05:01:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11029 for ; Tue, 28 May 2002 05:01:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Cce0-000108-00 for idn-data@psg.com; Tue, 28 May 2002 01:47:52 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ccdz-000102-00 for idn@ops.ietf.org; Tue, 28 May 2002 01:47:51 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4S8lSWa008464; Tue, 28 May 2002 10:47:29 +0200 To: "Masahiro Sekiguchi" Cc: Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> <006601c205e7$45443f40$7b6d230a@sysrap.cs.fujitsu.co.jp> From: Simon Josefsson Date: Tue, 28 May 2002 10:47:29 +0200 In-Reply-To: <006601c205e7$45443f40$7b6d230a@sysrap.cs.fujitsu.co.jp> ("Masahiro Sekiguchi"'s message of "Tue, 28 May 2002 10:30:36 +0900") Message-ID: Lines: 89 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Masahiro Sekiguchi" writes: >> The basic attack: Alice runs on host that uses Latin-1 for >> input/output and enters www.µbank.com (where µ is 8859-1 0xB5). The >> domain is registered using U+00B5, but Alice's application transcode >> the string using U+03BC. Either Alice can't connect (if the other >> domain doesn't exist) or she ends up talking to someone else (if the >> other domain does exist). > > I agree the case you described is a problem. However, I don't > agree on the point you state is the cause, i.e., I don't think > it is a transcoding problem. > > Please imagine that we are living in a ideal Unicode-only world. > > Assume the bank registers its domain name using Unicode U+00B5, > intending "micro-bank." Alice *may* type a key for U+00B5 is > she is a computer engineer, but she may type U+03BC in if she is > a Greek linguist, because her keyboard (or input mapper) will be > optimized for Greek typing, or because her thinking is biased by > her Greek familiarity (She probably read the name as "mu bank", > being puzzled what it means.) > > Someone might say this is a Unicode problem. Well, partly. For > this particular case, Unicode could have eliminated one of > U+00B5 and U+03BC. However, there are a lot of similar cases: l > and 1, 0 and O, ´ and ', or ° and o, even in the 8859-1 range. > We can't eliminate all of these similar lookings. > > Hence, I consider the basic problem is in our writing systems > and I don't think it's feasible to fix them. I agree it isn't feasible to fix them, so that problem cannot be solved. That problem should probably be mentioned in the security considerations as well. The user gets what she enters, and if she enters something else than she expects to enter, there will be errors that can have security implications. The same problem exists today, if you enter "mybank.com" instead of "mubank.com" no technical aid can protect you from someone calling herself "mybank.com" setting up a similar looking web site as "mubank.com", including server certs etc. I think the transcoding issue is separate though. The security implications in the scenario above can be solved by having educated users. They must remember the exact spelling and exact characters used to contact their bank (this isn't unreasonable). However, when the system uses transcoding to convert system characters into Unicode characters, even a user entering the "correct" spelling cannot be certain that she ends up at the right server because transcoding algorithms are not specified by IDNA and is left to implementations. The user can even look at the string she entered, and the string found in a certificate and it is possible for them to match, octet-by-octet, with her "correct" string, and still she is talking to the wrong server because different mapping tables exists. When transcoding algorithms are left unspecified, the only way for the user to be able to verify the identity of the bank is to compare the computed IDNA strings with what she wanted. She enters the string using system characters, it is converted into IDNA, the server is contacted and a certificate is fetched. Now, to be certain of the identity, the application will likely compare the IDNA of the server with the one in the certificate, but the user need to compare the computed IDNA with something she knows, to be certain that the application didn't use a transcoding algorithm different from what the bank used, the CA used, and the user intended. If transcoding algorithms was specified by IDNA, the second security problem would be reduced into the first one (modulo any mistakes in transcoding mapping tables -- once the tables are fixed, you can't modify them unless you want to enable the attack again). Instead, it could be easier to just ignore the second security problem, assuming that all implementations will transcode system characters into Unicode characters in the same way. Or that the problem is rare in practice that it doesn't matter. Or that the whole world will switch to Unicode. Or that I misunderstood everything and there isn't a problem at all. Either way, all I'm asking is that the problem and the expected solution is discussed a bit further in the specification, so that I can understand how to implement IDNA securely on my Latin-1 machine. >> Suggested modified security consideration below. It essentially says >> that unless everyone switches to UTF-8, IDNA will enable new attacks >> that has security implications. > > Mentioning the security implications is good. Blaming it on > transcoding is irrelevant. Revilutionalize the world to use > UTF-8 only doesn't completely eliminate the problem, IMHO. As illustrated above, I believe there are two separate problems. It might be good to make both of them explicit. From owner-idn@ops.ietf.org Tue May 28 08:09:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14688 for ; Tue, 28 May 2002 08:09:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Cfft-0003nC-00 for idn-data@psg.com; Tue, 28 May 2002 05:02:01 -0700 Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu) by psg.com with esmtp (Exim 3.36 #1) id 17Cffq-0003n4-00 for idn@ops.ietf.org; Tue, 28 May 2002 05:01:59 -0700 Received: from bamdad.org (IDENT:root@[194.225.40.24]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g4SC1oE05455 for ; Tue, 28 May 2002 16:31:50 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id g4SCMnR16982 for ; Tue, 28 May 2002 16:52:49 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Tue, 28 May 2002 16:52:49 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: IDN Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt In-Reply-To: <006601c205e7$45443f40$7b6d230a@sysrap.cs.fujitsu.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT > The basic attack: Alice runs on host that uses Latin-1 for > input/output and enters www.µbank.com (where µ is 8859-1 0xB5). The > domain is registered using U+00B5, but Alice's application transcode > the string using U+03BC. Either Alice can't connect (if the other > domain doesn't exist) or she ends up talking to someone else (if the > other domain does exist). I'm sorry, but your example doesn't work. In nameprep, when doing Unicode Normalization, U+00B5 is mapped to U+03BC. So these will be the same domain name, and have the same ACE label. roozbeh From owner-idn@ops.ietf.org Tue May 28 09:34:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18096 for ; Tue, 28 May 2002 09:34:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CggK-0004xA-00 for idn-data@psg.com; Tue, 28 May 2002 06:06:32 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #1) id 17CggJ-0004x4-00 for idn@ops.ietf.org; Tue, 28 May 2002 06:06:31 -0700 Received: from classic.viagenie.qc.ca (modemcable071.132-130-66.que.mc.videotron.ca [66.130.132.71]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g4SD6c820643; Tue, 28 May 2002 09:06:38 -0400 (EDT) Date: Tue, 28 May 2002 09:05:18 -0400 From: Marc Blanchet To: vint cerf , Dave Crocker , John C Klensin cc: IETF idn working group Subject: Re: [idn] FTP history Message-ID: <337320000.1022591118@classic.viagenie.qc.ca> In-Reply-To: <5.0.2.1.2.20020527164916.0523a478@shoe.reston.mci.net> References: <3611664.1022503430@localhost> <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <5.0.2.1.2.20020527164916.0523a478@shoe.reston.mci.net> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA18096 -- lundi, mai 27, 2002 16:54:26 -0400 vint cerf wrote/a écrit: > Dave, > > isn't there a distinction to be made between the client and the server > here? The results of the user interaction were exchanges over a TCP > connection distinct from the control connection - that was so even before > TCP/IP (with NCP). The fact that we used TELNET to drive the FTP control > doesn't make the design any less a protocol. TELNET was a convenient way > of implementing the text-based exchanges - but they had formats that > included error numbers as well as text in the expectation that some > implementations of the the client would be machine driven, I thought. > > The server side plainly had to deal with protocol exchanges between the > ftp data transfer servers on source and sink machines, in addition to the > control server exchanges carried over the TELNET protocol. > > I'm not sure whether this thread/debate is necessarily useful, is it?? While I found this thread very informative of design considerations at that time, I agree with Vint about the not clear usefulness of this thread for this wg. The internet history mailing list might be more appropriate for this thread. Marc. > > vint > > At 09:58 AM 5/27/2002 -0700, Dave Crocker wrote: >> At 12:43 PM 5/27/2002 -0400, John C Klensin wrote: >>> While FTP apparently lends itself to "direct UI", it >>> was never intended that way. >> >> John, >> >> I have a pretty clear recollection that when FTP first came out the >> folks who wrote the spec honestly expected to be able to sit at a TIP, >> telnet over to an FTP server, and type commands that would effect file >> transfers. >> >> I even have a vague recollection that this was used to send data to a >> printer attached to the TIP on another port. >> >> >>> For example, use of "TYPE ASCII" transfers requires translation >>> between the character set of the sender and network ASCII and >>> translation by the receiver from network ASCII to local >>> character set and formats. >> >> Not if the receiver can process network ASCII directly, as some did. >> >> >>> Even when those hosts use ASCII, the >>> translations must accomodate, e.g., conversion of end of line >>> conventions. >> >> Not if they supported CRLF directly, as some did. In fact, that was why >> CRLF was chosen and end of line, rather than a single character. A >> single character would have made lexical analysis notably simpler. >> >> >>> But the protocol is no more designed as a "direct UI" than SMTP >> >> SMTP came around 10 years later. >> >> However, the original MAIL command in FTP was explicitly intended to >> permit direct typing over a telnet connection. And it was in fact used >> that way. (That was why there was a distinction between MAIL and MLFL >> which did the data transfer over a separate FTP data connection.) >> >> d/ >> >> ---------- >> Dave Crocker >> TribalWise, Inc. >> tel +1.408.246.8253; fax +1.408.850.1850 >> > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-idn@ops.ietf.org Tue May 28 10:19:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19825 for ; Tue, 28 May 2002 10:19:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Chb1-00068L-00 for idn-data@psg.com; Tue, 28 May 2002 07:05:07 -0700 Received: from sccrmhc03.attbi.com ([204.127.202.63]) by psg.com with esmtp (Exim 3.36 #1) id 17Chb0-00068D-00 for idn@ops.ietf.org; Tue, 28 May 2002 07:05:06 -0700 Received: from c1340594a ([12.234.224.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020528140505.EIY20219.sccrmhc03.attbi.com@c1340594a>; Tue, 28 May 2002 14:05:05 +0000 Message-ID: <0b3801c20650$cf8119d0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Roozbeh Pournader" , "IDN" References: Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Tue, 28 May 2002 07:06:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I agree with Roozbeh; in the particular case cited, there is not a problem. There is a very significant problem with transcoding, because different vendors mean different things by a tag like "SJIS". The IANA registry, unfortunately, does not specify the mapping corresponding to this tag in sufficient detail for precise conversions. See, for example, http://www.w3.org/TR/japanese-xml/ for an extended discussion. However, precise tags have been proposed to IANA to resolve these problems (in Appendix D of this document) by providing precise mappings, at least for Japanese. http://oss.software.ibm.com/icu/charset/index.html lists some of the variation among different character mapping tables for other code sets. However, all this being said and done, the variations are usually a very small percent of the total, and usually restricted to a few punctuation or symbols. And to the best of my knowledge, people do not vary in how they interpret the ISO 8859 series. Thus while the document wants to point to the problem, it would be misleading to give people the impression that a large number of characters will cause security problems, when it is really restricted to a very small number of cases. What would be productive and useful would be to identify and list those characters that could have problems in practice. Mark __________ http://www.macchiato.com “Eppur si muove†----- Original Message ----- From: "Roozbeh Pournader" To: "IDN" Sent: Tuesday, May 28, 2002 05:22 Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt > > > The basic attack: Alice runs on host that uses Latin-1 for > > input/output and enters www.µbank.com (where µ is 8859-1 0xB5). The > > domain is registered using U+00B5, but Alice's application transcode > > the string using U+03BC. Either Alice can't connect (if the other > > domain doesn't exist) or she ends up talking to someone else (if the > > other domain does exist). > > I'm sorry, but your example doesn't work. In nameprep, when doing Unicode > Normalization, U+00B5 is mapped to U+03BC. So these will be the same > domain name, and have the same ACE label. > > roozbeh > > > From owner-idn@ops.ietf.org Tue May 28 10:51:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20693 for ; Tue, 28 May 2002 10:51:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ci69-0006kO-00 for idn-data@psg.com; Tue, 28 May 2002 07:37:17 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ci68-0006kI-00 for idn@ops.ietf.org; Tue, 28 May 2002 07:37:16 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4SEbCWa011157; Tue, 28 May 2002 16:37:13 +0200 To: Roozbeh Pournader Cc: IDN Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: From: Simon Josefsson Date: Tue, 28 May 2002 16:37:13 +0200 In-Reply-To: (Roozbeh Pournader's message of "Tue, 28 May 2002 16:52:49 +0430 (IRST)") Message-ID: Lines: 37 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Roozbeh Pournader writes: >> The basic attack: Alice runs on host that uses Latin-1 for >> input/output and enters www.µbank.com (where µ is 8859-1 0xB5). The >> domain is registered using U+00B5, but Alice's application transcode >> the string using U+03BC. Either Alice can't connect (if the other >> domain doesn't exist) or she ends up talking to someone else (if the >> other domain does exist). > > I'm sorry, but your example doesn't work. In nameprep, when doing Unicode > Normalization, U+00B5 is mapped to U+03BC. So these will be the same > domain name, and have the same ACE label. You are right. What about other examples? ISO-8859-1 0xB5: U+00B5 / U+03BC: Mapped to U+03BC as you indicate ISO-8859-1 0xC5: U+00C5 / U+212B: Mapped to U+00C5 CP437 0xE1: U+03B2 / U+00DF: ? CP437 0xEA: U+03A9 / U+2126: Mapped to U+03A9 CP437 0xEE: U+03B5 / U+2208: ? JIS-X-0208 0x2140: U+005C / U+FF3C: ? "?" means I could not find any KC normalization in the Unicode tables at http://www.unicode.org/charts/normalization/, I'm not sure how to interprete this. Possibly it means they are not normalized, in which case there is a problem? I agree with Mark Davis that it would be interesting to find out which and how many characters in commonly used legacy charsets that may cause these problems. Also note that, if these tables are ever changed in the future, this could also be exploited. Application A uses mapping table version Y and application B uses mapping table version Y+1 which transcode and/or normalizes characters differently. In this case someone could register either old or new domain and fool either new or old applications. From owner-idn@ops.ietf.org Tue May 28 11:07:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21205 for ; Tue, 28 May 2002 11:07:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CiT7-0007FY-00 for idn-data@psg.com; Tue, 28 May 2002 08:01:01 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CiT6-0007FS-00 for idn@ops.ietf.org; Tue, 28 May 2002 08:01:01 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4SF06A29354; Wed, 29 May 2002 00:00:11 +0900 Message-ID: <01c501c20658$5d5addc0$2b19fea9@temp> From: "Soobok Lee" To: "Mark Davis" , "Roozbeh Pournader" , "IDN" References: <0b3801c20650$cf8119d0$8900a8c0@c1340594a> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Tue, 28 May 2002 23:59:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit How do you think about the variations between KSC5601-1987 and KSC5601-1992 ? The latter one has thousands of new hangul syllable characters (johab), but often has been tagged as shorter "KSC5601" or interchangably as "EUC-KR". Obviously, This loose versioning convention,which is found everywhere from Outlook , MSIE , Hotmail, and Netscape Navigator, would cause unnoticeable failures and security problems. For example, if the sender encloses hangul IRI including such hangul legacy-encoded IDN in his outgoing email message, the recipient with old s/w may be unable to convert it into Unicode. What if that happens between machine client and servers? Soobok Lee ----- Original Message ----- From: "Mark Davis" > > However, all this being said and done, the variations are usually a > very small percent of the total, and usually restricted to a few > punctuation or symbols. And to the best of my knowledge, people do not > vary in how they interpret the ISO 8859 series. Thus while the > document wants to point to the problem, it would be misleading to give > people the impression that a large number of characters will cause > security problems, when it is really restricted to a very small number > of cases. > > What would be productive and useful would be to identify and list > those characters that could have problems in practice. > > Mark > __________ > > http://www.macchiato.com > > “Eppur si muove†> ----- Original Message ----- > From: "Roozbeh Pournader" > To: "IDN" > Sent: Tuesday, May 28, 2002 05:22 > Subject: Re: [idn] Re: Legacy charset conversion in > draft-ietf-idn-idna-08.txt > > > > > > > The basic attack: Alice runs on host that uses Latin-1 for > > > input/output and enters www.µbank.com (where µ is 8859-1 0xB5). > The > > > domain is registered using U+00B5, but Alice's application > transcode > > > the string using U+03BC. Either Alice can't connect (if the other > > > domain doesn't exist) or she ends up talking to someone else (if > the > > > other domain does exist). > > > > I'm sorry, but your example doesn't work. In nameprep, when doing > Unicode > > Normalization, U+00B5 is mapped to U+03BC. So these will be the same > > domain name, and have the same ACE label. > > > > roozbeh > > > > > > > From owner-idn@ops.ietf.org Tue May 28 11:11:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21350 for ; Tue, 28 May 2002 11:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CiVZ-0007Id-00 for idn-data@psg.com; Tue, 28 May 2002 08:03:33 -0700 Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu) by psg.com with esmtp (Exim 3.36 #1) id 17CiVW-0007IU-00 for idn@ops.ietf.org; Tue, 28 May 2002 08:03:31 -0700 Received: from bamdad.org (IDENT:root@bamdad.org [213.29.27.7] (may be forged)) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g4SF3PE31729; Tue, 28 May 2002 19:33:25 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id g4SFOQ019333; Tue, 28 May 2002 19:54:26 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Tue, 28 May 2002 19:54:26 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: Simon Josefsson cc: IDN Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, 28 May 2002, Simon Josefsson wrote: > You are right. What about other examples? > > ISO-8859-1 0xB5: U+00B5 / U+03BC: Mapped to U+03BC as you indicate > ISO-8859-1 0xC5: U+00C5 / U+212B: Mapped to U+00C5 > CP437 0xEA: U+03A9 / U+2126: Mapped to U+03A9 These three won't cause any problem as you noted. > JIS-X-0208 0x2140: U+005C / U+FF3C: ? FF3C is compatibilitily mapped to 005C. So everything is fine. > CP437 0xE1: U+03B2 / U+00DF: ? > CP437 0xEE: U+03B5 / U+2208: ? As far as I know, all existing CP437 tables map those to SMALL SHARP S (U+00DF) and SMALL EPSILON (U+03B5) and not SMALL BETA or ELEMENT OF. I just checked everywhere I could, this is the list: http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT http://microsoft.com/globaldev/reference/oem/437.htm http://www.kostis.net/charsets/cp437.htm Can you point me to anywhere disagreeing? So you are suggesting that if one wants to use CP437 as the underlying encoding, conform to IDNA RFCs, and then dives into Unicode charts for finding the characters of CP437 instead of using tables he can find on the net, he is in a real mess. I agree! The only thing we are disagreeing on is the real source of the mess. :-) roozbeh From owner-idn@ops.ietf.org Tue May 28 11:34:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22073 for ; Tue, 28 May 2002 11:34:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Cipz-0007sx-00 for idn-data@psg.com; Tue, 28 May 2002 08:24:39 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17Cipy-0007si-00 for idn@ops.ietf.org; Tue, 28 May 2002 08:24:38 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4SFNqA29614; Wed, 29 May 2002 00:23:52 +0900 Message-ID: <01ee01c2065b$ac70a810$2b19fea9@temp> From: "Soobok Lee" To: "Soobok Lee" , "Mark Davis" , "Roozbeh Pournader" , "IDN" References: <0b3801c20650$cf8119d0$8900a8c0@c1340594a> <01c501c20658$5d5addc0$2b19fea9@temp> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 00:23:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit One concrete example: There is one hangul syllable char which is found only in KSC5601-1992. "똯" 0x8C70 U+B62F #HANGUL SYLLABLE SSANGTIKEUT WA KIYEOKSIOS I typed in this char "똯" in this mesage from my Outlook Express 6.0. If you look into the mime header of this message, you can find the errornous mime-charset name : "KS_C_5601-1987". Stupid and Wrong Versioning! Legacy encodings and its versioning conventions were not designed to be used in rigorous identifier contexts, rather to be used in textual applications like wordprocessors or html pages. but IRI (IDN) is about to use the legacy encodings in its own extended way regardless of this caveat. Soobok Lee ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" ; "Roozbeh Pournader" ; "IDN" Sent: Tuesday, May 28, 2002 11:59 PM Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt > How do you think about the variations between KSC5601-1987 and KSC5601-1992 ? > The latter one has thousands of new hangul syllable characters (johab), but often > has been tagged as shorter "KSC5601" or interchangably as "EUC-KR". Obviously, > This loose versioning convention,which is found everywhere from Outlook , MSIE , Hotmail, and Netscape > Navigator, would cause unnoticeable failures and security problems. > For example, if the sender encloses hangul IRI including such hangul legacy-encoded IDN in his outgoing email message, > the recipient with old s/w may be unable to convert it into Unicode. > What if that happens between machine client and servers? > > Soobok Lee > > ----- Original Message ----- > From: "Mark Davis" > > > > However, all this being said and done, the variations are usually a > > very small percent of the total, and usually restricted to a few > > punctuation or symbols. And to the best of my knowledge, people do not > > vary in how they interpret the ISO 8859 series. Thus while the > > document wants to point to the problem, it would be misleading to give > > people the impression that a large number of characters will cause > > security problems, when it is really restricted to a very small number > > of cases. > > > > What would be productive and useful would be to identify and list > > those characters that could have problems in practice. > > > > Mark > > __________ > > > > http://www.macchiato.com > > > > “Eppur si muove†> > ----- Original Message ----- > > From: "Roozbeh Pournader" > > To: "IDN" > > Sent: Tuesday, May 28, 2002 05:22 > > Subject: Re: [idn] Re: Legacy charset conversion in > > draft-ietf-idn-idna-08.txt > > > > > > > > > > > The basic attack: Alice runs on host that uses Latin-1 for > > > > input/output and enters www.µbank.com (where µ is 8859-1 0xB5). > > The > > > > domain is registered using U+00B5, but Alice's application > > transcode > > > > the string using U+03BC. Either Alice can't connect (if the other > > > > domain doesn't exist) or she ends up talking to someone else (if > > the > > > > other domain does exist). > > > > > > I'm sorry, but your example doesn't work. In nameprep, when doing > > Unicode > > > Normalization, U+00B5 is mapped to U+03BC. So these will be the same > > > domain name, and have the same ACE label. > > > > > > roozbeh > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 11:37:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22240 for ; Tue, 28 May 2002 11:37:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CitU-0007yw-00 for idn-data@psg.com; Tue, 28 May 2002 08:28:16 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CitT-0007yq-00 for idn@ops.ietf.org; Tue, 28 May 2002 08:28:16 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4SFRGA29656; Wed, 29 May 2002 00:27:16 +0900 Message-ID: <020901c2065c$29db21e0$2b19fea9@temp> From: "Soobok Lee" To: "Soobok Lee" , "Mark Davis" , "Roozbeh Pournader" , "IDN" References: <0b3801c20650$cf8119d0$8900a8c0@c1340594a> <01c501c20658$5d5addc0$2b19fea9@temp> Subject: (ksc5601)Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Date: Wed, 29 May 2002 00:27:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit One concrete example: There is one hangul syllable char which is found only in KSC5601-1992. "Œp" 0x8C70 U+B62F #HANGUL SYLLABLE SSANGTIKEUT WA KIYEOKSIOS I typed in this char "Œp" in this mesage from my Outlook Express 6.0. If you look into the mime header of this message, you can find the errornous mime-charset name : "KS_C_5601-1987". Stupid and Wrong Versioning! Legacy encodings and its versioning conventions were not designed to be used in rigorous identifier contexts, rather to be used in textual applications like wordprocessors or html pages. but IRI (IDN) is about to use the legacy encodings in its own extended way regardless of this caveat. Soobok Lee ----- Original Message ----- From: "Soobok Lee" To: "Mark Davis" ; "Roozbeh Pournader" ; "IDN" Sent: Tuesday, May 28, 2002 11:59 PM Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt > How do you think about the variations between KSC5601-1987 and KSC5601-1992 ? > The latter one has thousands of new hangul syllable characters (johab), but often > has been tagged as shorter "KSC5601" or interchangably as "EUC-KR". Obviously, > This loose versioning convention,which is found everywhere from Outlook , MSIE , Hotmail, and Netscape > Navigator, would cause unnoticeable failures and security problems. > For example, if the sender encloses hangul IRI including such hangul legacy-encoded IDN in his outgoing email message, > the recipient with old s/w may be unable to convert it into Unicode. > What if that happens between machine client and servers? > > Soobok Lee > > ----- Original Message ----- > From: "Mark Davis" > > > > However, all this being said and done, the variations are usually a > > very small percent of the total, and usually restricted to a few > > punctuation or symbols. And to the best of my knowledge, people do not > > vary in how they interpret the ISO 8859 series. Thus while the > > document wants to point to the problem, it would be misleading to give > > people the impression that a large number of characters will cause > > security problems, when it is really restricted to a very small number > > of cases. > > > > What would be productive and useful would be to identify and list > > those characters that could have problems in practice. > > > > Mark > > __________ > > > > http://www.macchiato.com > > > > ¡°Eppur si muove¡± > > ----- Original Message ----- > > From: "Roozbeh Pournader" > > To: "IDN" > > Sent: Tuesday, May 28, 2002 05:22 > > Subject: Re: [idn] Re: Legacy charset conversion in > > draft-ietf-idn-idna-08.txt > > > > > > > > > > > The basic attack: Alice runs on host that uses Latin-1 for > > > > input/output and enters www.¥ìbank.com (where ¥ì is 8859-1 0xB5). > > The > > > > domain is registered using U+00B5, but Alice's application > > transcode > > > > the string using U+03BC. Either Alice can't connect (if the other > > > > domain doesn't exist) or she ends up talking to someone else (if > > the > > > > other domain does exist). > > > > > > I'm sorry, but your example doesn't work. In nameprep, when doing > > Unicode > > > Normalization, U+00B5 is mapped to U+03BC. So these will be the same > > > domain name, and have the same ACE label. > > > > > > roozbeh > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 11:40:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22348 for ; Tue, 28 May 2002 11:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CixA-00086O-00 for idn-data@psg.com; Tue, 28 May 2002 08:32:04 -0700 Received: from sccrmhc02.attbi.com ([204.127.202.62]) by psg.com with esmtp (Exim 3.36 #1) id 17Cix9-00085d-00 for idn@ops.ietf.org; Tue, 28 May 2002 08:32:03 -0700 Received: from c1340594a ([12.234.224.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020528153200.ZBWX11183.sccrmhc02.attbi.com@c1340594a> for ; Tue, 28 May 2002 15:32:00 +0000 Message-ID: <0b5101c2065c$f3f82900$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: Subject: Fw: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Tue, 28 May 2002 08:33:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Wherever there is mislabeling of character sets, that can cause problems, of course. If ms1252 text is mislabeled as iso8859-1 text, for example, then all sorts of problems can ensue. Even worse, of course, is if SJIS text is mislabeled as 8859-1! In many circumstances of domain name conversion, I think these problems will be less likely. Take a browser, for example. In the URL field, someone will be typing in a given URL, in whatever code page the browser supports. The synchronization between the code page and the input keyboard will be pretty close, and will be unlikely that there will be a mismatch unless the OS is completely clueless. (Also, this will be much less of a problem in the very near future, as most client machines will be native Unicode [UTF-8, UTF-16, or UTF-32] anyway.) Also, if transcoding produces an unassigned character, or detects an illegal sequence, then it would fail. I don't say that problems can't happen, but it would be useful to examine some detailed scenarii to see whether, where, and how any problems would realistically arise. Mark __________ http://www.macchiato.com “Eppur si muove†----- Original Message ----- From: "Soobok Lee" To: "Soobok Lee" ; "Mark Davis" ; "Roozbeh Pournader" ; "IDN" Sent: Tuesday, May 28, 2002 08:23 Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > One concrete example: There is one hangul syllable char which is found only in KSC5601-1992. > > "똯" 0x8C70 U+B62F #HANGUL SYLLABLE SSANGTIKEUT WA KIYEOKSIOS > > I typed in this char "똯" in this mesage from my Outlook Express 6.0. > If you look into the mime header of this message, > you can find the errornous mime-charset name : "KS_C_5601-1987". Stupid and Wrong Versioning! > > Legacy encodings and its versioning conventions were not designed to be used in rigorous identifier contexts, > rather to be used in textual applications like wordprocessors or html pages. > but IRI (IDN) is about to use the legacy encodings in its own extended way regardless of this caveat. > > Soobok Lee > > ----- Original Message ----- > From: "Soobok Lee" > To: "Mark Davis" ; "Roozbeh Pournader" ; "IDN" > Sent: Tuesday, May 28, 2002 11:59 PM > Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt > > > > How do you think about the variations between KSC5601-1987 and KSC5601-1992 ? > > The latter one has thousands of new hangul syllable characters (johab), but often > > has been tagged as shorter "KSC5601" or interchangably as "EUC-KR". Obviously, > > This loose versioning convention,which is found everywhere from Outlook , MSIE , Hotmail, and Netscape > > Navigator, would cause unnoticeable failures and security problems. > > For example, if the sender encloses hangul IRI including such hangul legacy-encoded IDN in his outgoing email message, > > the recipient with old s/w may be unable to convert it into Unicode. > > What if that happens between machine client and servers? > > > > Soobok Lee > > > > ----- Original Message ----- > > From: "Mark Davis" > > > > > > However, all this being said and done, the variations are usually a > > > very small percent of the total, and usually restricted to a few > > > punctuation or symbols. And to the best of my knowledge, people do not > > > vary in how they interpret the ISO 8859 series. Thus while the > > > document wants to point to the problem, it would be misleading to give > > > people the impression that a large number of characters will cause > > > security problems, when it is really restricted to a very small number > > > of cases. > > > > > > What would be productive and useful would be to identify and list > > > those characters that could have problems in practice. > > > > > > Mark > > > __________ > > > > > > http://www.macchiato.com > > > > > > “Eppur si muove†> > > ----- Original Message ----- > > > From: "Roozbeh Pournader" > > > To: "IDN" > > > Sent: Tuesday, May 28, 2002 05:22 > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > draft-ietf-idn-idna-08.txt > > > > > > > > > > > > > > > The basic attack: Alice runs on host that uses Latin-1 for > > > > > input/output and enters www.µbank.com (where µ is 8859-1 0xB5). > > > The > > > > > domain is registered using U+00B5, but Alice's application > > > transcode > > > > > the string using U+03BC. Either Alice can't connect (if the other > > > > > domain doesn't exist) or she ends up talking to someone else (if > > > the > > > > > other domain does exist). > > > > > > > > I'm sorry, but your example doesn't work. In nameprep, when doing > > > Unicode > > > > Normalization, U+00B5 is mapped to U+03BC. So these will be the same > > > > domain name, and have the same ACE label. > > > > > > > > roozbeh > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 12:01:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23088 for ; Tue, 28 May 2002 12:01:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CjE9-0008bd-00 for idn-data@psg.com; Tue, 28 May 2002 08:49:37 -0700 Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu) by psg.com with esmtp (Exim 3.36 #1) id 17CjE7-0008aV-00 for idn@ops.ietf.org; Tue, 28 May 2002 08:49:36 -0700 Received: from bamdad.org (IDENT:root@[194.225.40.24]) by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g4SFnTE06015; Tue, 28 May 2002 20:19:29 +0430 Received: from localhost (roozbeh@localhost) by bamdad.org (8.11.6/8.11.6) with ESMTP id g4SGAVF19854; Tue, 28 May 2002 20:40:31 +0430 X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs Date: Tue, 28 May 2002 20:40:30 +0430 (IRST) From: Roozbeh Pournader X-X-Sender: roozbeh@gilas.bamdad.org To: Soobok Lee cc: Mark Davis , IDN Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) In-Reply-To: <01ee01c2065b$ac70a810$2b19fea9@temp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, 29 May 2002, Soobok Lee wrote: > you can find the errornous mime-charset name : "KS_C_5601-1987". > Stupid and Wrong Versioning! Sure. But no protocol can fix broken software. Nag to developers of the software to fix it. In this case, it is passing a character onto wire, which is not in the character set it is claiming it to be in. If a piece of software wants to work with KSC 5601:1992, and use the character you used, should know its mapping to Unicode. Simple. roozbeh From owner-idn@ops.ietf.org Tue May 28 12:19:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23730 for ; Tue, 28 May 2002 12:19:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CjYY-0009B0-00 for idn-data@psg.com; Tue, 28 May 2002 09:10:42 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17CjYX-0009At-00 for idn@ops.ietf.org; Tue, 28 May 2002 09:10:41 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 93979 for idn@ops.ietf.org; Tue, 28 May 2002 11:10:46 -0500 Message-ID: <3CF3ABFD.C5AD5368@ehsco.com> Date: Tue, 28 May 2002 11:10:37 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 CC: IETF idn working group Subject: [idn] conversion collisions References: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <3611664.1022503430@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [bringing this back on topic] John C Klensin wrote: > Of course, Whois or Finger might be better examples of your > point, but those protocols did not specify the details of either > the input or output formats. That illustrates the problem exactly. The default behavior as specified in IDNA is to perform conversion, even though these standardized protocols do not require conversion, since they implicitly allow any charset. Ergo, any conversion which is to be performed with those protocols must be specified as part of an update to those protocols. Another issue from another thread is X.509 certificates. The certificate subjects must continue to use LDH domain names in order to interoperate with legacy applications of legacy services. New protocols may choose to specify the use of certificate subjects with Unicode characters, but legacy services must use IDNA sequences in order for them to continue functioning with legacy apps. However, if an IDNA mailer passes a converted i18n HTTPS URL to a web browser, then the comparison operation will fail. In these cases (as well as with things like Message-ID) there will be basic interoperability problems unless the governing specifications clearly define specific behaviors. The only reasonable position for us is to prohibit auto-conversion except where these decisions have been made. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue May 28 12:24:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23895 for ; Tue, 28 May 2002 12:24:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CjcZ-0009JI-00 for idn-data@psg.com; Tue, 28 May 2002 09:14:51 -0700 Received: from postel2.postel.co.kr ([211.218.145.193]) by psg.com with esmtp (Exim 3.36 #1) id 17CjcY-0009JB-00 for idn@ops.ietf.org; Tue, 28 May 2002 09:14:50 -0700 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g4SGEi813658 for idn@ops.ietf.org; Wed, 29 May 2002 01:14:44 +0900 To: idn@ops.ietf.org Received: Postel SMTP v1.0 Received: from MASTER ([203.229.224.207]) by postel2 (8.11.0/8.11.0) with SMTP id g4SGEg913655 for ; Wed, 29 May 2002 01:14:42 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: base64 X-Msmail-Priority: Normal Message-Id: <021f01c20662$c08616d0$2b19fea9@temp> Subject: [idn] BIG5< -> Unicode roundtrip compatibility From: "Soobok Lee" X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Wed, 29 May 2002 01:14:31 +0900 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjEwcHQnPgpJ IGVuY2xvc2UgYW4gZXhjZXJwdCBmcm9tCmh0dHAmIzU4Oy8vd3d3LnVuaWNv ZGUub3JnL1B1YmxpYy9NQVBQSU5HUy9PQlNPTEVURS9FQVNUQVNJQS9PVEhF Ui9CSUc1LlRYVC4KCkl0IHNheXMgdGhhdCBzb21lIFRDIGNoYXIgWCBjYW5u b3QgYmUgY29udmVydGVkIGludG8gVUNTIGNoYXJzIHdpdGhvdXQgbG9zaW5n CnJvdW5kdHJpcCBjb21wYXRpYmlsaXR5LiBpZSwgSW4gYSByb3VuZHRyaXAg Y29udmVyc2lvbiAgIFggLS0+IFVDUyhYKSAtLT4gWCcsICAKSXQgbWF5IGFy aXNlIHRoYXQgWCAhPSBYJy4KCkFueSBsZWdhY3ktZW5jb2RlZCBJUkkoSURO KXMgaW5jbHVkaW5nIFgsIG1heSBmYWlsIHRvIGJlIGNvbXBhcmVkCnN1Y2Nl c3NmdWxseSBpZiB0aGV5IGhhZCB1bmRlcmdvbmUgY29udmVyc2lvbnMgaW50 by9mcm9tIHVuaWNvZGUuCgpJIHdpbGwgYXBwcmVhY2lhdGUgaWYgYW55b25l IHByZXNlbnQgdGhlIGhpc3Rvcnkgb2YgQklHNSB2ZXJzaW9ucyBhbmQgaXRz IApyb3VuZC10cmlwIGNvbXBhdGlsaWJpdHkgcHJvYmxlbXMgaW4gbW9yZSBk ZXRhaWwuCgpTb29ib2sgTGVlCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCgoKIwlOYW1lJiM1ODsgICAgICAgICAgICAgQklHNSB0byBV bmljb2RlIHRhYmxlIChjb21wbGV0ZSkKIwlVbmljb2RlIHZlcnNpb24mIzU4 OyAgMS4xCiMJVGFibGUgdmVyc2lvbiYjNTg7ICAgIDAuMGQzCiMJVGFibGUg Zm9ybWF0JiM1ODsgICAgIEZvcm1hdCBBCiMJRGF0ZSYjNTg7ICAgICAgICAg ICAgIDExIEZlYnJ1YXJ5IDE5OTQKIwojCUNvcHlyaWdodCAoYykgMTk5MS0x OTk0IFVuaWNvZGUsIEluYy4gIEFsbCBSaWdodHMgcmVzZXJ2ZWQuCgooc25p cCkKIAojIElmIHlvdSBoYXZlIGNhcmVmdWxseSBjb25zaWRlcmVkIHRoZSBm YWN0IHRoYXQgdGhlIG1hcHBpbmdzIGluCiMgdGhpcyB0YWJsZSBhcmUgb25s eSBvbmUgcG9zc2libGUgc2V0IG9mIG1hcHBpbmdzIGJldHdlZW4gQklHNSBh bmQKIyBVbmljb2RlIGFuZCBoYXZlIG5vIG5vcm1hdGl2ZSBzdGF0dXMsIGJ1 dCBzdGlsbCBmZWVsIHRoYXQgeW91CiMgaGF2ZSBsb2NhdGVkIGFuIGVycm9y IGluIHRoZSB0YWJsZSB0aGF0IHJlcXVpcmVzIGZpeGluZywgeW91IG1heQoj IHJlcG9ydCBhbnkgc3VjaCBlcnJvciB0byBlcnJhdGFAdW5pY29kZS5vcmcu CiMKIwlXQVJOSU5HISAgSXQgaXMgY3VycmVudGx5IGltcG9zc2libGUgdG8g cHJvdmlkZSByb3VuZC10cmlwIGNvbXBhdGliaWxpdHkKIwkJYmV0d2VlbiBC SUc1IGFuZCBVbmljb2RlLiAgCiMKIwlBIG51bWJlciBvZiBjaGFyYWN0ZXJz IGFyZSBub3QgY3VycmVudGx5IG1hcHBlZCBiZWNhdXNlCiMJCW9mIGNvbmZs aWN0cyB3aXRoIG90aGVyIG1hcHBpbmdzLiAgVGhleSBhcmUgYXMgZm9sbG93 cyYjNTg7CiMKIyAgICAgICBCSUc1ICAgICAgICBEZXNjcmlwdGlvbiAgICAg ICAgICAgICAgICAgICAgQ29tbWVudHMKIwojICAgICAgIDB4QTE1QSAgICAg IFNQQUNJTkcgVU5ERVJTQ09SRSAgICAgICAgICAgICBkdXBsaWNhdGVzIEEx QzQKIyAgICAgICAweEExQzMgICAgICBTUEFDSU5HIEhFQVZZIE9WRVJTQ09S RSAgICAgICAgbm90IGluIFVuaWNvZGUKIyAgICAgICAweEExQzUgICAgICBT UEFDSU5HIEhFQVZZIFVOREVSU0NPUkUgICAgICAgbm90IGluIFVuaWNvZGUK IyAgICAgICAweEExRkUgICAgICBMVCBESUFHIFVQIFJJR0hUIFRPIExPVyBM RUZUICAgZHVwbGljYXRlcyBBMkFDCiMgICAgICAgMHhBMjQwICAgICAgTFQg RElBRyBVUCBMRUZUIFRPIExPVyBSSUdIVCAgIGR1cGxpY2F0ZXMgQTJBRAoj ICAgICAgIDB4QTJDQyAgICAgIEhBTkdaSE9VIE5VTUVSQUwgVEVOICAgICAg ICAgICBjb25mbGljdHMgd2l0aCBBNDUxIG1hcHBpbmcKIyAgICAgICAweEEy Q0UgICAgICBIQU5HWkhPVSBOVU1FUkFMIFRISVJUWSAgICAgICAgY29uZmxp Y3RzIHdpdGggQTRDQSBtYXBwaW5nCiMKIwlXZSBjdXJyZW50bHkgbWFwIGFs bCBvZiB0aGVzZSBjaGFyYWN0ZXJzIHRvIFUrRkZGRCBSRVBMQUNFTUVOVCBD SEFSQUNURVIuCiMJCUl0IGlzIGFsc28gcG9zc2libGUgdG8gbWFwIHRoZXNl IGNoYXJhY3RlcnMgdG8gdGhlaXIgZHVwbGljYXRlcywgb3IgdG8KIwkJdGhl IHVzZXIgem9uZS4gIAojCQojCU5vdGVzJiM1ODsKIwojCTEuIEluIGFkZGl0 aW9uIHRvIHRoZSBhYm92ZSwgdGhlcmUgaXMgc29tZSB1bmNlcnRhaW50eSBh Ym91dCB0aGUKIyAgICAgICBtYXBwaW5ncyBpbiB0aGUgcmFuZ2UgQzZBMSAt IEM4RkUsIGFuZCBGOUREIC0gRjlGRS4gIFRoZSBFVEVOCiMJdmVyc2lvbiBv ZiBCSUc1IG9yZ2FuaXplcyB0aGUgZm9ybWVyIHJhbmdlIGRpZmZlcmVudGx5 LCBhbmQgYWRkcwojCWFkZGl0aW9uYWwgY2hhcmFjdGVycyBpbiB0aGUgbGF0 dGVyIHJhbmdlLiAgVGhlIGNvcnJlY3QgbWFwcGluZ3MKIwl0aGVzZSByYW5n ZXMgbmVlZCB0byBiZSBkZXRlcm1pbmVkLgojCiMJMi4gIFRoZXJlIGlzIGFu IHVuY2VydGFpbnR5IGluIHRoZSBtYXBwaW5nIG9mIHRoZSBCaWcgRml2ZSBj aGFyYWN0ZXIKIwkweEEzQkMuICBUaGlzIGNoYXJhY3RlciBvY2N1cnMgd2l0 aGluIHRoZSBCaWcgRml2ZSBibG9jayBvZiB0b25lIG1hcmtzCiMJZm9yIGJv cG9tb2ZvIGFuZCBpcyBpbnRlbmRlZCB0byBiZSB0aGUgdG9uZSBtYXJrIGZv ciB0aGUgZmlyc3QgdG9uZSBpbgojCU1hbmRhcmluIENoaW5lc2UuICBXZSBo YXZlIHNlbGVjdGVkIHRoZSBtYXBwaW5nIFUrMDJDOSBNT0RJRklFUiBMRVRU RVIKIwlNQUNST04gKE1hbmRhcmluIENoaW5lc2UgZmlyc3QgdG9uZSkgdG8g cmVmbGVjdCB0aGlzIHNlbWFudGljLiAgCiMJSG93ZXZlciwgYmVjYXVzZSBi b3BvbW9mbyB1c2VzIHRoZSBhYnNlbnNlIG9mIGEgdG9uZSBtYXJrIHRvIGlu ZGljYXRlCiMJdGhlIGZpcnN0IE1hbmRhcmluIHRvbmUsIG1vc3QgaW1wbGVt ZW50YXRpb25zIG9mIEJpZyBGaXZlIHJlcHJlc2VudAojCXRoaXMgY2hhcmFj dGVyIHdpdGggYSBibGFuayBzcGFjZSwgYW5kIHNvIGEgbWFwcGluZyBzdWNo IGFzIFUrMjAwMyBFTQojCVNQQUNFIG1pZ2h0IGJlIHByZWZlcnJlZC4gIAoj CiMJRm9ybWF0JiM1ODsgIFRocmVlIHRhYi1zZXBhcmF0ZWQgY29sdW1ucwoj CQkgQ29sdW1uICMxIGlzIHRoZSBCSUc1IGNvZGUgKGluIGhleCBhcyAweFhY WFgpCiMJCSBDb2x1bW4gIzIgaXMgdGhlIFVuaWNvZGUgKGluIGhleCBhcyAw eFhYWFgpCiMJCSBDb2x1bW4gIzMgIGlzIHRoZSBVbmljb2RlIG5hbWUgKGZv bGxvd3MgYSBjb21tZW50IHNpZ24sICcjJykKIwkJCVRoZSBvZmZpY2lhbCBu YW1lcyBmb3IgVW5pY29kZSBjaGFyYWN0ZXJzIFUrNEUwMAojCQkJdG8gVSs5 RkE1LCBpbmNsdXNpdmUsIGlzICJDSksgVU5JRklFRCBJREVPR1JBUEgtWFhY WCIsCiMJCQl3aGVyZSBYWFhYIGlzIHRoZSBjb2RlIHBvaW50LiAgSW5jbHVk aW5nIGFsbCB0aGVzZQojCQkJbmFtZXMgaW4gdGhpcyBmaWxlIGluY3JlYXNl cyBpdHMgc2l6ZSBzdWJzdGFudGlhbGx5CiMJCQlhbmQgbmVlZGxlc3NseS4g IFRoZSB0b2tlbiAiPENKSz4iIGlzIHVzZWQgZm9yIHRoZQojCQkJbmFtZSBv ZiB0aGVzZSBjaGFyYWN0ZXJzLiAgSWYgbmVjZXNzYXJ5LCBpdCBjYW4gYmUK IwkJCWV4cGFuZGVkIGFsZ29yaXRobWljYWxseSBieSBhIHBhcnNlciBvciBl ZGl0b3IuCiMKIwlUaGUgZW50cmllcyBhcmUgaW4gQklHNSBvcmRlcgojCiMK CiAKCjwvUFJFPgo8aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28u a3IvcmVhZC8xMDIyNjAyNDcxLWY4MWY2OGZhYzNmYWQ5MDc0ZmRiOGIxMzQ0 MzkwNGViLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25m aXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0xPgo8L0JPRFk+CjwvSFRN TD4K From owner-idn@ops.ietf.org Tue May 28 12:24:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23909 for ; Tue, 28 May 2002 12:24:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CjdN-0009Ld-00 for idn-data@psg.com; Tue, 28 May 2002 09:15:41 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CjdM-0009LV-00 for idn@ops.ietf.org; Tue, 28 May 2002 09:15:41 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4SGFbA30043 for ; Wed, 29 May 2002 01:15:37 +0900 Message-ID: <022c01c20662$e1900930$2b19fea9@temp> From: "Soobok Lee" To: Subject: [idn] BIG5< -> Unicode roundtrip compatibility Date: Wed, 29 May 2002 01:15:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I enclose an excerpt from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT. It says that some TC char X cannot be converted into UCS chars without losing roundtrip compatibility. ie, In a roundtrip conversion X --> UCS(X) --> X', It may arise that X != X'. Any legacy-encoded IRI(IDN)s including X, may fail to be compared successfully if they had undergone conversions into/from unicode. I will appreaciate if anyone present the history of BIG5 versions and its round-trip compatilibity problems in more detail. Soobok Lee -------------------------------------------------------------------------------- # Name: BIG5 to Unicode table (complete) # Unicode version: 1.1 # Table version: 0.0d3 # Table format: Format A # Date: 11 February 1994 # # Copyright (c) 1991-1994 Unicode, Inc. All Rights reserved. (snip) # If you have carefully considered the fact that the mappings in # this table are only one possible set of mappings between BIG5 and # Unicode and have no normative status, but still feel that you # have located an error in the table that requires fixing, you may # report any such error to errata@unicode.org. # # WARNING! It is currently impossible to provide round-trip compatibility # between BIG5 and Unicode. # # A number of characters are not currently mapped because # of conflicts with other mappings. They are as follows: # # BIG5 Description Comments # # 0xA15A SPACING UNDERSCORE duplicates A1C4 # 0xA1C3 SPACING HEAVY OVERSCORE not in Unicode # 0xA1C5 SPACING HEAVY UNDERSCORE not in Unicode # 0xA1FE LT DIAG UP RIGHT TO LOW LEFT duplicates A2AC # 0xA240 LT DIAG UP LEFT TO LOW RIGHT duplicates A2AD # 0xA2CC HANGZHOU NUMERAL TEN conflicts with A451 mapping # 0xA2CE HANGZHOU NUMERAL THIRTY conflicts with A4CA mapping # # We currently map all of these characters to U+FFFD REPLACEMENT CHARACTER. # It is also possible to map these characters to their duplicates, or to # the user zone. # # Notes: # # 1. In addition to the above, there is some uncertainty about the # mappings in the range C6A1 - C8FE, and F9DD - F9FE. The ETEN # version of BIG5 organizes the former range differently, and adds # additional characters in the latter range. The correct mappings # these ranges need to be determined. # # 2. There is an uncertainty in the mapping of the Big Five character # 0xA3BC. This character occurs within the Big Five block of tone marks # for bopomofo and is intended to be the tone mark for the first tone in # Mandarin Chinese. We have selected the mapping U+02C9 MODIFIER LETTER # MACRON (Mandarin Chinese first tone) to reflect this semantic. # However, because bopomofo uses the absense of a tone mark to indicate # the first Mandarin tone, most implementations of Big Five represent # this character with a blank space, and so a mapping such as U+2003 EM # SPACE might be preferred. # # Format: Three tab-separated columns # Column #1 is the BIG5 code (in hex as 0xXXXX) # Column #2 is the Unicode (in hex as 0xXXXX) # Column #3 is the Unicode name (follows a comment sign, '#') # The official names for Unicode characters U+4E00 # to U+9FA5, inclusive, is "CJK UNIFIED IDEOGRAPH-XXXX", # where XXXX is the code point. Including all these # names in this file increases its size substantially # and needlessly. The token "" is used for the # name of these characters. If necessary, it can be # expanded algorithmically by a parser or editor. # # The entries are in BIG5 order # # From owner-idn@ops.ietf.org Tue May 28 13:24:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25764 for ; Tue, 28 May 2002 13:24:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CkYV-000B4m-00 for idn-data@psg.com; Tue, 28 May 2002 10:14:43 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CkYU-000B4d-00 for idn@ops.ietf.org; Tue, 28 May 2002 10:14:42 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4SHEeA30591 for ; Wed, 29 May 2002 02:14:40 +0900 Message-ID: <024701c2066b$2127a9b0$2b19fea9@temp> From: "Soobok Lee" To: References: Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 02:14:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The big problem lies in that such bad and loose versioning practice is *everywhere*. And precise and correct legacy-code versioning requires that "code-range&version" checking routines should be inserted in every application. And such checking routines themselves also should be versioned because legacy encodings are ever evolving. Both objectives requires upgrading all existing i18n applications, but that may be not feasible, by the same reason why IDNA is preferred over UTF8 approach in this WG. For example, let's assume future Outlook Express 7.0 will fix the bug by introducing new mime charset name "KS_C_5601-1992" . The sender posts an email message in KS_C_5601-1992 to the recipient who uses Outlook Express 6.0 which knows only "KS_C_5601-1987". What will happen? maybe, fallback to iso8859-1 or default locale. direct-charset-negotiation between the sender/recipient's email clients are not possible. A XML application server receives a XML request encoded in new KS_C_5601_1992, but the server applications don't know the new charset. what happens if the transaction was in batch mode? There may be no immediate/interactive error report to the orginator. That explains how much difficult it would be to introduce new version or new legacy encoding into the IDN repertoires of supported encodings , if a certain version of IDN/IRI would have been widely deployed. Soobok Lee ----- Original Message ----- From: "Roozbeh Pournader" > On Wed, 29 May 2002, Soobok Lee wrote: > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > Stupid and Wrong Versioning! > > Sure. But no protocol can fix broken software. Nag to developers of the > software to fix it. In this case, it is passing a character onto wire, > which is not in the character set it is claiming it to be in. > > If a piece of software wants to work with KSC 5601:1992, and use the > character you used, should know its mapping to Unicode. Simple. > > roozbeh > > > From owner-idn@ops.ietf.org Tue May 28 18:31:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03159 for ; Tue, 28 May 2002 18:31:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CpCI-000JfE-00 for idn-data@psg.com; Tue, 28 May 2002 15:12:06 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17CpCH-000Jf6-00 for idn@ops.ietf.org; Tue, 28 May 2002 15:12:05 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17CpCF-000711-00 for ; Tue, 28 May 2002 15:12:03 -0700 Date: Tue, 28 May 2002 22:12:03 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Message-ID: <20020528221203.GC24925@nicemice.net> Reply-To: IETF idn working group References: <200205231129.HAA04661@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC wrote: > > When all systems use ASCII or Unicode, different interpretations are > > not allowed in this specification. > > A user system that "uses Unicode" could still make wrong judgements > between the keyboard and the encoding. For example, on the Mac, > typing Option-8 inserts a bullet character. There are many different > bullet characters in the Unicode character repertoire, so entering > a host name that includes one of those bullet symbols might get the > wrong result. Thus, I'd rather not use that last sentence. Agreed. > > When involved systems use non-ASCII and non-Unicode characters (such > > as ISO-8859-1 and ISO-2022-JP, which are common on the Internet), > > We're not concerned with what is common on the Internet, but what is > common in systems. I don't think we need to mention any specific character sets. If the reader doesn't already know that there are character sets other than ASCII and Unicode, then none of this is going to be understandable anyway. > > however, this specification leaves the transcoding problem up to > > the application. Thus there can not be any assurance that two > > applications will not implement different transcoding rules. When > > two applications implement different transcoding rules, they will > > (assuming both domains exists) contact different servers. Note > > that the problem can not just easily be solved by using a security > > protocol such as TLS to identify and authenticate to end points, > > unless these protocols have already solved the problem which IDNA is > > trying to solve. > > That seems like a good addition. I have no objection. We might be able to compact it a bit: Domain names are used by users to identify and connect to Internet servers. The security of the Internet is compromised if a user entering a single internationalized name is connected to different servers based on different interpretations of the internationalized domain name. When systems use local character sets other than ASCII and Unicode, this specification leaves the transcoding problem up to the application. If applications implement different transcoding rules, they could interpret the same name differently and contact different servers. This problem is not solved by security protocols like TLS that do not take local character sets into account. [I didn't change the first paragraph except to remove the last sentence.] Simon, does that still say everything you want it to? AMC From owner-idn@ops.ietf.org Tue May 28 18:52:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03533 for ; Tue, 28 May 2002 18:52:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CpkK-000Kk3-00 for idn-data@psg.com; Tue, 28 May 2002 15:47:16 -0700 Received: from heron.verisign.com ([216.168.233.95]) by psg.com with esmtp (Exim 3.36 #1) id 17CpkJ-000Kjx-00 for idn@ops.ietf.org; Tue, 28 May 2002 15:47:15 -0700 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id SAA01503 for ; Tue, 28 May 2002 18:47:44 -0400 (EDT) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 18:47:14 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60267B010@vsvapostal3.bkup6> From: "Colosi, John" To: idn@ops.ietf.org Subject: [idn] Circular Reference in the IDNA / Nameprep documentation Date: Tue, 28 May 2002 18:47:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk All, The current documentation layout for prohibited codepoints seems confusing. To properly implement prohibitions consistent with the Nameprep 10 draft, one must: Conditionally prohibit five (5) ranges (IDNA) Conditionally prohibit leading/trailing hyphens (IDNA) Prohibit additional delimiters (+U3002) (Nameprep) Prohibit ranges from "Prohibition Tables" (Stringprep) Prohibit ranges from "Unassigned Codepoints" (Stringprep) [ from "draft-ietf-idn-nameprep-10.txt", line 107 ] "IMPORTANT NOTE: This profile MUST be used with the IDNA protocol. The IDNA protocol has additional prohibitions that are checked outside of this profile." If this statement is true, and Nameprep MUST be implemented with consideration to prohibitions in IDNA, then shouldn't these prohibitions be incorporated in the Nameprep draft? Nameprep's reference to IDNA, taken in conjunction with IDNA's reference to Nameprep seems circular. What is the motivation for relegating the conditional prohibitions to the IDNA draft? Could "non-LDH" characters be specified in a table of the Stringprep draft? The Nameprep draft would then reference this table in a conditional prohibition, encapsulating the name preparation concept. -- John From owner-idn@ops.ietf.org Tue May 28 20:09:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04665 for ; Tue, 28 May 2002 20:09:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CqrO-000Msx-00 for idn-data@psg.com; Tue, 28 May 2002 16:58:38 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17CqrN-000Msp-00 for idn@ops.ietf.org; Tue, 28 May 2002 16:58:38 -0700 Received: (qmail 30683 invoked from network); 29 May 2002 00:00:48 -0000 Received: from bb-203-125-6-74.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.6.74) by sentosa.post1.com with SMTP; 29 May 2002 00:00:48 -0000 Message-ID: <005001c206a3$7d62fb70$8000a8c0@JAMESSONYVAIO> From: "James Seng" To: "Soobok Lee" , References: <024701c2066b$2127a9b0$2b19fea9@temp> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 07:57:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If the problem is with the implementation, we fix the implementation, not the protocol. We have similar arguments before. -James Seng ----- Original Message ----- From: "Soobok Lee" To: Sent: Wednesday, May 29, 2002 1:14 AM Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > The big problem lies in that such bad and loose versioning practice is *everywhere*. > And precise and correct legacy-code versioning requires that "code-range&version" checking routines > should be inserted in every application. And such checking routines themselves also should be > versioned because legacy encodings are ever evolving. Both objectives requires upgrading all existing > i18n applications, but that may be not feasible, by the same reason why IDNA is preferred over UTF8 approach > in this WG. > > For example, let's assume future Outlook Express 7.0 will fix the bug by introducing > new mime charset name "KS_C_5601-1992" . The sender posts an email message in KS_C_5601-1992 > to the recipient who uses Outlook Express 6.0 which knows only "KS_C_5601-1987". > What will happen? maybe, fallback to iso8859-1 or default locale. > direct-charset-negotiation between the sender/recipient's email clients are not possible. > > A XML application server receives a XML request encoded in new KS_C_5601_1992, but the server applications > don't know the new charset. what happens if the transaction was in batch mode? There may be no immediate/interactive error report to > the orginator. > > That explains how much difficult it would be to introduce new version or new legacy encoding into > the IDN repertoires of supported encodings , if a certain version of IDN/IRI would have been widely deployed. > > Soobok Lee > > ----- Original Message ----- > From: "Roozbeh Pournader" > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > > Stupid and Wrong Versioning! > > > > Sure. But no protocol can fix broken software. Nag to developers of the > > software to fix it. In this case, it is passing a character onto wire, > > which is not in the character set it is claiming it to be in. > > > > If a piece of software wants to work with KSC 5601:1992, and use the > > character you used, should know its mapping to Unicode. Simple. > > > > roozbeh > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 20:21:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04811 for ; Tue, 28 May 2002 20:21:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Cr7f-000NQ6-00 for idn-data@psg.com; Tue, 28 May 2002 17:15:27 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17Cr7e-000NQ0-00 for idn@ops.ietf.org; Tue, 28 May 2002 17:15:27 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4T0FCA03947; Wed, 29 May 2002 09:15:12 +0900 Message-ID: <02a701c206a5$e27c6990$2b19fea9@temp> From: "Soobok Lee" To: "James Seng" , References: <024701c2066b$2127a9b0$2b19fea9@temp> <005001c206a3$7d62fb70$8000a8c0@JAMESSONYVAIO> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 09:15:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The legacy encodings are ever evolving and ever *emerging*. That is not the implementation issue , rather protocol/architecture issues, IMO. Soobok Lee ----- Original Message ----- From: "James Seng" To: "Soobok Lee" ; Sent: Wednesday, May 29, 2002 8:57 AM Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > If the problem is with the implementation, we fix the implementation, not > the protocol. We have similar arguments before. > > -James Seng > > ----- Original Message ----- > From: "Soobok Lee" > To: > Sent: Wednesday, May 29, 2002 1:14 AM > Subject: Re: [idn] Re: Legacy charset conversion in > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > The big problem lies in that such bad and loose versioning practice is > *everywhere*. > > And precise and correct legacy-code versioning requires that > "code-range&version" checking routines > > should be inserted in every application. And such checking routines > themselves also should be > > versioned because legacy encodings are ever evolving. Both objectives > requires upgrading all existing > > i18n applications, but that may be not feasible, by the same reason why > IDNA is preferred over UTF8 approach > > in this WG. > > > > For example, let's assume future Outlook Express 7.0 will fix the bug by > introducing > > new mime charset name "KS_C_5601-1992" . The sender posts an email message > in KS_C_5601-1992 > > to the recipient who uses Outlook Express 6.0 which knows only > "KS_C_5601-1987". > > What will happen? maybe, fallback to iso8859-1 or default locale. > > direct-charset-negotiation between the sender/recipient's email clients > are not possible. > > > > A XML application server receives a XML request encoded in new > KS_C_5601_1992, but the server applications > > don't know the new charset. what happens if the transaction was in batch > mode? There may be no immediate/interactive error report to > > the orginator. > > > > That explains how much difficult it would be to introduce new version or > new legacy encoding into > > the IDN repertoires of supported encodings , if a certain version of > IDN/IRI would have been widely deployed. > > > > Soobok Lee > > > > ----- Original Message ----- > > From: "Roozbeh Pournader" > > > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > > > Stupid and Wrong Versioning! > > > > > > Sure. But no protocol can fix broken software. Nag to developers of the > > > software to fix it. In this case, it is passing a character onto wire, > > > which is not in the character set it is claiming it to be in. > > > > > > If a piece of software wants to work with KSC 5601:1992, and use the > > > character you used, should know its mapping to Unicode. Simple. > > > > > > roozbeh > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 20:31:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04957 for ; Tue, 28 May 2002 20:31:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CrIE-000NpV-00 for idn-data@psg.com; Tue, 28 May 2002 17:26:22 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17CrID-000NpO-00 for idn@ops.ietf.org; Tue, 28 May 2002 17:26:21 -0700 Received: (qmail 30838 invoked from network); 29 May 2002 00:28:41 -0000 Received: from bb-203-125-6-74.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.6.74) by sentosa.post1.com with SMTP; 29 May 2002 00:28:41 -0000 Message-ID: <00ae01c206a7$62aa2ca0$8000a8c0@JAMESSONYVAIO> From: "James Seng" To: "Soobok Lee" , References: <024701c2066b$2127a9b0$2b19fea9@temp> <005001c206a3$7d62fb70$8000a8c0@JAMESSONYVAIO> <02a701c206a5$e27c6990$2b19fea9@temp> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 08:25:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The legacy encodings are ever evolving and ever *emerging*. Yes. > That is not the implementation issue , rather protocol/architecture issues, IMO. No. The problem you describe, ie the improper handling of legacy encoding is an implementation issue, not protocol one. Don't confuse the two. -James Seng > Soobok Lee > > ----- Original Message ----- > From: "James Seng" > To: "Soobok Lee" ; > Sent: Wednesday, May 29, 2002 8:57 AM > Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > If the problem is with the implementation, we fix the implementation, not > > the protocol. We have similar arguments before. > > > > -James Seng > > > > ----- Original Message ----- > > From: "Soobok Lee" > > To: > > Sent: Wednesday, May 29, 2002 1:14 AM > > Subject: Re: [idn] Re: Legacy charset conversion in > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > The big problem lies in that such bad and loose versioning practice is > > *everywhere*. > > > And precise and correct legacy-code versioning requires that > > "code-range&version" checking routines > > > should be inserted in every application. And such checking routines > > themselves also should be > > > versioned because legacy encodings are ever evolving. Both objectives > > requires upgrading all existing > > > i18n applications, but that may be not feasible, by the same reason why > > IDNA is preferred over UTF8 approach > > > in this WG. > > > > > > For example, let's assume future Outlook Express 7.0 will fix the bug by > > introducing > > > new mime charset name "KS_C_5601-1992" . The sender posts an email message > > in KS_C_5601-1992 > > > to the recipient who uses Outlook Express 6.0 which knows only > > "KS_C_5601-1987". > > > What will happen? maybe, fallback to iso8859-1 or default locale. > > > direct-charset-negotiation between the sender/recipient's email clients > > are not possible. > > > > > > A XML application server receives a XML request encoded in new > > KS_C_5601_1992, but the server applications > > > don't know the new charset. what happens if the transaction was in batch > > mode? There may be no immediate/interactive error report to > > > the orginator. > > > > > > That explains how much difficult it would be to introduce new version or > > new legacy encoding into > > > the IDN repertoires of supported encodings , if a certain version of > > IDN/IRI would have been widely deployed. > > > > > > Soobok Lee > > > > > > ----- Original Message ----- > > > From: "Roozbeh Pournader" > > > > > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > > > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > > > > Stupid and Wrong Versioning! > > > > > > > > Sure. But no protocol can fix broken software. Nag to developers of the > > > > software to fix it. In this case, it is passing a character onto wire, > > > > which is not in the character set it is claiming it to be in. > > > > > > > > If a piece of software wants to work with KSC 5601:1992, and use the > > > > character you used, should know its mapping to Unicode. Simple. > > > > > > > > roozbeh > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 20:45:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05139 for ; Tue, 28 May 2002 20:45:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CrSv-000OB4-00 for idn-data@psg.com; Tue, 28 May 2002 17:37:25 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CrSu-000OAy-00 for idn@ops.ietf.org; Tue, 28 May 2002 17:37:24 -0700 Received: from MASTER ([203.229.224.207]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4T0auA04070; Wed, 29 May 2002 09:36:56 +0900 Message-ID: <02c501c206a8$eb5b8070$2b19fea9@temp> From: "Soobok Lee" To: "James Seng" , References: <024701c2066b$2127a9b0$2b19fea9@temp> <005001c206a3$7d62fb70$8000a8c0@JAMESSONYVAIO> <02a701c206a5$e27c6990$2b19fea9@temp> <00ae01c206a7$62aa2ca0$8000a8c0@JAMESSONYVAIO> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 09:36:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Seng" > No. The problem you describe, ie the improper handling of legacy encoding is > an implementation issue, not protocol one. If legacy encodings are incorporated into any IDNA libraries, There arise legacy encoding versioning problems, regardles of whether the legacy encoding implementations were correct or not at that time of first deployment. In summary, the issue is that: How can we build IDNA tower on the ground of moving legacy encodings ? Is it still implementation issue? In Sanfrancisco and Tokyo, every building should be well architectured against any earthquakes and 'soften' land. Soobok Lee > > Don't confuse the two. > > -James Seng > > > Soobok Lee > > > > ----- Original Message ----- > > From: "James Seng" > > To: "Soobok Lee" ; > > Sent: Wednesday, May 29, 2002 8:57 AM > > Subject: Re: [idn] Re: Legacy charset conversion in > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > If the problem is with the implementation, we fix the implementation, > not > > > the protocol. We have similar arguments before. > > > > > > -James Seng > > > > > > ----- Original Message ----- > > > From: "Soobok Lee" > > > To: > > > Sent: Wednesday, May 29, 2002 1:14 AM > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > The big problem lies in that such bad and loose versioning practice is > > > *everywhere*. > > > > And precise and correct legacy-code versioning requires that > > > "code-range&version" checking routines > > > > should be inserted in every application. And such checking routines > > > themselves also should be > > > > versioned because legacy encodings are ever evolving. Both objectives > > > requires upgrading all existing > > > > i18n applications, but that may be not feasible, by the same reason > why > > > IDNA is preferred over UTF8 approach > > > > in this WG. > > > > > > > > For example, let's assume future Outlook Express 7.0 will fix the bug > by > > > introducing > > > > new mime charset name "KS_C_5601-1992" . The sender posts an email > message > > > in KS_C_5601-1992 > > > > to the recipient who uses Outlook Express 6.0 which knows only > > > "KS_C_5601-1987". > > > > What will happen? maybe, fallback to iso8859-1 or default locale. > > > > direct-charset-negotiation between the sender/recipient's email > clients > > > are not possible. > > > > > > > > A XML application server receives a XML request encoded in new > > > KS_C_5601_1992, but the server applications > > > > don't know the new charset. what happens if the transaction was in > batch > > > mode? There may be no immediate/interactive error report to > > > > the orginator. > > > > > > > > That explains how much difficult it would be to introduce new version > or > > > new legacy encoding into > > > > the IDN repertoires of supported encodings , if a certain version of > > > IDN/IRI would have been widely deployed. > > > > > > > > Soobok Lee > > > > > > > > ----- Original Message ----- > > > > From: "Roozbeh Pournader" > > > > > > > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > > > > > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > > > > > Stupid and Wrong Versioning! > > > > > > > > > > Sure. But no protocol can fix broken software. Nag to developers of > the > > > > > software to fix it. In this case, it is passing a character onto > wire, > > > > > which is not in the character set it is claiming it to be in. > > > > > > > > > > If a piece of software wants to work with KSC 5601:1992, and use the > > > > > character you used, should know its mapping to Unicode. Simple. > > > > > > > > > > roozbeh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 20:51:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05214 for ; Tue, 28 May 2002 20:51:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Crbc-000OUu-00 for idn-data@psg.com; Tue, 28 May 2002 17:46:24 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17Crbb-000OUn-00 for idn@ops.ietf.org; Tue, 28 May 2002 17:46:23 -0700 Received: (qmail 30944 invoked from network); 29 May 2002 00:48:43 -0000 Received: from bb-203-125-6-74.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.6.74) by sentosa.post1.com with SMTP; 29 May 2002 00:48:43 -0000 Message-ID: <00d501c206aa$2f150970$8000a8c0@JAMESSONYVAIO> From: "James Seng" To: "Soobok Lee" , References: <024701c2066b$2127a9b0$2b19fea9@temp> <005001c206a3$7d62fb70$8000a8c0@JAMESSONYVAIO> <02a701c206a5$e27c6990$2b19fea9@temp> <00ae01c206a7$62aa2ca0$8000a8c0@JAMESSONYVAIO> <02c501c206a8$eb5b8070$2b19fea9@temp> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Wed, 29 May 2002 08:45:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lee, I repeat: legacy encoding evolves -- yes; but each one is tagged properly. Implementation which does not handle legacy encoding properly is an implementation problem, not a protocol one. Evolving encoding standards is not an issue. By all means twist the arguments round in circle, in your usual style. This will be my last email on this thread. -James Seng > ----- Original Message ----- > From: "James Seng" > > > No. The problem you describe, ie the improper handling of legacy encoding is > > an implementation issue, not protocol one. > > If legacy encodings are incorporated into any IDNA libraries, > There arise legacy encoding versioning problems, regardles of whether > the legacy encoding implementations were correct or not at that time of first deployment. > > In summary, the issue is that: How can we build IDNA tower on the ground > of moving legacy encodings ? Is it still implementation issue? > In Sanfrancisco and Tokyo, every building should be well architectured > against any earthquakes and 'soften' land. > > Soobok Lee > > > > > Don't confuse the two. > > > > -James Seng > > > > > Soobok Lee > > > > > > ----- Original Message ----- > > > From: "James Seng" > > > To: "Soobok Lee" ; > > > Sent: Wednesday, May 29, 2002 8:57 AM > > > Subject: Re: [idn] Re: Legacy charset conversion in > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > If the problem is with the implementation, we fix the implementation, > > not > > > > the protocol. We have similar arguments before. > > > > > > > > -James Seng > > > > > > > > ----- Original Message ----- > > > > From: "Soobok Lee" > > > > To: > > > > Sent: Wednesday, May 29, 2002 1:14 AM > > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > > > > The big problem lies in that such bad and loose versioning practice is > > > > *everywhere*. > > > > > And precise and correct legacy-code versioning requires that > > > > "code-range&version" checking routines > > > > > should be inserted in every application. And such checking routines > > > > themselves also should be > > > > > versioned because legacy encodings are ever evolving. Both objectives > > > > requires upgrading all existing > > > > > i18n applications, but that may be not feasible, by the same reason > > why > > > > IDNA is preferred over UTF8 approach > > > > > in this WG. > > > > > > > > > > For example, let's assume future Outlook Express 7.0 will fix the bug > > by > > > > introducing > > > > > new mime charset name "KS_C_5601-1992" . The sender posts an email > > message > > > > in KS_C_5601-1992 > > > > > to the recipient who uses Outlook Express 6.0 which knows only > > > > "KS_C_5601-1987". > > > > > What will happen? maybe, fallback to iso8859-1 or default locale. > > > > > direct-charset-negotiation between the sender/recipient's email > > clients > > > > are not possible. > > > > > > > > > > A XML application server receives a XML request encoded in new > > > > KS_C_5601_1992, but the server applications > > > > > don't know the new charset. what happens if the transaction was in > > batch > > > > mode? There may be no immediate/interactive error report to > > > > > the orginator. > > > > > > > > > > That explains how much difficult it would be to introduce new version > > or > > > > new legacy encoding into > > > > > the IDN repertoires of supported encodings , if a certain version of > > > > IDN/IRI would have been widely deployed. > > > > > > > > > > Soobok Lee > > > > > > > > > > ----- Original Message ----- > > > > > From: "Roozbeh Pournader" > > > > > > > > > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > > > > > > > > > you can find the errornous mime-charset name : "KS_C_5601-1987". > > > > > > > Stupid and Wrong Versioning! > > > > > > > > > > > > Sure. But no protocol can fix broken software. Nag to developers of > > the > > > > > > software to fix it. In this case, it is passing a character onto > > wire, > > > > > > which is not in the character set it is claiming it to be in. > > > > > > > > > > > > If a piece of software wants to work with KSC 5601:1992, and use the > > > > > > character you used, should know its mapping to Unicode. Simple. > > > > > > > > > > > > roozbeh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Tue May 28 21:55:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06541 for ; Tue, 28 May 2002 21:55:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CsZn-0000Yz-00 for idn-data@psg.com; Tue, 28 May 2002 18:48:35 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17CsZm-0000Yt-00 for idn@ops.ietf.org; Tue, 28 May 2002 18:48:34 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17CsZh-0007rT-00 for ; Tue, 28 May 2002 18:48:29 -0700 Date: Wed, 29 May 2002 01:48:28 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020529014828.GD24925@nicemice.net> Reply-To: IETF idn working group References: <3CF24C00.3186F15F@trab.se> <13839118.1022523536@localhost> <3CF24C00.3186F15F@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13839118.1022523536@localhost> <3CF24C00.3186F15F@trab.se> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dan Oscarsson brings up an interesting point. The introduction section of IDNA says: IDNA does not require changes to any infrastructure. In particular, IDNA does not require any changes to DNS servers, resolvers, or protocol elements, because the ASCII name service provided by the existing DNS is entirely sufficient. Later, section 6.3 says: All IDNs served by DNS servers MUST contain only ASCII characters. Clearly IDNA does "require" a change to the DNS infrastructure, because it introduces some new requirements, some of which apply to DNS servers. This apparent contradiction comes from multiple senses of the word "require". When I wrote that paragraph in the introduction, I meant "require" in the sense of "depend on", not "demand". I suggest clarifying this by changing "require" to "depend on" in the two instances quoted above, and making similar changes in the last paragraph before 1.1: - Proposals that were not chosen by the IDN Working Group would - require that user applications, resolvers, and DNS servers be - updated in order for a user to use an internationalized domain name. + Proposals that were not chosen by the IDN Working Group would depend + on user applications, resolvers, and DNS servers being updated in + order for a user to use an internationalized domain name. - Rather than require widespread updating of all components, IDNA - requires only user applications to be updated; + Rather than rely on widespread updating of all components, IDNA + depends on updates to user applications only; Even though IDNA does make some demands on DNS servers, IDNA will still work with DNS servers that predate IDNA, as long as the new zone files are created in an IDNA-conformant way (with IDNs stored in their ASCII forms). That's why we can say that IDNA does not depend on changes to the infrastructure. Dan Oscarsson wrote: > Regarding the ASCII names of DNS is sufficient you probably mean > that it is sufficient for IDNA. Yes, exactly. > It is not generally sufficient. I think the meaning is clear enough, but I wouldn't object if "for IDNA" were added at the end of that paragraph (again, the first paragraph of the introduction). I'll leave the decision to Paul and Patrick. > it is stated that resolvers do not need to be changed. Indeed, they don't need to be changed. > But it is probably the resolver libraries that should be changed. The spec doesn't say they shouldn't be changed, it just says they don't need to be. Whether they should be changed is something that OS makers can decide for themselves. > The definition of what IDN means is complex. It is defined to be a > domain name on which ToASCII can be applied without failing. The internals of ToASCII are complex, but once you encapsulate that concept, the definition of IDN is quite simple, as you have just illustrated. > And then in the text IDN is sometimes used to mean a ACE-encoded name > and sometimes to mean a UCS-encoded name. When the text says IDN, it means IDN as defined is section 2. If there is someplace where IDN is used to mean something else, please point it out, because it would be an error. An IDN can contain ACE labels and non-ACE ASCII labels and non-ASCII labels. As long as every label of a domain name passes ToASCII, it's an IDN. > The basic definition for domain names should be IDNA does not define domain names or labels. That's not its job. IDNA defines internationalized domain names and internationalized labels in terms of the preexisting concepts of domain names and labels. > Section 3 says in requirement 1) that several different "dots" are > allowed between labels when written that way. There are probably more > "dots" in UCS that could work. There are. > I see no reason to forbid them, unless all are forbidden except > U+002E. We don't forbid them. The draft nowhere prohibits applications from accepting additional characters as dots. But only full stop and ideographic full stop (and their fullwidth/halfwidth versions) are required to be accepted by all applications. Ideographic full stop was singled out because it's the only one that anyone ever asked for. I think that's probably because it's the only one that belongs to a script large enough to use a modal input method. CJK users need to switch modes in order to type the ASCII full stop, whereas for other users the ASCII full stop is probably within easier reach. > Only one type of dots simplifies comparing of names. True, but comparing names is already pretty complex (it involves Unicode normalization, and sometimes also transcoding to Unicode). > Only one type of "dot" should be used in each context. > In a Latin based context only U+002E should be used. Names can be copied from one context into a different context. I'd rather both dots work in both contexts. I can't think of any way users would benefit if Latin contexts refused to accept ideographic full stop. > 3) If a name is put an a non_ASCII context it must be > changed to the character set of that context We distinguish between structured data (domain name slots, which contain domain names intended to be used by programs) and unstructured data (text intended primarily to be viewed by humans). If an IDN is put into an IDN-unaware domain name slot, then it must be converted to the ASCII form regardless of whether that context supports non-ASCII characters. That's because even if the application receiving the name knows how to represent non-ASCII strings, it doesn't necessarily know how to compare IDNs. We must play it safe and use the ASCII form unless we know the receiver knows how to compare IDNs. If an IDN is put into unstructured text, the usual rules for putting any string into that context apply; IDNA adds no special requirements for IDNs in this situation. > 4) When two names are compared they must both be in the same context > and be normalised. IDNA defines comparison of names very precisely. > IDNA mandates (probably) that a domain name used in a link in a html > document must be ACE encoded. This is not what is natural for people > to use. It's up to the HTML folks to update the HTML spec to support IDNs natively. I think they're already working on this. In the meantime, authors of HTML documents can either enter the ACE themselves or use an HTML editor/preprocessor that understands IDNA. > IDNA must NOT restrict current usage and DNS standards making it > impossible to update the DNS standard later with a suitable defined > handling of non-ASCII octet values! The door is left open for updates to DNS: If a signaling system which makes negotiation possible between old and new DNS clients and servers is standardized in the future, the encoding of the query in the DNS protocol itself can be changed from ACE to something else, such as UTF-8. What we don't want to allow is untagged non-ASCII text in DNS messages, because there is no standard for what it means or how it should be compared. > IDNA is not an update of the DNS standard. IDNA is mainly orthogonal to the DNS standard, but it could be considered an update in one small respect. RFCs 1034 and 1035 say: domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. we may someday need to add full binary domain names for new services; future additions beyond current usage may need to use the full binary octet capabilities in names Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. It seems pretty clear that the 8th bit is reserved for future use. As far as I know, no use for the 8th bit has ever been standardized. IDNA effectively says that the 8th bit is not to be used for internationalization, at least not for the time being. It's still available for other purposes (like non-textual domain names). Patrik Fältström wrote: > IDNA does NOT change the definition of DNS labels. Right. > It only says that labels with a specific prefix are said to be "IDN > labels". There is no such term as "IDN label". Labels that get modified by ToUnicode are said to be "ACE labels". AMC From owner-idn@ops.ietf.org Tue May 28 22:23:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06915 for ; Tue, 28 May 2002 22:23:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ct26-0001aU-00 for idn-data@psg.com; Tue, 28 May 2002 19:17:50 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Ct25-0001aB-00 for idn@ops.ietf.org; Tue, 28 May 2002 19:17:50 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94074 for idn@ops.ietf.org; Tue, 28 May 2002 21:17:56 -0500 Message-ID: <3CF43A4B.607B274D@ehsco.com> Date: Tue, 28 May 2002 21:17:47 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CF24C00.3186F15F@trab.se> <13839118.1022523536@localhost> <3CF24C00.3186F15F@trab.se> <20020529014828.GD24925@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > I suggest clarifying this by changing "require" to "depend on" in the > two instances quoted above, and making similar changes in the last > paragraph before 1.1: Please delete the reference. It is non-contributory to implementation of the specification and is somewhat argumentative. Cumulatively, it is a distraction to the protocol. > As far as I know, no use for the 8th bit has ever been standardized. The standardized usage is local interpretation. Any usage is compliant. > IDNA effectively says that the 8th bit is not to be used for > internationalization, at least not for the time being. It's still > available for other purposes (like non-textual domain names). These can still be supported, but they can't be run through the converter. They have to be treated as exceptions. This is in DM-IDNS-01, now that it is going to a strong data-typing model. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue May 28 22:34:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07411 for ; Tue, 28 May 2002 22:34:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CtAV-0001rE-00 for idn-data@psg.com; Tue, 28 May 2002 19:26:31 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17CtAU-0001r8-00 for idn@ops.ietf.org; Tue, 28 May 2002 19:26:30 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17CtAT-00080I-00 for ; Tue, 28 May 2002 19:26:29 -0700 Date: Wed, 29 May 2002 02:26:29 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] conversion collisions Message-ID: <20020529022629.GE24925@nicemice.net> Reply-To: IETF idn working group References: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <3611664.1022503430@localhost> <3CF3ABFD.C5AD5368@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF3ABFD.C5AD5368@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > The default behavior as specified in IDNA is to perform conversion, > even though these standardized protocols [whois and finger] do not > require conversion, since they implicitly allow any charset. Just because they allow any charset does not mean ToASCII is not necessary. If a non-ASCII domain name falls into the hands of an IDN-unaware application, that application (or something else downstream of it) is likely to choke on the name or fail to compare it correctly. [For these particular examples, I think the output of finger and whois are plain text intended for humans, not conforming to any standard syntax, and thus not designed for applications to be able to pick out the domain names from the surrounding text. If that's true, IDNA does not require the domain names to be in ASCII form, but rather recommends that they be in non-ACE form.] > if an IDNA mailer passes a converted i18n HTTPS URL to a web browser, > then the comparison operation will fail. How? If the URI spec does not explicitly allow IDNs in the host field, then whoever creates the URI is required by IDNA to convert the host to ASCII before putting it in the URI. That is the situation with today's URI spec. Now suppose there is a newURI spec that explicitly allows IDNs in the host field, in some form other than ACE. If the browser supports newURIs, then it is IDN-aware, and hence it knows how to compare IDNs. If the browser does not support newURIs, then the failure is the result of passing a newURI to a browser that doesn't support newURIs, and you can hardly blame IDNA for that. AMC From owner-idn@ops.ietf.org Tue May 28 23:04:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08038 for ; Tue, 28 May 2002 23:04:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CtYT-0002k1-00 for idn-data@psg.com; Tue, 28 May 2002 19:51:17 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17CtYS-0002jv-00 for idn@ops.ietf.org; Tue, 28 May 2002 19:51:16 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17CtYS-0008C0-00 for ; Tue, 28 May 2002 19:51:16 -0700 Date: Wed, 29 May 2002 02:51:16 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Circular Reference in the IDNA / Nameprep documentation Message-ID: <20020529025116.GF24925@nicemice.net> Reply-To: IETF idn working group References: <3CD14E451751BD42BA48AAA50B07BAD60267B010@vsvapostal3.bkup6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60267B010@vsvapostal3.bkup6> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Colosi, John" wrote: > What is the motivation for relegating the conditional prohibitions to > the IDNA draft? Could "non-LDH" characters be specified in a table of > the Stringprep draft? The Nameprep draft would then reference this > table in a conditional prohibition, encapsulating the name preparation > concept. The check for leading/trailing hyphens cannot be done within the Stringprep framework. Stringprep has no provisions for prohibiting characters in selected places in the string. ToASCII is the only place we can perform this check. The check for non-LDH ASCII code points is done in the same place. We want to keep these two checks together because they are both derived from the same source (the STD3 host name syntax) and both are enabled by a single flag. AMC From owner-idn@ops.ietf.org Tue May 28 23:05:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08072 for ; Tue, 28 May 2002 23:05:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CtYz-0002m5-00 for idn-data@psg.com; Tue, 28 May 2002 19:51:49 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17CtYy-0002lz-00 for idn@ops.ietf.org; Tue, 28 May 2002 19:51:48 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94079 for idn@ops.ietf.org; Tue, 28 May 2002 21:51:53 -0500 Message-ID: <3CF44240.5511497@ehsco.com> Date: Tue, 28 May 2002 21:51:45 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] conversion collisions References: <5.1.0.14.2.20020525183341.03bffb78@jay.songbird.com> <3611664.1022503430@localhost> <3CF3ABFD.C5AD5368@ehsco.com> <20020529022629.GE24925@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > "Eric A. Hall" wrote: > > > The default behavior as specified in IDNA is to perform conversion, > > even though these standardized protocols [whois and finger] do not > > require conversion, since they implicitly allow any charset. > > Just because they allow any charset does not mean ToASCII is not > necessary. I didn't say it was unnecessary. In fact, I said it would be appropriate. What I also said is that the behavior needed to be defined in a standards-track update to those protocols so that implementors know what to do and where to do it. > > if an IDNA mailer passes a converted i18n HTTPS URL to a web browser, > > then the comparison operation will fail. > > How? If the URI spec does not explicitly allow IDNs in the host field, > then whoever creates the URI is required by IDNA to convert the host to > ASCII before putting it in the URI. There's more than one way to pass data between apps. Structured exchange over well-defined APIs is only one of them. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue May 28 23:12:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08157 for ; Tue, 28 May 2002 23:12:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CthL-00034q-00 for idn-data@psg.com; Tue, 28 May 2002 20:00:27 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17CthL-00034i-00 for idn@ops.ietf.org; Tue, 28 May 2002 20:00:27 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17CthK-0008Ei-00 for ; Tue, 28 May 2002 20:00:26 -0700 Date: Wed, 29 May 2002 03:00:26 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020529030026.GG24925@nicemice.net> Reply-To: IETF idn working group References: <3CF24C00.3186F15F@trab.se> <13839118.1022523536@localhost> <3CF24C00.3186F15F@trab.se> <20020529014828.GD24925@nicemice.net> <3CF43A4B.607B274D@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF43A4B.607B274D@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > > As far as I know, no use for the 8th bit has ever been standardized. > > The standardized usage is local interpretation. Any usage is > compliant. I'll agree that any usage is compliant, but by definition "local interpretation" is not "standardized". By the way, using the 8th bit is risky, because the DNS spec is very unclear (if not downright silent) about how DNS servers compare octets with the 8th bit set. > > IDNA effectively says that the 8th bit is not to be used for > > internationalization, at least not for the time being. It's still > > available for other purposes (like non-textual domain names). > > These can still be supported, but they can't be run through the > converter. Right. IDNA requirements do not apply to non-text labels, because: Throughout this document the term "label" is shorthand for "text label", and "every label" means "every text label". (Section 2.) AMC From owner-idn@ops.ietf.org Tue May 28 23:57:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09153 for ; Tue, 28 May 2002 23:57:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CuO2-0004al-00 for idn-data@psg.com; Tue, 28 May 2002 20:44:34 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17CuO1-0004af-00 for idn@ops.ietf.org; Tue, 28 May 2002 20:44:33 -0700 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g4T3iUOI072447 for ; Wed, 29 May 2002 13:44:30 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200205290344.g4T3iUOI072447@drugs.dv.isc.org> To: IETF idn working group From: Mark.Andrews@isc.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt In-reply-to: Your message of "Wed, 29 May 2002 03:00:26 GMT." <20020529030026.GG24925@nicemice.net> Date: Wed, 29 May 2002 13:44:30 +1000 Sender: owner-idn@ops.ietf.org Precedence: bulk > "Eric A. Hall" wrote: > > > > As far as I know, no use for the 8th bit has ever been standardized. > > > > The standardized usage is local interpretation. Any usage is > > compliant. > > I'll agree that any usage is compliant, but by definition "local > interpretation" is not "standardized". By the way, using the 8th bit is > risky, because the DNS spec is very unclear (if not downright silent) > about how DNS servers compare octets with the 8th bit set. I don't know what's "unclear" or "silent" about the following from RFC 1035. Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. > > > > IDNA effectively says that the 8th bit is not to be used for > > > internationalization, at least not for the time being. It's still > > > available for other purposes (like non-textual domain names). > > > > These can still be supported, but they can't be run through the > > converter. > > Right. IDNA requirements do not apply to non-text labels, because: > > Throughout this document the term "label" is shorthand for "text > label", and "every label" means "every text label". > > (Section 2.) > > AMC > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Wed May 29 00:36:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09565 for ; Wed, 29 May 2002 00:36:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Cuzt-00060i-00 for idn-data@psg.com; Tue, 28 May 2002 21:23:41 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Cuzs-00060c-00 for idn@ops.ietf.org; Tue, 28 May 2002 21:23:41 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Cuzs-0000CK-00 for ; Tue, 28 May 2002 21:23:40 -0700 Date: Wed, 29 May 2002 04:23:40 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020529042339.GA382@nicemice.net> Reply-To: IETF idn working group References: <20020529030026.GG24925@nicemice.net> <200205290344.g4T3iUOI072447@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205290344.g4T3iUOI072447@drugs.dv.isc.org> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org wrote: > I don't know what's "unclear" or "silent" about the following > from RFC 1035. > > Although labels can contain any 8 bit values in octets that make up > a label, it is strongly recommended that labels follow the preferred > syntax described elsewhere in this memo, which is compatible with > existing host naming conventions. Name servers and resolvers must > compare labels in a case-insensitive manner (i.e., A=a), assuming > ASCII with zero parity. Non-alphabetic codes must match exactly. How do I "compare labels assuming ASCII with zero parity" when the input strings are not ASCII or don't have zero parity? If I can really assume zero parity, then I can ignore the 8th bit completely and compare only the bottom 7 bits. On the other hand, "match exactly" suggests that I should require the 8th bit to match too. But even then, among the codes 128..255, which are non-alphabetic? I don't know, but I'm required to do a case-insensitive comparison, so I'm screwed. Is that unclear enough for you? :) AMC From owner-idn@ops.ietf.org Wed May 29 00:58:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09920 for ; Wed, 29 May 2002 00:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CvOD-0006yV-00 for idn-data@psg.com; Tue, 28 May 2002 21:48:49 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CvOC-0006yP-00 for idn@ops.ietf.org; Tue, 28 May 2002 21:48:49 -0700 Received: from localhost (lsb@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g4T4mdC05682; Wed, 29 May 2002 13:48:39 +0900 Date: Wed, 29 May 2002 13:48:39 +0900 (KST) From: To: James Seng cc: idn@ops.ietf.org Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) In-Reply-To: <00d501c206aa$2f150970$8000a8c0@JAMESSONYVAIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk What if proper and stable implementation of legacy encodings in IDNA is not a tangilbe object due to their frequent updates/additions ? stringprep/nameprep added some code prohibiting rules wrt UCS versioning. And IDNA mentioned about legacy-2-unicode conversions necessary in major user environments. legacy versioning and UCS versioning is similar and interdependant issues that affect IDN security. Soobok Lee On Wed, 29 May 2002, James Seng wrote: > Lee, > > I repeat: > > legacy encoding evolves -- yes; but each one is tagged properly. > > Implementation which does not handle legacy encoding properly is an > implementation problem, not a protocol one. Evolving encoding standards is > not an issue. > > By all means twist the arguments round in circle, in your usual style. This > will be my last email on this thread. > > -James Seng > > > ----- Original Message ----- > > From: "James Seng" > > > > > No. The problem you describe, ie the improper handling of legacy > encoding is > > > an implementation issue, not protocol one. > > > > If legacy encodings are incorporated into any IDNA libraries, > > There arise legacy encoding versioning problems, regardles of whether > > the legacy encoding implementations were correct or not at that time > of first deployment. > > > > In summary, the issue is that: How can we build IDNA tower on the ground > > of moving legacy encodings ? Is it still implementation issue? > > In Sanfrancisco and Tokyo, every building should be well architectured > > against any earthquakes and 'soften' land. > > > > Soobok Lee > > > > > > > > Don't confuse the two. > > > > > > -James Seng > > > > > > > Soobok Lee > > > > > > > > ----- Original Message ----- > > > > From: "James Seng" > > > > To: "Soobok Lee" ; > > > > Sent: Wednesday, May 29, 2002 8:57 AM > > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > > > > If the problem is with the implementation, we fix the > implementation, > > > not > > > > > the protocol. We have similar arguments before. > > > > > > > > > > -James Seng > > > > > > > > > > ----- Original Message ----- > > > > > From: "Soobok Lee" > > > > > To: > > > > > Sent: Wednesday, May 29, 2002 1:14 AM > > > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > > > > > > > The big problem lies in that such bad and loose versioning > practice is > > > > > *everywhere*. > > > > > > And precise and correct legacy-code versioning requires that > > > > > "code-range&version" checking routines > > > > > > should be inserted in every application. And such checking > routines > > > > > themselves also should be > > > > > > versioned because legacy encodings are ever evolving. Both > objectives > > > > > requires upgrading all existing > > > > > > i18n applications, but that may be not feasible, by the same > reason > > > why > > > > > IDNA is preferred over UTF8 approach > > > > > > in this WG. > > > > > > > > > > > > For example, let's assume future Outlook Express 7.0 will fix the > bug > > > by > > > > > introducing > > > > > > new mime charset name "KS_C_5601-1992" . The sender posts an email > > > message > > > > > in KS_C_5601-1992 > > > > > > to the recipient who uses Outlook Express 6.0 which knows only > > > > > "KS_C_5601-1987". > > > > > > What will happen? maybe, fallback to iso8859-1 or default locale. > > > > > > direct-charset-negotiation between the sender/recipient's email > > > clients > > > > > are not possible. > > > > > > > > > > > > A XML application server receives a XML request encoded in new > > > > > KS_C_5601_1992, but the server applications > > > > > > don't know the new charset. what happens if the transaction was in > > > batch > > > > > mode? There may be no immediate/interactive error report to > > > > > > the orginator. > > > > > > > > > > > > That explains how much difficult it would be to introduce new > version > > > or > > > > > new legacy encoding into > > > > > > the IDN repertoires of supported encodings , if a certain version > of > > > > > IDN/IRI would have been widely deployed. > > > > > > > > > > > > Soobok Lee > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Roozbeh Pournader" > > > > > > > > > > > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > > > > > > > > > > > you can find the errornous mime-charset name : > "KS_C_5601-1987". > > > > > > > > Stupid and Wrong Versioning! > > > > > > > > > > > > > > Sure. But no protocol can fix broken software. Nag to developers > of > > > the > > > > > > > software to fix it. In this case, it is passing a character onto > > > wire, > > > > > > > which is not in the character set it is claiming it to be in. > > > > > > > > > > > > > > If a piece of software wants to work with KSC 5601:1992, and use > the > > > > > > > character you used, should know its mapping to Unicode. Simple. > > > > > > > > > > > > > > roozbeh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Wed May 29 00:59:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09938 for ; Wed, 29 May 2002 00:59:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CvRV-00078H-00 for idn-data@psg.com; Tue, 28 May 2002 21:52:13 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17CvRU-00078A-00 for idn@ops.ietf.org; Tue, 28 May 2002 21:52:13 -0700 Received: from localhost (lsb@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g4T4q4P05713 for ; Wed, 29 May 2002 13:52:04 +0900 Date: Wed, 29 May 2002 13:52:04 +0900 (KST) From: Soobok Lee To: idn@ops.ietf.org Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk What if proper and stable implementation of legacy encodings in IDNA is not a tangilbe object due to their frequent updates/additions ? stringprep/nameprep added some code prohibiting rules wrt UCS versioning. And IDNA mentioned about legacy-2-unicode conversions necessary in major user environments. legacy versioning and UCS versioning is similar and interdependant issues that affect IDN security. Soobok Lee On Wed, 29 May 2002, James Seng wrote: > Lee, > > I repeat: > > legacy encoding evolves -- yes; but each one is tagged properly. > > Implementation which does not handle legacy encoding properly is an > implementation problem, not a protocol one. Evolving encoding standards is > not an issue. > > By all means twist the arguments round in circle, in your usual style. This > will be my last email on this thread. > > -James Seng > > > ----- Original Message ----- > > From: "James Seng" > > > > > No. The problem you describe, ie the improper handling of legacy > encoding is > > > an implementation issue, not protocol one. > > > > If legacy encodings are incorporated into any IDNA libraries, > > There arise legacy encoding versioning problems, regardles of whether > > the legacy encoding implementations were correct or not at that time > of first deployment. > > > > In summary, the issue is that: How can we build IDNA tower on the ground > > of moving legacy encodings ? Is it still implementation issue? > > In Sanfrancisco and Tokyo, every building should be well architectured > > against any earthquakes and 'soften' land. > > > > Soobok Lee > > > > > > > > Don't confuse the two. > > > > > > -James Seng > > > > > > > Soobok Lee > > > > > > > > ----- Original Message ----- > > > > From: "James Seng" > > > > To: "Soobok Lee" ; > > > > Sent: Wednesday, May 29, 2002 8:57 AM > > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > > > > If the problem is with the implementation, we fix the > implementation, > > > not > > > > > the protocol. We have similar arguments before. > > > > > > > > > > -James Seng > > > > > > > > > > ----- Original Message ----- > > > > > From: "Soobok Lee" > > > > > To: > > > > > Sent: Wednesday, May 29, 2002 1:14 AM > > > > > Subject: Re: [idn] Re: Legacy charset conversion in > > > > > draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > > > > > > > > > > > > > The big problem lies in that such bad and loose versioning > practice is > > > > > *everywhere*. > > > > > > And precise and correct legacy-code versioning requires that > > > > > "code-range&version" checking routines > > > > > > should be inserted in every application. And such checking > routines > > > > > themselves also should be > > > > > > versioned because legacy encodings are ever evolving. Both > objectives > > > > > requires upgrading all existing > > > > > > i18n applications, but that may be not feasible, by the same > reason > > > why > > > > > IDNA is preferred over UTF8 approach > > > > > > in this WG. > > > > > > > > > > > > For example, let's assume future Outlook Express 7.0 will fix the > bug > > > by > > > > > introducing > > > > > > new mime charset name "KS_C_5601-1992" . The sender posts an email > > > message > > > > > in KS_C_5601-1992 > > > > > > to the recipient who uses Outlook Express 6.0 which knows only > > > > > "KS_C_5601-1987". > > > > > > What will happen? maybe, fallback to iso8859-1 or default locale. > > > > > > direct-charset-negotiation between the sender/recipient's email > > > clients > > > > > are not possible. > > > > > > > > > > > > A XML application server receives a XML request encoded in new > > > > > KS_C_5601_1992, but the server applications > > > > > > don't know the new charset. what happens if the transaction was in > > > batch > > > > > mode? There may be no immediate/interactive error report to > > > > > > the orginator. > > > > > > > > > > > > That explains how much difficult it would be to introduce new > version > > > or > > > > > new legacy encoding into > > > > > > the IDN repertoires of supported encodings , if a certain version > of > > > > > IDN/IRI would have been widely deployed. > > > > > > > > > > > > Soobok Lee > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Roozbeh Pournader" > > > > > > > > > > > > > On Wed, 29 May 2002, Soobok Lee wrote: > > > > > > > > > > > > > > > you can find the errornous mime-charset name : > "KS_C_5601-1987". > > > > > > > > Stupid and Wrong Versioning! > > > > > > > > > > > > > > Sure. But no protocol can fix broken software. Nag to developers > of > > > the > > > > > > > software to fix it. In this case, it is passing a character onto > > > wire, > > > > > > > which is not in the character set it is claiming it to be in. > > > > > > > > > > > > > > If a piece of software wants to work with KSC 5601:1992, and use > the > > > > > > > character you used, should know its mapping to Unicode. Simple. > > > > > > > > > > > > > > roozbeh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Wed May 29 01:16:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10115 for ; Wed, 29 May 2002 01:16:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CvjZ-0007ut-00 for idn-data@psg.com; Tue, 28 May 2002 22:10:53 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17CvjX-0007un-00 for idn@ops.ietf.org; Tue, 28 May 2002 22:10:52 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g4T5AnOI078121 for ; Wed, 29 May 2002 15:10:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200205290510.g4T5AnOI078121@drugs.dv.isc.org> To: IETF idn working group From: Mark.Andrews@isc.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt In-reply-to: Your message of "Wed, 29 May 2002 04:23:40 GMT." <20020529042339.GA382@nicemice.net> Date: Wed, 29 May 2002 15:10:49 +1000 Sender: owner-idn@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org wrote: > > > I don't know what's "unclear" or "silent" about the following > > from RFC 1035. > > > > Although labels can contain any 8 bit values in octets that make up > > a label, it is strongly recommended that labels follow the preferred > > syntax described elsewhere in this memo, which is compatible with > > existing host naming conventions. Name servers and resolvers must > > compare labels in a case-insensitive manner (i.e., A=a), assuming > > ASCII with zero parity. Non-alphabetic codes must match exactly. > > How do I "compare labels assuming ASCII with zero parity" when the input > strings are not ASCII or don't have zero parity? If I can really assume > zero parity, then I can ignore the 8th bit completely and compare only > the bottom 7 bits. On the other hand, "match exactly" suggests that I > should require the 8th bit to match too. But even then, among the codes > 128..255, which are non-alphabetic? I don't know, but I'm required to > do a case-insensitive comparison, so I'm screwed. > > Is that unclear enough for you? :) > > AMC The alphabetic characters in this context are 0x41-0x5a and 0x61-0x7a (zero parity ASCII A-Z, a-z). All others are compared exactly. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Wed May 29 01:29:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10342 for ; Wed, 29 May 2002 01:29:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CvvT-0008MT-00 for idn-data@psg.com; Tue, 28 May 2002 22:23:11 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17CvvS-0008MN-00 for idn@ops.ietf.org; Tue, 28 May 2002 22:23:10 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94098 for idn@ops.ietf.org; Wed, 29 May 2002 00:23:16 -0500 Message-ID: <3CF465BB.9000902@ehsco.com> Date: Wed, 29 May 2002 00:23:07 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020529030026.GG24925@nicemice.net> <200205290344.g4T3iUOI072447@drugs.dv.isc.org> <20020529042339.GA382@nicemice.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: >Mark.Andrews@isc.org wrote: > >> I don't know what's "unclear" or "silent" about the following >> from RFC 1035. >> >>Although labels can contain any 8 bit values in octets that make up >>a label, it is strongly recommended that labels follow the preferred >>syntax described elsewhere in this memo, which is compatible with >>existing host naming conventions. Name servers and resolvers must >>compare labels in a case-insensitive manner (i.e., A=a), assuming >>ASCII with zero parity. Non-alphabetic codes must match exactly. >How do I "compare labels assuming ASCII with zero parity" when the input >strings are not ASCII or don't have zero parity? If I can really assume >zero parity, then I can ignore the 8th bit completely and compare only >the bottom 7 bits. On the other hand, "match exactly" suggests that I >should require the 8th bit to match too. But even then, among the codes >128..255, which are non-alphabetic? I don't know, but I'm required to >do a case-insensitive comparison, so I'm screwed. > >Is that unclear enough for you? :) You are the only one that is unclear on it. 0x80-0xFF must match exactly. Any usage of any of these character codes is allowed and legal, but the meaning of those codes only has context within the application that uses the data. As far as STD13 is concerned, these aren't necessarily even characters, they are just eight-bit codes. From owner-idn@ops.ietf.org Wed May 29 01:42:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10588 for ; Wed, 29 May 2002 01:42:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Cw5z-0008o3-00 for idn-data@psg.com; Tue, 28 May 2002 22:34:03 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #1) id 17Cw5y-0008nx-00 for idn@ops.ietf.org; Tue, 28 May 2002 22:34:02 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GWUY4P00.H3M; Wed, 29 May 2002 01:34:01 -0400 Message-ID: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: , "James Seng" Cc: References: Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Tue, 28 May 2002 22:32:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee wrote: > What if proper and stable implementation of legacy encodings in > IDNA is not a tangilbe object due to their frequent updates/ > additions ? How "frequent" are updates to legacy encodings, or updates to the mapping tables between legacy encodings and Unicode? As for additions, they shouldn't cause a problem anyway, because they don't break existing legacy-to-Unicode mappings. An often-mentioned case of adding to a legacy encoding was when Microsoft retrofitted U+20AC EURO SIGN onto their Windows code pages (mostly at previously unassigned code position 0x80). The only people who suffered at all were the ones who thought "unassigned" somehow meant that they should map 0x80 to U+0080. Everyone else made it just fine. -Doug Ewell Fullerton, California (would prefer to receive only one copy of these messages) From owner-idn@ops.ietf.org Wed May 29 05:54:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09245 for ; Wed, 29 May 2002 05:54:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Czmg-000F02-00 for idn-data@psg.com; Wed, 29 May 2002 02:30:22 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17Czme-000Ezw-00 for idn@ops.ietf.org; Wed, 29 May 2002 02:30:21 -0700 Received: from localhost (lsb@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g4T9UBs07641 for ; Wed, 29 May 2002 18:30:11 +0900 Date: Wed, 29 May 2002 18:30:06 +0900 (KST) From: Soobok Lee To: idn@ops.ietf.org Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) In-Reply-To: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, 28 May 2002, Doug Ewell wrote: > Soobok Lee wrote: > > > What if proper and stable implementation of legacy encodings in > > IDNA is not a tangilbe object due to their frequent updates/ > > additions ? > > How "frequent" are updates to legacy encodings, or updates to the > mapping tables between legacy encodings and Unicode? > FYI, I enclose the following tables from iconv library documentations. See Korean section below. About recent additions (1998,2002), you can visit http://www.xfree86.org/pipermail/i18n/2002-April/003209.html Soobok Lee =================================================================== .* New charsets (most from libiconv) . + Japanese EUC-JP (csEUCPkdFmtJapanese, EUC_JP, Extended_UNIX_Code_Packed_Format_for_Japanese); ISO-2022-JP (csISO2022JP); ISO-2022-JP-1; ISO-2022-JP-2 (csISO2022JP2); JIS_C6220-1969-ro (csISO14JISC6220ro, ISO646-JP, iso-ir-14, jp); JIS_X0201 (csHalfWidthKatakana, JIS0201, JISX0201-1976, JISX0201.1976-0, X0201); JIS_X0208 (csISO87JISX0208, ISO-IR-87, JIS0208, JIS_X0208.1983-0, JIS_X0208.1983-1, JIS_X0208-1990-0, JIS_X0208.1983-1, X0208); JIS_X0212 (csISO159JISX02121990, ISO-IR-159, JIS0212, JIS_X0212.1990-0, JIS_X0212-1990, X0212); SJIS (csShiftJIS, MS_KANJI, SHIFT-JIS). . + Chinese BIG5 (BIG-5, BIG-FIVE, BIGFIVE, CN-BIG5 csBig5); EUC-CN (CN-GB, csGB2312, EUC_CN, GB2312); EUC-TW (csEUCTW, EUC_TW); HZ (HZ-GB-2312); ISO-2022-CN (csISO2022CN); ISO-2022-CN-EXT; GB_1988-80 (cn, csISO57GB1988, ISO646-CN, iso-ir-57); GB_2312-80 (CHINESE, csISO58GB231280, GB2312.1980-0, ISO-IR-58); ISO-IR-165 (CN-GB-ISOIR165). . + Korean JOHAB (CP1361); EUC-KR (csEUCKR, EUC_KR); GBK (CP936); ISO-2022-KR (csISO2022KR); KSC_5601 (CP949, csKSC56011987, ISO-IR-149, KOREAN, KSC5601.1987-0, KS_C_5601-1987, KS_C_5601-1989, KSX1001:1992). . + Vietnamese (independently of libiconv) TCVN; VIQR; VISCII; VNI; VPS. . + Other languages ARMSCII-8; Georgian-Academy; Georgian-PS; WINDOWS-874 (CP874); MuleLao-1; CP1133 (IBM-CP1133); CP1258 (WINDOWS-1258); TIS-620 (ISO-IR-166, TIS620, TIS620.2529-1, TIS620-0, TIS620.2533-0, TIS620.2533-1). . + Apple specifics MacArabic; MacCentralEurope; MacCroatian; MacCyrillic; MacGreek; MacHebrew; MacIceland; MacRomania; MacThai; MacTurkish; MacUkraine . + Unicode JAVA; UCS-2-INTERNAL; UCS-2LE (UnicodeLITTLE); UCS-2-SWAPPED; UCS-4BE; UCS-4-INTERNAL; UCS-4LE; UCS-4-SWAPPED; UTF-16BE; UTF-16LE. . + Others CP932; CP949 (UHC); CP950; CP866 (866, csIBM866, IBM866). ISO-8859-16 (ISO-IR-226, ISO_8859-16:2000). . + Recode internal :libiconv: (:) [so option -x: avoids going through libiconv] .* New aliases (from libiconv) [list to be revised] csASCII (for ANSI_X3.4-1968); csHPRoman8 (for hp-roman8); csISOLatin1 (for ISO-8859-1); csISOLatin2 (for ISO-8859-2); csISOLatin3 (for ISO-8859-3); csISOLatin4 (for ISO-8859-4); csISOLatin5 (for ISO-8859-9); csISOLatin6 and ISO_8859-10:1992 (for ISO-8859-10); csISOLatinArabic (for ISO-8859-6); csISOLatinCyrillic (for ISO-8859-5); csISOLatinGreek (for ISO-8859-7); csISOLatinHebrew (for ISO-8859-8); csKOI8R (for KOI8-R); csPC850Multilingual (for IBM850); csUCS4 (for ISO-10646-UCS-4); csUnicode, csUnicode11, UCS-2BE, UnicodeBIG (for ISO-10646-UCS-2); csUnicode11UTF7 (for UNICODE-1-1-UTF-7); csVISCII and VISCII1.1-1 (for VISCII); ISO-IR-179 (for ISO-8859-13); csMacintosh and MacRoman (for macintosh); TCVN5712-1, TCVN5712-1:1993 and TCVN-5712 (for TCVN). .* New surfaces tree (experimental). * Version 3.5 - Francois Pinard, 1999-05. .* Incompatible changes . + A double dot `..' should now be used instead of a colon `:'. . + Option --force (-f) is needed to pursue recoding despite errors. . + There is no more quoting for special characters within charsets names. . + Auto check (`-a') and popen (`-o') options have been withdrawn. . + Some charsets and aliases were deleted, see `Charsets & aliases' below. .* Extended features . + Program messages are available in localised form for many languages. . + Long character names are available in French, if LANGUAGE is set to `fr'. . + A new request syntax allows for recode chaining, and for surfaces. . + Option --header-file (-h) accepts a language parameter, and Perl is new. . + Full charset listings now show the UCS-2 value for characters. . + Option --known=PAIRS (-k) also accepts octal and hexadecimal numbers. . + Option --list (-l) better sorts charsets and aliases, also fully written. . + Charset `RFC1345' implements mnemonic+ascii+38, and is now reversible. . + HTML is not limited anymore to Latin-1, HTML 4.0 entities are supported. .* New features . + Euro support. . + Updated RFC 1345 set of tables, from Keld Simonsen. . + Some African charsets and transliterated forms. . + Conversions for ISO 10646 and Unicode. . + Combining or explosion of UCS-2 diacriticized characters and ligatures. . + Implementation of surfaces, see `Surfaces & aliases' below. . + Mixed mode for recoding only comments and strings in C sources or PO files. . + A stand-alone recoding library gets installed, often as a shared library. . + Option --find-subsets (-T) lists charsets which are subsets of another. . + The library may generate testing data, and study character frequencies. .* Charsets & aliases . + New ISO 10646 and Unicode charsets . - combined-UCS-2: pseudo-charset. . - count-characters: pseudo-charset. . - dump-with-names: pseudo-charset. . - ISO-10646-UCS-2 (UNICODE-1-1, BMP, rune, u2). . - ISO-10646-UCS-4 (10646, ISO-10646, UCS-4, u4). . - UNICODE-1-1-UTF-7 (TF-7, u7). . - UTF-8 (UTF-2, UTF-FSS, FSS_UTF, TF-8, u8). . - UTF-16 (Unicode, TF-16, u6). . + RFC 1345.bis matters . - Deleted charsets dk-us, us-dk (because of &duplicate which `recode' does not handle yet). . - New charsets baltic (alias is iso-ir-179); CP1250 (1250, ms-ee, windows-1250); CP1251 (1251, ms-cyrl, windows-1251); CP1252 (1252, ms-ansi, windows-1252); CP1253 (1253, ms-greek, windows-1253); CP1254 (1254, ms-turk, windows-1254); CP1255 (1255, ms-hebr, windows-1255); CP1256 (1256, ms-arab, windows-1256); CP1257 (1257, WinBaltRim, windows-1257); CWI (CWI-2, cp-hu); EBCDIC-IS-FRISS (friss); GOST_19768-87 with aliases of previous GOST_19768-74; IBM256 (256, CP256, EBCDIC-INT1); IBM875 (875, CP875, EBCDIC-Greek); IBM1004 (1004, CP1004, os2latin1); IBM1047 (1047, CP1047); ISO-8859-13 (ISO_8859-13:1998, iso-baltic, iso-ir-179a, l7, latin7); ISO-8859-14 (ISO_8859-14:1998, iso-celtic, iso-ir-199, l8, latin8); ISO-8859-15 (ISO_8859-15:1998, iso-ir-203, l9, latin9); KOI-7; KOI-8 (GOST_19768-74); KOI8-R; KOI8-RU; KOI8-U; macintosh_ce (macce); mac-is; NeXTSTEP (next) yet previous `recode' had it outside RFC 1345. . - Alias promoted to charset (with previous charset becoming alias) ISO-646.basic (with ISO-646.basic:1983); ISO-646.irv (ISO-646.irv:1983); ISO_5427-ext (ISO_5427:1981); ISO_5428 (ISO_5428:1980); ISO-8859-1 (ISO_8859-1:1987); ISO-8859-2 (ISO_8859-2:1987); ISO-8859-3 (ISO_8859-3:1988); ISO-8859-4 (ISO_8859-4:1988); ISO-8859-5 (ISO_8859-5:1988); ISO-8859-6 (ISO_8859-6:1987); ISO-8859-7 (ISO_8859-7:1987); ISO-8859-8 (ISO_8859-8:1988); ISO-8859-9 (ISO_8859-9:1989); ISO-8859-10 (latin6); NC_NC00-10 (NC_NC00-10:81); sami (latin-lap). . - New aliases 037 (for charset IBM037); 038 (IBM038); 273 (IBM273); 274 (IBM274); 275 (IBM275); 278 (IBM278); 280 (IBM280); 281 (IBM281); 284 (IBM284); 285 (IBM285); 290 (IBM290); 297 (IBM297); 367 (ANSI_X3.4-1968); 420 (IBM420); 423 (IBM423); 424 (IBM424); 500, 500V1 (IBM500); 819 (ISO-8859-1); 864 (IBM864); 868 (IBM868); 870 (IBM870); 871 (IBM871); 880 (IBM880); 891 (IBM891); 903 (IBM903); 905 (IBM905); 912, CP912, IBM912 (ISO-8859-2); 918 (IBM918); 1026 (IBM1026); ECMA-113, ECMA-113:1986 (ECMA-Cyrillic); GOST_19768-74 (KOI8); ISO_8859-N (ISO-8859-N) for N = 1 through 10 and 13 through 15; ISO_8859-10:1993 (ISO-8869-10); iso-ir-170 (INVARIANT); KOI8_L2 (CSN_369103); pclatin2, pcl2 (IBM852); SS636127 (SEN_850200_B). . + New African charsets AFRL1-101-BPI_OCIL (t-francais, t-fra); AFRFUL-102-BPI_OCIL (bambara, bra, ewondo, fulfulde); AFRFUL-103-BPI_OCIL (t-bambara, t-bra, t-ewondo, t-fulfulde); AFRLIN-104-BPI_OCIL (lingala, lin, sango, wolof); AFRLIN-105-BPI_OCIL (t-lingala, t-lin, t-sango, t-wolof). . + Extra miscellaneous charsets KEYBCS2 (Kamenicky); CORK (T1); KOI-8_CS2. . + New HTML pseudo-charsets HTML_1.1 (h1); HTML_2.0 (RFC 1866, 1866, h2); HTML-i18n (RFC 2070); HTML_3.2 (h3) reimplemented; HTML_4.0 (h4, HTML, h); deleted aliases HTF, 8859, ISO 8859, Entities, SGML, WWW, w3. .* Surfaces & aliases Base64 (64, b64); Quoted-Printable (qp, Quote-Printable); 21-Permutation (swabytes); 4321-Permutation; CR; CR-LF (cl); Decimal-1 (d, d1); Decimal-2 (d2), Decimal-4 (d4); Hexadecimal-1 (x, x1); Hexadecimal-2 (x2); Hexadecimal-4 (x4); Octal-1 (o, o1); Octal-2 (o2); Octal-4 (o4). data; test7; test8; test15; test16. From owner-idn@ops.ietf.org Wed May 29 05:55:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09290 for ; Wed, 29 May 2002 05:55:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17CzvQ-000FBM-00 for idn-data@psg.com; Wed, 29 May 2002 02:39:24 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17CzvP-000FBD-00 for idn@ops.ietf.org; Wed, 29 May 2002 02:39:23 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4T9dGWa019243; Wed, 29 May 2002 11:39:17 +0200 To: Cc: , "James Seng" Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> From: Simon Josefsson Date: Wed, 29 May 2002 11:39:16 +0200 In-Reply-To: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> ("Doug Ewell"'s message of "Tue, 28 May 2002 22:32:20 -0700") Message-ID: Lines: 23 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk "Doug Ewell" writes: > Soobok Lee wrote: > >> What if proper and stable implementation of legacy encodings in >> IDNA is not a tangilbe object due to their frequent updates/ >> additions ? > > How "frequent" are updates to legacy encodings, or updates to the > mapping tables between legacy encodings and Unicode? The problem seem to be that there are no official mapping tables between legacy encodings and Unicode. So each implementator can in theory chose whatever mapping tables she wishes, and change it every other day as well. In practice, implementator will pick a table they find on the net. Question is if this is sufficient or not, are all mapping tables "on the net" consistent and non-evolving? > -Doug Ewell > Fullerton, California > (would prefer to receive only one copy of these messages) Setting "Mail-Copies-To: never" helps. From owner-idn@ops.ietf.org Wed May 29 06:00:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09455 for ; Wed, 29 May 2002 06:00:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D06q-000FQr-00 for idn-data@psg.com; Wed, 29 May 2002 02:51:12 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17D06p-000FQl-00 for idn@ops.ietf.org; Wed, 29 May 2002 02:51:11 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4T9p9Wa019344 for ; Wed, 29 May 2002 11:51:10 +0200 To: IETF idn working group Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> <20020528221203.GC24925@nicemice.net> From: Simon Josefsson Date: Wed, 29 May 2002 11:51:09 +0200 In-Reply-To: <20020528221203.GC24925@nicemice.net> ("Adam M. Costello"'s message of "Tue, 28 May 2002 22:12:03 +0000") Message-ID: Lines: 34 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > I have no objection. We might be able to compact it a bit: > > Domain names are used by users to identify and connect to Internet > servers. The security of the Internet is compromised if a user > entering a single internationalized name is connected to different > servers based on different interpretations of the internationalized > domain name. > > When systems use local character sets other than ASCII and Unicode, > this specification leaves the transcoding problem up to the > application. If applications implement different transcoding rules, > they could interpret the same name differently and contact different > servers. This problem is not solved by security protocols like TLS > that do not take local character sets into account. > > [I didn't change the first paragraph except to remove the last > sentence.] > > Simon, does that still say everything you want it to? Sure. Before the last sentence it could be useful to also add something like: "Furthermore, if a single application uses one mapping table in one version, and a subsequent version of the application uses a modified mapping table, different interpretations of the same internationalized text string may be possible even within the same application which has security implications." Perhaps it didn't come out very clearly, I was trying to explain that if mapping tables are modified over time (in a way that Unicode CK normalization does not cancel out) it will be exploitable. From owner-idn@ops.ietf.org Wed May 29 06:42:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10010 for ; Wed, 29 May 2002 06:42:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D0kw-000GMT-00 for idn-data@psg.com; Wed, 29 May 2002 03:32:38 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17D0kv-000GMN-00 for idn@ops.ietf.org; Wed, 29 May 2002 03:32:37 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4TAWXWa019585; Wed, 29 May 2002 12:32:34 +0200 To: Roozbeh Pournader Cc: IDN Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: From: Simon Josefsson Date: Wed, 29 May 2002 12:32:33 +0200 In-Reply-To: (Roozbeh Pournader's message of "Tue, 28 May 2002 19:54:26 +0430 (IRST)") Message-ID: Lines: 70 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Roozbeh Pournader writes: >> CP437 0xE1: U+03B2 / U+00DF: ? >> CP437 0xEE: U+03B5 / U+2208: ? > > As far as I know, all existing CP437 tables map those to SMALL SHARP S > (U+00DF) and SMALL EPSILON (U+03B5) and not SMALL BETA or ELEMENT OF. > I just checked everywhere I could, this is the list: > > http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT > http://microsoft.com/globaldev/reference/oem/437.htm > http://www.kostis.net/charsets/cp437.htm > > Can you point me to anywhere disagreeing? No. I was thinking of mapping from Unicode into legacy charsets here, which probably wasn't clear (I probably hadn't realized I made that assumption when I wrote that message). To understand why that is ever relevant, I think it is useful to summarize the security related problems with internationalized text identifiers in applications. We have only talked about the first two yet. 1) Internationalized text strings extend the set of possible characters to use in identifiers. Traditionally a-z0-9- is such a small set that users can separate two elements of the set easily ("oh! mybank.com is not the same string as mubank.com, I must be under attack!"). With Unicode, users cannot easily do this anymore. I think the point of CK normalization is to mitigate this problem, but the basic problem will still be there. Users must understand that different but similar looking characters are different. This problem cannot be solved entirely, and people will exploit this fact. 2) On systems with non-ASCII non-Unicode charsets, applications need to transcode strings entered using the system charset into Unicode before applying IDN stuff. If different applications use different mapping tables, or if those mapping tables change, in a way that CK normalization does not cancel out, there will be additional attacks. 3) On systems with non-ASCII non-Unicode charsets in security applications, the system will have to convert Unicode in IDNA into system charset before sending it to those security applications. Here is the problem I was referring to above. Consider a user entering a string in the browser containing CP437 0xE1, it is IDNAlized within the resolver and the user connects to the server, receives (for security purposes, in a TLS stream for instance), e.g., a certificate containing an IDNA. If IDNA is not supposed to force the entire system to switch to Unicode, the application will have to convert the IDNA string into the system charset to display it to the user. So it converts U+03B2 into CP437 0xE1 and displays it, the user compares the strings (possibly even by studying the byte sequence to be sure, if a system charset with similar looking symbols are used) and can verify it. However, it is not unreasonable for the application to convert U+00DF into CP437 0xE1 as well. So the attack will only have to register the domain using U+00DF instead of U+03B2 in order to mount an attack. Ok, I admit that the case in 3) can be solved in two ways. Either the user is shown the IDNA strings and is allowed to compare them. Or the system is upgraded to use Unicode in all involved applications, including the display engine. My point is that this attack isn't discussed in the security considerations. Also, the two solutions aren't very good, IMHO, since the first one will generate a bad user experience and the second will take years to implement. And bad solutions are only implemented badly or not at all, so this will most likely generate security incidents. Which for prudence should at least be mentioned in security considerations. From owner-idn@ops.ietf.org Wed May 29 07:40:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11499 for ; Wed, 29 May 2002 07:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D1i2-000Hg5-00 for idn-data@psg.com; Wed, 29 May 2002 04:33:42 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17D1i1-000Hfz-00 for idn@ops.ietf.org; Wed, 29 May 2002 04:33:41 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11031; Wed, 29 May 2002 07:32:46 -0400 (EDT) Message-Id: <200205291132.HAA11031@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-idna-09.txt Date: Wed, 29 May 2002 07:32:45 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Domain Names In Applications (IDNA) Author(s) : P. Faltstrom, P. Hoffman, A. Costello Filename : draft-ietf-idn-idna-09.txt Pages : Date : 28-May-02 Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called IDNA for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using the same octets used in so-called host names today. This representation allows IDNs to be introduced with minimal changes to the existing DNS infrastructure. IDNA is only meant for processing domain names, not free text A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-idna-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-idna-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Wed May 29 10:59:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20121 for ; Wed, 29 May 2002 10:59:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D4cE-000Lh9-00 for idn-data@psg.com; Wed, 29 May 2002 07:39:54 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17D4cD-000Lh3-00 for idn@ops.ietf.org; Wed, 29 May 2002 07:39:53 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19580; Wed, 29 May 2002 10:39:28 -0400 (EDT) Message-Id: <200205291439.KAA19580@ietf.org> To: IETF-Announce: ; Cc: idn@ops.ietf.org From: The IESG Subject: [idn] Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 29 May 2002 10:39:28 -0400 Sender: owner-idn@ops.ietf.org Precedence: bulk The IESG has received a request from the Internationalized Domain Name Working Group to consider the following Internet-Drafts as Proposed Standards: o Internationalizing Domain Names In Applications (IDNA) o Nameprep: A Stringprep Profile for Internationalized Domain Names o Punycode: An encoding of Unocode for use with IDNA The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 6, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-08.txt http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-10.txt http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-02.txt From owner-idn@ops.ietf.org Wed May 29 11:20:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20988 for ; Wed, 29 May 2002 11:19:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D4wp-000M4R-00 for idn-data@psg.com; Wed, 29 May 2002 08:01:11 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17D4wo-000M4L-00 for idn@ops.ietf.org; Wed, 29 May 2002 08:01:10 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TF18J26223 for ; Wed, 29 May 2002 08:01:08 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3CF465BB.9000902@ehsco.com> References: <20020529030026.GG24925@nicemice.net> <200205290344.g4T3iUOI072447@drugs.dv.isc.org> <20020529042339.GA382@nicemice.net> <3CF465BB.9000902@ehsco.com> Date: Wed, 29 May 2002 07:52:11 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:23 AM -0500 5/29/02, Eric A. Hall wrote: >You are the only one that is unclear on it. 0x80-0xFF must match >exactly. Funny, that doesn't match what a DNS expert posted a little before you did; maybe there is more unclarity than you think. Further, neither your rules nor Mark's rules take into account the many encodings that don't reserve the octets used for ASCII. Think UTF-16. Or ISO-2022-JP. Or numerous others. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Wed May 29 11:41:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21661 for ; Wed, 29 May 2002 11:41:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D5SP-000Ml8-00 for idn-data@psg.com; Wed, 29 May 2002 08:33:49 -0700 Received: from smtprelay1.dc3.adelphia.net ([24.50.78.4]) by psg.com with esmtp (Exim 3.36 #1) id 17D5SO-000Ml2-00 for idn@ops.ietf.org; Wed, 29 May 2002 08:33:48 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay1.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GWVPWB00.00T for ; Wed, 29 May 2002 11:33:47 -0400 Message-ID: <007c01c20726$03e9c980$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: Subject: Fw: [idn] Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Date: Wed, 29 May 2002 08:32:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG wrote: > The IESG has received a request from the Internationalized Domain Name > Working Group to consider the following Internet-Drafts as Proposed > Standards: > > o Internationalizing Domain Names In Applications (IDNA) > Shouldn't that be idna-09, not idna-08? Four hours earlier I received a message that idna-09 was available, and I downloaded it. Is everything stable here? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Wed May 29 11:53:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22089 for ; Wed, 29 May 2002 11:53:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D5bx-000MxH-00 for idn-data@psg.com; Wed, 29 May 2002 08:43:41 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17D5bw-000MxB-00 for idn@ops.ietf.org; Wed, 29 May 2002 08:43:40 -0700 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04242; Wed, 29 May 2002 08:43:38 -0700 (PDT) Received: from odin.france.sun.com (esun1as-be.Central.Sun.COM [129.147.34.142]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g4TFhQ229424; Wed, 29 May 2002 17:43:29 +0200 (MEST) From: Erik Nordmark - Sun Microsystems Message-Id: <200205291543.g4TFhQ229424@odin.France.Sun.COM> Date: Wed, 29 May 2002 15:42:33 -0000 To: "Doug Ewell" , Subject: Re: Fw: [idn] Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Shouldn't that be idna-09, not idna-08? Four hours earlier I received a >message that idna-09 was available, and I downloaded it. Is everything >stable here? Yes, please review -09. The reason for this confusion is due to me requesting the last call last week and Paul fixing some typos and submitted -09 after I sent the request to the IETF secretariat. Erik From owner-idn@ops.ietf.org Wed May 29 12:02:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22476 for ; Wed, 29 May 2002 12:02:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D5ki-000N7o-00 for idn-data@psg.com; Wed, 29 May 2002 08:52:44 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17D5ki-000N7i-00 for idn@ops.ietf.org; Wed, 29 May 2002 08:52:44 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TFqcJ24757; Wed, 29 May 2002 08:52:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <007c01c20726$03e9c980$fa424244@anhmca.adelphia.net> References: <007c01c20726$03e9c980$fa424244@anhmca.adelphia.net> Date: Wed, 29 May 2002 08:52:34 -0700 To: "Doug Ewell" , From: Paul Hoffman / IMC Subject: Re: Fw: [idn] Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 8:32 AM -0700 5/29/02, Doug Ewell wrote: >Shouldn't that be idna-09, not idna-08? Four hours earlier I received a >message that idna-09 was available, and I downloaded it. Is everything >stable here? There were some editorial mistakes in -08 that didn't get noticed before Erik asked for the IETF last call. We made those fixes in -09. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Wed May 29 13:04:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25010 for ; Wed, 29 May 2002 13:04:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17D6jI-000OO2-00 for idn-data@psg.com; Wed, 29 May 2002 09:55:20 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17D6jG-000ONv-00 for idn@ops.ietf.org; Wed, 29 May 2002 09:55:18 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94181 for idn@ops.ietf.org; Wed, 29 May 2002 11:55:21 -0500 Message-ID: <3CF507CE.CB475551@ehsco.com> Date: Wed, 29 May 2002 11:54:38 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020529030026.GG24925@nicemice.net> <200205290344.g4T3iUOI072447@drugs.dv.isc.org> <20020529042339.GA382@nicemice.net> <3CF465BB.9000902@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At 12:23 AM -0500 5/29/02, Eric A. Hall wrote: > >You are the only one that is unclear on it. 0x80-0xFF must match > >exactly. > > Funny, that doesn't match what a DNS expert posted a little before > you did; maybe there is more unclarity than you think. There is no conflict between the answers. I responded to the earlier query regarding "using the 8th bit" while Mark responded to the "alphabetic characters" part of the followup query. The only unclarity remains to be in the IDNA camp, where it took seven drafts to figure out there was a difference between domain names and hostnames, and where there is continued misunderstanding on the basic premises underlying the use of domain names in general. > Further, neither your rules nor Mark's rules take into account the > many encodings that don't reserve the octets used for ASCII. Think > UTF-16. Or ISO-2022-JP. Or numerous others. What's your point? The DNS rules are pretty simple. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed May 29 18:45:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06138 for ; Wed, 29 May 2002 18:45:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DBw6-0004z4-00 for idn-data@psg.com; Wed, 29 May 2002 15:28:54 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17DBw5-0004yy-00 for idn@ops.ietf.org; Wed, 29 May 2002 15:28:53 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g4TMSjOI078333; Thu, 30 May 2002 08:28:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200205292228.g4TMSjOI078333@drugs.dv.isc.org> To: Paul Hoffman / IMC Cc: idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt In-reply-to: Your message of "Wed, 29 May 2002 07:52:11 MST." Date: Thu, 30 May 2002 08:28:45 +1000 Sender: owner-idn@ops.ietf.org Precedence: bulk > At 12:23 AM -0500 5/29/02, Eric A. Hall wrote: > >You are the only one that is unclear on it. 0x80-0xFF must match > >exactly. > > Funny, that doesn't match what a DNS expert posted a little before > you did; maybe there is more unclarity than you think. > > Further, neither your rules nor Mark's rules take into account the > many encodings that don't reserve the octets used for ASCII. Think > UTF-16. Or ISO-2022-JP. Or numerous others. > > --Paul Hoffman, Director > --Internet Mail Consortium > The rules are how you compare labels as "they appear on the wire". If you are using a local encoding that does not reserve the those octets to ASCII (like one of the EBCIDCs) you map to ASCII then compare. IBM has been doing that for years for their main frames. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Wed May 29 20:10:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08265 for ; Wed, 29 May 2002 20:10:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DDM5-0006us-00 for idn-data@psg.com; Wed, 29 May 2002 16:59:49 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17DDM4-0006um-00 for idn@ops.ietf.org; Wed, 29 May 2002 16:59:48 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17DDM3-0004N9-00 for ; Wed, 29 May 2002 16:59:47 -0700 Date: Wed, 29 May 2002 23:59:47 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020529235947.GC382@nicemice.net> Reply-To: IETF idn working group References: <20020529030026.GG24925@nicemice.net> <200205290344.g4T3iUOI072447@drugs.dv.isc.org> <20020529042339.GA382@nicemice.net> <3CF465BB.9000902@ehsco.com> <20020529042339.GA382@nicemice.net> <200205290510.g4T5AnOI078121@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF465BB.9000902@ehsco.com> <200205290510.g4T5AnOI078121@drugs.dv.isc.org> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org wrote: > The alphabetic characters in this context are 0x41-0x5a and 0x61-0x7a > (zero parity ASCII A-Z, a-z). All others are compared exactly. That may be what the popular DNS implementations do, but I don't see RFC 1035 saying how to compare 0x80-0xFF. "Eric A. Hall" wrote: > You are the only one that is unclear on it. 0x80-0xFF must match > exactly. I'm not the only one. Here's an excerpt from a message by John Klensin: http://www.ietf.org/mail-archive/ietf/Current/msg15742.html RFC1035> For all parts of the DNS that are part of the official RFC1035> protocol, all comparisons between character strings (e.g., RFC1035> labels, domain names, etc.) are done in a case-insensitive RFC1035> manner. At present, this rule is in force throughout the RFC1035> domain system without exception. John Klensin> To emphasize, that is "all parts" and "all comparisons", John Klensin> not "unless you happen to find the high bit turned on". John Klensin> An existing and conforming implementation has no way to do John Klensin> those required case-insensitive comparisons outside the John Klensin> ASCII range. Robert Elz> No, nor is it required to. John Klensin> There we probably disagree -- I suggest that the text is John Klensin> at least ambiguous and might require it. AMC From owner-idn@ops.ietf.org Thu May 30 02:46:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24365 for ; Thu, 30 May 2002 02:46:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DJPb-000GIY-00 for idn-data@psg.com; Wed, 29 May 2002 23:27:51 -0700 Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17DJPa-000GIS-00 for idn@ops.ietf.org; Wed, 29 May 2002 23:27:50 -0700 Received: from mailc.telia.se (localhost [127.0.0.1]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g4U6RmL00782 for ; Thu, 30 May 2002 08:27:48 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g4U6Rl100773 for ; Thu, 30 May 2002 08:27:47 +0200 (METDST) Message-ID: <3CF5C663.9D2EFC77@trab.se> Date: Thu, 30 May 2002 08:27:47 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: >> IDNA must NOT restrict current usage and DNS standards making it >> impossible to update the DNS standard later with a suitable defined >> handling of non-ASCII octet values! > >The door is left open for updates to DNS: > > If a signaling system which makes negotiation possible between old > and new DNS clients and servers is standardized in the future, the > encoding of the query in the DNS protocol itself can be changed from > ACE to something else, such as UTF-8. > >What we don't want to allow is untagged non-ASCII text in DNS messages, >because there is no standard for what it means or how it should be >compared. It is simple to standardise it. We just publish a short RFC defining how octet values with the 8th bit should be handled. There are already DNS servers supporting names in UTF-8 and other encodings. Why not standardise what encoding should be used? > >> IDNA is not an update of the DNS standard. > >IDNA is mainly orthogonal to the DNS standard, but it could be >considered an update in one small respect. RFCs 1034 and 1035 say: > > domain name comparisons for all present domain functions are done in > a case-insensitive manner, assuming an ASCII character set, and a > high order zero bit. > > Name servers and resolvers must compare labels in a case-insensitive > manner (i.e., A=a), assuming ASCII with zero parity. Yes ASCII characters must have zero parity! This is because DNS uses 8 bit octets, not 7bit ASCII. > >It seems pretty clear that the 8th bit is reserved for future use. >As far as I know, no use for the 8th bit has ever been standardized. Then it is high time it was standardised. Let's standardise it to be UTF-8 as that is highly compatible with current usage. >IDNA effectively says that the 8th bit is not to be used for >internationalization, at least not for the time being. It's still >available for other purposes (like non-textual domain names). That is bad, the 8th bit is already used for internationalisation! Dan From owner-idn@ops.ietf.org Thu May 30 04:54:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26764 for ; Thu, 30 May 2002 04:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DLWO-000Imp-00 for idn-data@psg.com; Thu, 30 May 2002 01:43:00 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17DLWO-000Imj-00 for idn@ops.ietf.org; Thu, 30 May 2002 01:43:00 -0700 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22704 for ; Thu, 30 May 2002 01:42:58 -0700 (PDT) Received: from odin.france.sun.com (euroapp.Holland.Sun.COM [129.159.197.58]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g4U8gl209938 for ; Thu, 30 May 2002 10:42:50 +0200 (MEST) From: Erik Nordmark - Sun Microsystems Message-Id: <200205300842.g4U8gl209938@odin.France.Sun.COM> Date: Thu, 30 May 2002 08:41:50 -0000 To: Reply-To: Subject: [idn] :Re: Last Call: Preparation of Internationalized Strings ('strin Sender: owner-idn@ops.ietf.org Precedence: bulk gprep') to Proposed Standard (Fwd) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Forwarded with permission. >----------------Begin Forwarded Message----------------< Date: Mon, 27 May 2002 09:52:09 +0100 (BST) From: "Charles Lindsey" Subject: Re: Last Call: Preparation of Internationalized Strings ('strin gprep') to Proposed Standard To: iesg@ietf.org >To: IETF-Announce:;;@loki.ietf.org >From: The IESG >SUBJECT: Last Call: Preparation of Internationalized Strings > ('stringprep') to Proposed Standard >Date: Wed, 22 May 2002 11:13:01 -0400 >The IESG has received a request to consider Preparation of >Internationalized Strings ('stringprep') > as a Proposed Standard. This has >been reviewed in the IETF but is not the product of an IETF Working >Group. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by June 4, 2002. This draft is based upon Unicode 3.1, but I see that the latest Unicode Standard is now version 3.2 (issued on 2002-03-27). It might be better to update this draft to 3.2 before acceptance as a Proposed Standard, and to do the same with the other drafts in the IDNA set. There would appear to be little that would need doing, beyond a routine updating of the tables in the draft, and with a bit of luck the whole IDNA series could then be published before Unicode 3.3 happens (which should be at least 12 months away). Moreover, since these drafts are so written that they are intended to be updated each time a new Unicode Version appears, it would be useful to have actual experience of doing that exercise on a draft, rather than on a published RFC. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 >----------------End Forwarded Message----------------< From owner-idn@ops.ietf.org Thu May 30 06:27:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27969 for ; Thu, 30 May 2002 06:27:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DMzC-000KD0-00 for idn-data@psg.com; Thu, 30 May 2002 03:16:50 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17DMzB-000KCu-00 for idn@ops.ietf.org; Thu, 30 May 2002 03:16:50 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4UAGgWa028611; Thu, 30 May 2002 12:16:42 +0200 To: Cc: Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin References: <200205300842.g4U8gl209938@odin.France.Sun.COM> From: Simon Josefsson Date: Thu, 30 May 2002 12:16:42 +0200 In-Reply-To: <200205300842.g4U8gl209938@odin.France.Sun.COM> (Erik Nordmark - Sun Microsystems's message of "Thu, 30 May 2002 08:41:50 -0000") Message-ID: Lines: 12 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) X-Face: FmU60_S;07.b/mq$mN4i[hYDH,9?'f\&F~>ROKqqN6'k$rh#oKV}|(Ol8$)L4`#XB"b|Tnu J"{VKSYBqieg/2&a.0pI2[7A\9*s+=%Zq\^> Moreover, since these drafts are so written that they are intended to be > updated each time a new Unicode Version appears, it would be useful to > have actual experience of doing that exercise on a draft, rather than on a > published RFC. This is interesting -- has the Unicode consortium promised to always update the CK normalization tables in a forward compatible way? Since IDNs will be used to identify hosts for security critical purposes, a change in the normalization could in theory be exploited to spoof identities in, e.g., TLS. From owner-idn@ops.ietf.org Thu May 30 06:32:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28067 for ; Thu, 30 May 2002 06:32:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DN3f-000KHb-00 for idn-data@psg.com; Thu, 30 May 2002 03:21:27 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17DN3e-000KHU-00 for idn@ops.ietf.org; Thu, 30 May 2002 03:21:26 -0700 Received: from ns.jck.com ([209.187.148.211] helo=localhost.jck.com) by bs.jck.com with esmtp (Exim 3.35 #1) id 17DN3e-000LTZ-00 for idn@ops.ietf.org; Thu, 30 May 2002 10:21:26 +0000 Date: Thu, 30 May 2002 06:21:25 -0400 From: John C Klensin To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <1756633.1022739685@localhost> In-Reply-To: <20020529235947.GC382@nicemice.net> References: <20020529235947.GC382@nicemice.net> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The disagreement between kre and myself about how to read the spec is, indeed, I think the key to this issue. It should be noted that we disagree about two things, which are separate: (i) Whether the correct reading on the DNS specs is that "ASCII" versus "binary" is a function of RR type, or a function of the bits in the octets. I take the text to suggest that _only_ ASCII (note, ASCII, not LDH) is permitted in RR types defined in or by 1034/1035, but that "future" RR types (and Classes) can be defined to have binary labels. Robert takes it as permitted characters outside the ASCII range, with case handling undefined for those characters. (ii) Whether the documents are clear or not, at least on this matter. Robert believes that they are. Perhaps we are in agreement -- I think they are fairly clear too, but in the other direction-- but that is at least the basis for a claim of ambiguity (or that I am an idiot, which is also a reasonable possibility). john --On Wednesday, May 29, 2002 11:59 PM +0000 "Adam M. Costello" wrote: > Mark.Andrews@isc.org wrote: > >> The alphabetic characters in this context are 0x41-0x5a and >> 0x61-0x7a (zero parity ASCII A-Z, a-z). All others are >> compared exactly. > > That may be what the popular DNS implementations do, but I > don't see RFC 1035 saying how to compare 0x80-0xFF. > > "Eric A. Hall" wrote: > >> You are the only one that is unclear on it. 0x80-0xFF must >> match exactly. > > I'm not the only one. Here's an excerpt from a message by > John Klensin: > > http://www.ietf.org/mail-archive/ietf/Current/msg15742.html > > RFC1035> For all parts of the DNS that are part of the official > RFC1035> protocol, all comparisons between character strings > (e.g., RFC1035> labels, domain names, etc.) are done in a > case-insensitive RFC1035> manner. At present, this rule is in > force throughout the RFC1035> domain system without exception. > > John Klensin> To emphasize, that is "all parts" and "all > comparisons", John Klensin> not "unless you happen to find the > high bit turned on". > > John Klensin> An existing and conforming implementation has no > way to do John Klensin> those required case-insensitive > comparisons outside the John Klensin> ASCII range. > > Robert Elz> No, nor is it required to. > > John Klensin> There we probably disagree -- I suggest that the > text is John Klensin> at least ambiguous and might require it. > > AMC > > > From owner-idn@ops.ietf.org Thu May 30 07:15:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28899 for ; Thu, 30 May 2002 07:15:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DNk7-000L1H-00 for idn-data@psg.com; Thu, 30 May 2002 04:05:19 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17DNk6-000L1B-00 for idn@ops.ietf.org; Thu, 30 May 2002 04:05:18 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4UB4P30018518; Thu, 30 May 2002 13:04:25 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 30 May 2002 13:05:02 +0200 Received: from [10.0.0.252] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 30 May 2002 13:05:00 +0200 Date: Thu, 30 May 2002 13:01:12 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Simon Josefsson , nordmark@eng.sun.com cc: idn@ops.ietf.org Subject: Re: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin Message-ID: <25020324.1022763672@localhost> In-Reply-To: References: <200205300842.g4U8gl209938@odin.France.Sun.COM> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 30 May 2002 11:05:02.0430 (UTC) FILETIME=[D8A4DFE0:01C207C9] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-30 12.16 +0200 Simon Josefsson wrote: > This is interesting -- has the Unicode consortium promised to always > update the CK normalization tables in a forward compatible way? Yes. paf -- Liason in IETF to Unicode Consortium From owner-idn@ops.ietf.org Thu May 30 07:16:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28944 for ; Thu, 30 May 2002 07:16:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DNgF-000Kwy-00 for idn-data@psg.com; Thu, 30 May 2002 04:01:19 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17DNgE-000Kwp-00 for idn@ops.ietf.org; Thu, 30 May 2002 04:01:18 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g4UB1GR08213 for ; Thu, 30 May 2002 13:01:16 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g4UB1Es08193; Thu, 30 May 2002 13:01:15 +0200 (METDST) Message-ID: <3CF6067A.DFCEA3AD@trab.se> Date: Thu, 30 May 2002 13:01:14 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org, klensin@jck.com Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: >The disagreement between kre and myself about how to read the >spec is, indeed, I think the key to this issue. It should be >noted that we disagree about two things, which are separate: >(ii) Whether the documents are clear or not, at least on this >matter. Robert believes that they are. Perhaps we are in >agreement -- I think they are fairly clear too, but in the other >direction-- but that is at least the basis for a claim of >ambiguity (or that I am an idiot, which is also a reasonable >possibility). > RFC 2181 and 2929 both clearly says that the label in DNS can include any octet value including zero. RFC 2929 also talks about text and binary labels, the binary label is defined in RFC 2673 so the normal label in DNS is a text label. RFC 2929 also says that for the text label, ASCII upper and lower case must be treated as equal. So while RFC 1034/1035 is vague in non-ASCII octet values, the above RFCs clearly defines that a text label can be composed of any octet value and that for the octet values equivalent to ASCII code values the matching must be case insensitive (but original case should be preserved in answers as stated by RFC 1035). Dan From owner-idn@ops.ietf.org Thu May 30 07:50:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29975 for ; Thu, 30 May 2002 07:50:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DOH8-000Lcv-00 for idn-data@psg.com; Thu, 30 May 2002 04:39:26 -0700 Received: from nod.reston.mci.net ([166.60.6.38]) by psg.com with esmtp (Exim 3.36 #1) id 17DOH7-000Lcp-00 for idn@ops.ietf.org; Thu, 30 May 2002 04:39:26 -0700 Received: from vint.wcom.com ([166.60.14.65]) by shoe.reston.mci.net (PMDF V6.1-1 #39689) with ESMTPA id <01KIBXDK34X690N4YX@shoe.reston.mci.net> for idn@ops.ietf.org; Thu, 30 May 2002 07:39:24 -0500 (EST) Date: Thu, 30 May 2002 07:33:15 -0400 From: vint cerf Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt In-reply-to: <1756633.1022739685@localhost> X-Sender: vcerf@shoe.reston.mci.net To: John C Klensin , IETF idn working group Message-id: <5.0.2.1.2.20020530073209.066d8b50@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <20020529235947.GC382@nicemice.net> <20020529235947.GC382@nicemice.net> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT what has been the practice in implementations of the various referenced RFCs? John's interpretation or Robert's? or has the apparent ambiguity also shown up in working implementations? vint At 06:21 AM 5/30/2002 -0400, John C Klensin wrote: >(i) Whether the correct reading on the DNS specs is that "ASCII" >versus "binary" is a function of RR type, or a function of the >bits in the octets. I take the text to suggest that _only_ >ASCII (note, ASCII, not LDH) is permitted in RR types defined in >or by 1034/1035, but that "future" RR types (and Classes) can be >defined to have binary labels. Robert takes it as permitted >characters outside the ASCII range, with case handling undefined >for those characters. From owner-idn@ops.ietf.org Thu May 30 09:13:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02928 for ; Thu, 30 May 2002 09:13:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DPdu-000NBK-00 for idn-data@psg.com; Thu, 30 May 2002 06:07:02 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17DPdt-000NBC-00 for idn@ops.ietf.org; Thu, 30 May 2002 06:07:01 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g4UD6xP21259 for ; Thu, 30 May 2002 15:06:59 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g4UD6wT21244; Thu, 30 May 2002 15:06:58 +0200 (METDST) Message-ID: <3CF623F2.417A17F9@trab.se> Date: Thu, 30 May 2002 15:06:58 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: klensin@jck.com, idn@ops.ietf.org, vinton.g.cerf@wcom.com Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit vint cerf wrote > >what has been the practice in implementations of the various >referenced RFCs? John's interpretation or Robert's? > >or has the apparent ambiguity also shown up in working >implementations? I know several DNS servers using non-ASCII domain names. The Microsoft DNS servers uses UTF-8 encoded domain names and the .NU-domain supports UTF-8, ISO 8859-1 and others depending on what client uses. I am sure there are more. Using UTF-8 or ISO 8859-1 is fully compatible with the current ASCII names as well as ISO 10646 code value compatible. Due to the current DNS RFCs not defining how characters should be encoded outside the ASCII range, people have selected the best choice for their needs as seen above. It would have been very good if the current DNS standard was updated with a RFC stating which encoding(s) is to be used. UTF-8 or UTF-8 and ISO 8859-1 are the best choices folloging that UCS is the most common choice for internationalisation. Dan From owner-idn@ops.ietf.org Thu May 30 10:00:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05354 for ; Thu, 30 May 2002 10:00:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DQMJ-000O6J-00 for idn-data@psg.com; Thu, 30 May 2002 06:52:55 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17DQMI-000O6D-00 for idn@ops.ietf.org; Thu, 30 May 2002 06:52:55 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4UDq4mE014711; Thu, 30 May 2002 15:52:10 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 30 May 2002 15:52:44 +0200 Received: from [10.0.0.252] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 30 May 2002 15:52:21 +0200 Date: Thu, 30 May 2002 15:20:58 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Simon Josefsson cc: idn@ops.ietf.org Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin Message-ID: <25523494.1022772058@localhost> In-Reply-To: References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 30 May 2002 13:52:44.0358 (UTC) FILETIME=[46053E60:01C207E1] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-30 14.24 +0200 Simon Josefsson wrote: > A further security consideration of IDNA could be that whenever such > modifications is done in the Unicode standards, they may be exploited > and it should be an operational consideration to never register > domains, issues PKIX certifices for domains, create Kerberos realms, > create PGP keys, etc, for IDNs that contains characters that have > their decomposition mapping changed by the Unicode consortium. > > It seems as if a modification of this kind occured between Unicode 3.0 > and 3.1: http://www.unicode.org/versions/corrigendum2.html. > > The conclusion here is that this isn't a practical problem -- only one > character changed normalization between 3.0 and 3.1 and none between > 3.1 and 3.2 AFAIK. I am more worried about the transcoding problem. (a) There was one change between 3.1 and 3.2. (b) If Unicode consortium decides to make a change which "we" (in the form of IETF community) don't think is safe enough, then we can choose to _NOT_ follow the update of Unicode, and stay with the version we are following (which include the errors which Unicode Consortium corrects to the new version). I.e. just because the documents point at a specific version of Unicode, we have to choice of not following and upgrading. That's the emergency break we have. Still, I (aswell as Unicode Consortium as you can see in their statement which you pointed at) don't want to see this happens. The day it does, if it does, we can talk again about it. paf From owner-idn@ops.ietf.org Thu May 30 11:02:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08022 for ; Thu, 30 May 2002 11:02:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DRJf-000PTU-00 for idn-data@psg.com; Thu, 30 May 2002 07:54:15 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17DRJe-000PTN-00 for idn@ops.ietf.org; Thu, 30 May 2002 07:54:14 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17DRIO-000M3m-00; Thu, 30 May 2002 14:52:56 +0000 Date: Thu, 30 May 2002 10:52:56 -0400 From: John C Klensin To: Dan Oscarsson cc: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <46984419.1022755976@localhost> In-Reply-To: <3CF6067A.DFCEA3AD@trab.se> References: <3CF6067A.DFCEA3AD@trab.se> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 30 May, 2002 13:01 +0200 Dan Oscarsson wrote: > RFC 2181 and 2929 both clearly says that the label in DNS > can include any octet value including zero. > RFC 2929 also talks about text and binary labels, the binary > label is defined in RFC 2673 so the normal label in DNS is > a text label. RFC 2929 also says that for the text label, > ASCII upper and lower case must be treated as equal. This is absolutely correct, and I didn't mean to suggest otherwise. But we generally don't let BCPs or Proposed Standards replace text in full Standards, at least without being very explicit that they are doing so. And 2181 was, if I recall, approved on the assumption that it did not make changes to 1034/1035/1123 in this area. So, if one wants to restate the question in terms of 2181, it would be whether the interpretation of 2181 (which is, not surprisingly, consistent with kre's interpretation) is correct given the language of 1034/1035. Or, if we conclude that 1034/1035 is ambiguous in this area (2181, if I recall, claims that it is not), what the informed consensus of the community is on the correct fix given today's knowledge of the various issues and risks. I note in passing that the "compare ASCII in a case-insensitive way, but treat any octet above 0x7F as binary with no case-mapping" interpretation would be very hard on those who advocate direct use of UTF-8 but who believe that users of Greek, Cyrillic, French, Swedish, Norwegian, etc., are as entitled to case-independent interpretation as users of English. This is, after all, why we have maturity levels for standards. john From owner-idn@ops.ietf.org Thu May 30 11:40:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09529 for ; Thu, 30 May 2002 11:40:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DRpk-0000Gr-00 for idn-data@psg.com; Thu, 30 May 2002 08:27:24 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17DRpj-0000Gk-00 for idn@ops.ietf.org; Thu, 30 May 2002 08:27:23 -0700 Received: from MASTER ([61.75.17.52]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4UFQfA12847; Fri, 31 May 2002 00:26:41 +0900 Message-ID: <001e01c207ee$64eb5370$2b19fea9@temp> From: "Soobok Lee" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Simon Josefsson" Cc: References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost> Subject: Re: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin Date: Fri, 31 May 2002 00:26:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit If new version of Unicode is not proved to be safe enough, we have choices 1) wait until newer , correc, mature and stable version of Unicode come out 2) go with previous version of Unicode, regardless of whether the version has errors or not. if we choose 2), we have the following chance of failures and security concerns NFKC3.1(CaseFold3.1(IDN1)) != NFKC3.2(CaseFold3.2(IDN1)) NFKC3.1(CaseFold3.1( NFKC3.2(CaseFold3.2(IDN1)) )) != NFKC3.2(CaseFold3.2(IDN1)) This may happen when ,for example, Canonical XML (which use NFC) facility applies new NFC3.2 to IDN-containing tag values ,and that canonicalized IDN go through NFKC3.1 in further nameprep/ACE coding. This issues were raised at the time of IDN WG last call, 3 months ago. Soobok Lee ----- Original Message ----- From: "Patrik Fältström" To: "Simon Josefsson" Cc: Sent: Thursday, May 30, 2002 10:20 PM Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin > --On 2002-05-30 14.24 +0200 Simon Josefsson wrote: > > > A further security consideration of IDNA could be that whenever such > > modifications is done in the Unicode standards, they may be exploited > > and it should be an operational consideration to never register > > domains, issues PKIX certifices for domains, create Kerberos realms, > > create PGP keys, etc, for IDNs that contains characters that have > > their decomposition mapping changed by the Unicode consortium. > > > > It seems as if a modification of this kind occured between Unicode 3.0 > > and 3.1: http://www.unicode.org/versions/corrigendum2.html. > > > > The conclusion here is that this isn't a practical problem -- only one > > character changed normalization between 3.0 and 3.1 and none between > > 3.1 and 3.2 AFAIK. I am more worried about the transcoding problem. > > (a) There was one change between 3.1 and 3.2. > > (b) If Unicode consortium decides to make a change which "we" (in the form > of IETF community) don't think is safe enough, then we can choose to _NOT_ > follow the update of Unicode, and stay with the version we are following > (which include the errors which Unicode Consortium corrects to the new > version). > > I.e. just because the documents point at a specific version of Unicode, we > have to choice of not following and upgrading. That's the emergency break > we have. > > Still, I (aswell as Unicode Consortium as you can see in their statement > which you pointed at) don't want to see this happens. The day it does, if > it does, we can talk again about it. > > paf > From owner-idn@ops.ietf.org Thu May 30 12:07:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10831 for ; Thu, 30 May 2002 12:07:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DSHw-0000yn-00 for idn-data@psg.com; Thu, 30 May 2002 08:56:32 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17DSHv-0000yf-00 for idn@ops.ietf.org; Thu, 30 May 2002 08:56:32 -0700 Received: from MASTER ([61.75.17.52]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4UFuDA13059 for ; Fri, 31 May 2002 00:56:13 +0900 Message-ID: <006701c207f2$84b045e0$2b19fea9@temp> From: "Soobok Lee" To: References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Fri, 31 May 2002 00:56:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit By "additions", i mean the required new tag for new version of legacy encoding, like "ks_c_5601-1992" which should have been used, but never have been, as far as i know. Is there any central registry that maintain the correct tag values for vaiour versions of numorous legacy encodings ?? If not, how to ensure stable and interoperable legacy-2-unicode conversion among myriads of applications ? Soobok Lee ----- Original Message ----- From: "Doug Ewell" To: ; "James Seng" Cc: Sent: Wednesday, May 29, 2002 2:32 PM Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > Soobok Lee wrote: > > > What if proper and stable implementation of legacy encodings in > > IDNA is not a tangilbe object due to their frequent updates/ > > additions ? > > How "frequent" are updates to legacy encodings, or updates to the > mapping tables between legacy encodings and Unicode? > > As for additions, they shouldn't cause a problem anyway, because they > don't break existing legacy-to-Unicode mappings. An often-mentioned > case of adding to a legacy encoding was when Microsoft retrofitted > U+20AC EURO SIGN onto their Windows code pages (mostly at previously > unassigned code position 0x80). The only people who suffered at all > were the ones who thought "unassigned" somehow meant that they should > map 0x80 to U+0080. Everyone else made it just fine. > > -Doug Ewell > Fullerton, California > (would prefer to receive only one copy of these messages) > From owner-idn@ops.ietf.org Thu May 30 12:14:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11294 for ; Thu, 30 May 2002 12:14:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DSN1-00017h-00 for idn-data@psg.com; Thu, 30 May 2002 09:01:47 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17DSN0-00017b-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:01:47 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94359; Thu, 30 May 2002 11:01:53 -0500 Message-ID: <3CF64CE7.7AB11BF9@ehsco.com> Date: Thu, 30 May 2002 11:01:43 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020529235947.GC382@nicemice.net> <1756633.1022739685@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > > The disagreement between kre and myself about how to read the > spec is, indeed, I think the key to this issue. It should be > noted that we disagree about two things, which are separate: > > (i) Whether the correct reading on the DNS specs is that "ASCII" > versus "binary" is a function of RR type, or a function of the > bits in the octets. I take the text to suggest that _only_ > ASCII (note, ASCII, not LDH) is permitted in RR types defined in > or by 1034/1035, but that "future" RR types (and Classes) can be > defined to have binary labels. Robert takes it as permitted > characters outside the ASCII range, with case handling undefined > for those characters. You are both correct, but Robert is more correct. Note that Robert didn't disagree with you "future" use. Essentially this boils down to having biblical scholars arguing over how MUCH they should love their neighbor. There are three elements here: 1) The lower seven-bit range is definitely interpreted as ASCII. 2) The upper eight-bit range is definitely undefined for those RRs and classes which do not have an interpretation. While some new RR and/or class could define an interpretation for the eight-bit range, the existing RRs in the IN class treat this range as undefined values. 3) STD13 is quite clear that queries may contain eight-bit codes. So, taking all of the above into consideration, how do you treat the eight-bit codes for existing RRs in the IN class, where an interpretation has not been defined? You have to treat them as undefined. Since they are undefined, they are not alphabetic, and the non-alphabetic comparison rule kicks in. Whether or not any of these RRs allow eight-bit codes to be defined is a totally different question, but one which was answered in the affirmative by RFC 2181. So, unless a new RR or class (or EDNS tag, or whatever) defines some specific interpretation, the eight-bit codes are to be treated as undefined codes, and must match exactly. > (ii) Whether the documents are clear or not, at least on this > matter. Robert believes that they are. Perhaps we are in > agreement -- I think they are fairly clear too, but in the other You are both wrong on that one. This is something that I hope to help fix at some point. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 30 12:15:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11313 for ; Thu, 30 May 2002 12:15:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DSPx-0001CY-00 for idn-data@psg.com; Thu, 30 May 2002 09:04:49 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17DSPw-0001CS-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:04:48 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94367; Thu, 30 May 2002 11:04:55 -0500 Message-ID: <3CF64D9A.A69BCB0D@ehsco.com> Date: Thu, 30 May 2002 11:04:42 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: vint cerf CC: John C Klensin , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020529235947.GC382@nicemice.net> <20020529235947.GC382@nicemice.net> <5.0.2.1.2.20020530073209.066d8b50@shoe.reston.mci.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit vint cerf wrote: > > what has been the practice in implementations of the various > referenced RFCs? John's interpretation or Robert's? > > or has the apparent ambiguity also shown up in working > implementations? Whenever any ambiguity appears, it is at the UI level, and as a violation of RFC 2181 (not allowing the use of eight-bit codes when creating an RR). All of the servers I have looked at treat eight-bit codes as opaque data, in accordance with the spec. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 30 12:26:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11821 for ; Thu, 30 May 2002 12:26:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DScc-0001am-00 for idn-data@psg.com; Thu, 30 May 2002 09:17:54 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17DScb-0001ag-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:17:53 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4UGGp4v005784; Thu, 30 May 2002 18:17:08 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 30 May 2002 18:17:23 +0200 Received: from [10.0.0.252] ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 30 May 2002 18:17:22 +0200 Date: Thu, 30 May 2002 18:11:52 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Soobok Lee , Simon Josefsson cc: idn@ops.ietf.org Subject: Re: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin Message-ID: <26138688.1022782312@localhost> In-Reply-To: <001e01c207ee$64eb5370$2b19fea9@temp> References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost> <001e01c207ee$64eb5370$2b19fea9@temp> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 30 May 2002 16:17:23.0109 (UTC) FILETIME=[7AF58D50:01C207F5] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-31 00.26 +0900 Soobok Lee wrote: > This issues were raised at the time of IDN WG last call, 3 months ago. And my answer was exactly the same then as now. We can not do better. If Unicode is updated, you will either get inconsistency with the parties using the new version of Unicode (if IDN is not upgraded) or inconsistency with old registered names (if IDN is upgraded). The point is that the current scheme (a) trust Unicode when they say that changes will be backward compatble and (b) IF they do an incompatible change, we can at that point in time make the desicion -- we don't have to decide now what path we take. paf From owner-idn@ops.ietf.org Thu May 30 12:28:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11954 for ; Thu, 30 May 2002 12:28:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DSfX-0001hp-00 for idn-data@psg.com; Thu, 30 May 2002 09:20:55 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17DSfW-0001hf-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:20:54 -0700 Received: from MASTER ([61.75.17.52]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g4UGKpA13257 for ; Fri, 31 May 2002 01:20:51 +0900 Message-ID: <008701c207f5$ef50b120$2b19fea9@temp> From: "Soobok Lee" To: References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Fri, 31 May 2002 01:20:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As for the case of new character addition to legacy encodings you mentioned below, The real problem emerges when the older version of receiving application has received new-version-legacy-encoded IDN(IRI) from the new version of sender application and it tries to convert that received IDN(IRI) into unicode using the *OLDER* version of legacy-2-unicode convesion table, but surely it will fail in some cases. Soobok Lee ----- Original Message ----- From: "Doug Ewell" > > As for additions, they shouldn't cause a problem anyway, because they > don't break existing legacy-to-Unicode mappings. An often-mentioned > case of adding to a legacy encoding was when Microsoft retrofitted > U+20AC EURO SIGN onto their Windows code pages (mostly at previously > unassigned code position 0x80). The only people who suffered at all > were the ones who thought "unassigned" somehow meant that they should > map 0x80 to U+0080. Everyone else made it just fine. > > -Doug Ewell > Fullerton, California > (would prefer to receive only one copy of these messages) > From owner-idn@ops.ietf.org Thu May 30 12:30:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12061 for ; Thu, 30 May 2002 12:30:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DSUR-0001Lo-00 for idn-data@psg.com; Thu, 30 May 2002 09:09:27 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17DSUQ-0001LU-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:09:26 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4UG9IWa031041; Thu, 30 May 2002 18:09:19 +0200 To: Patrik =?iso-8859-1?q?F=E4ltstr=F6m?= Cc: idn@ops.ietf.org Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost> From: Simon Josefsson Date: Thu, 30 May 2002 18:09:18 +0200 In-Reply-To: <25523494.1022772058@localhost> (Patrik =?iso-8859-1?q?F=E4ltstr=F6m's?= message of "Thu, 30 May 2002 15:20:58 +0200") Message-ID: Lines: 60 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) X-Face: 1Yn@M+tp9bHO[8c_KMq4EAehxF;z,'j|yrivOiG+mxk$hnZac61A{@h6 writes: > --On 2002-05-30 14.24 +0200 Simon Josefsson wrote: > >> A further security consideration of IDNA could be that whenever such >> modifications is done in the Unicode standards, they may be exploited >> and it should be an operational consideration to never register >> domains, issues PKIX certifices for domains, create Kerberos realms, >> create PGP keys, etc, for IDNs that contains characters that have >> their decomposition mapping changed by the Unicode consortium. >> >> It seems as if a modification of this kind occured between Unicode 3.0 >> and 3.1: http://www.unicode.org/versions/corrigendum2.html. >> >> The conclusion here is that this isn't a practical problem -- only one >> character changed normalization between 3.0 and 3.1 and none between >> 3.1 and 3.2 AFAIK. I am more worried about the transcoding problem. > > (a) There was one change between 3.1 and 3.2. So the Unicode consortium has already broken the promise? The assumption that normalization tables are not changed in a backwards incompatible way should be stated in the security considerations IMHO, as the security of IDN depends on that. Especially if the assumption doesn't hold in all cases. > (b) If Unicode consortium decides to make a change which "we" (in the form > of IETF community) don't think is safe enough, then we can choose to _NOT_ > follow the update of Unicode, and stay with the version we are following > (which include the errors which Unicode Consortium corrects to the new > version). > > I.e. just because the documents point at a specific version of Unicode, we > have to choice of not following and upgrading. That's the emergency break > we have. This means Unicode-based systems will implement two versions of Unicode (normalization, encoding etc) at the same time. One implementation for IDNA, one for the rest of the system that need new features in Unicode. That should probably also made more clear; that an implementator MUST NOT use Unicode 3.2 or any other Unicode version provided by the system, but must pick Unicode 3.1 (without the Corrigendum, it seems, since they aren't referenced in IDNA), otherwise security may be jeopardized. Again, it would be useful to see a study on how serious these problems are in practice. I'm not sure if this (and the transcoding) discussion is purely theoretical or, at the other extreme, there will not only be security problems but even interoperability problems (application A can connect to bank with funny characters but application B cannot connect, all because of differences in normalization and/or transcoding mapping tables). > Still, I (aswell as Unicode Consortium as you can see in their statement > which you pointed at) don't want to see this happens. The day it does, if > it does, we can talk again about it. If indeed there was a change between 3.1 and 3.2, the day has already come. From owner-idn@ops.ietf.org Thu May 30 12:45:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12572 for ; Thu, 30 May 2002 12:45:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DSxf-0002Dg-00 for idn-data@psg.com; Thu, 30 May 2002 09:39:39 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17DSxd-0002DT-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:39:37 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4UGcnBS008151; Thu, 30 May 2002 18:38:53 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 30 May 2002 18:38:51 +0200 Received: from [10.0.0.252] ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 30 May 2002 18:38:50 +0200 Date: Thu, 30 May 2002 18:37:45 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Simon Josefsson cc: idn@ops.ietf.org Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings ('strin Message-ID: <26231873.1022783865@localhost> In-Reply-To: References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 30 May 2002 16:38:50.0750 (UTC) FILETIME=[7A73F9E0:01C207F8] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-05-30 18.09 +0200 Simon Josefsson wrote: > If indeed there was a change between 3.1 and 3.2, the day has already > come. No. They said very explicitly that the change could be done (i.e. the correction could be done) just because IDN is not deployed. Yes, that involvs we choosing to go with 3.2 and not 3.1 (which was last called), but that has already been suggested as a last call comment so that horse is already dead. paf From owner-idn@ops.ietf.org Thu May 30 12:58:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12962 for ; Thu, 30 May 2002 12:58:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DT7r-0002Vf-00 for idn-data@psg.com; Thu, 30 May 2002 09:50:11 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17DT7q-0002VZ-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:50:10 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94390; Thu, 30 May 2002 11:50:17 -0500 Message-ID: <3CF6583E.1E7F0C44@ehsco.com> Date: Thu, 30 May 2002 11:50:06 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: idn@ops.ietf.org Subject: Re: [idn] Re: :Re: Last Call: Preparation of InternationalizedStrings ('strin References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost> <001e01c207ee$64eb5370$2b19fea9@temp> <26138688.1022782312@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > > --On 2002-05-31 00.26 +0900 Soobok Lee wrote: > > > This issues were raised at the time of IDN WG last call, 3 months ago. > > And my answer was exactly the same then as now. We can not do better. If > Unicode is updated, you will either get inconsistency with the parties > using the new version of Unicode (if IDN is not upgraded) or > inconsistency with old registered names (if IDN is upgraded). There are some alternatives here. We can certainly define our own Unicode mapping table and make it available through a variety of means, and also encourage synchronization. When unicode changes, we change the mapping tables to handle any conflicts. We could even put this stuff into a zone, and let people replicate from that periodically, to encourage faster synchronization. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 30 13:05:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13288 for ; Thu, 30 May 2002 13:05:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DTE0-0002gz-00 for idn-data@psg.com; Thu, 30 May 2002 09:56:32 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17DTDz-0002gt-00 for idn@ops.ietf.org; Thu, 30 May 2002 09:56:31 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94398; Thu, 30 May 2002 11:56:37 -0500 Message-ID: <3CF659BB.D4BE50CB@ehsco.com> Date: Thu, 30 May 2002 11:56:28 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dan Oscarsson CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CF5C663.9D2EFC77@trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan Oscarsson wrote: > It is simple to standardise it. We just publish a short RFC > defining how octet values with the 8th bit should be handled. > > There are already DNS servers supporting names in UTF-8 and other > encodings. Why not standardise what encoding should be used? The reason why this won't work is that there is no way to determine if the remote end-point is compliant with the updated specification. If you want to enforce an interpretation of the eight-bit range, you have to use new RRs, a new class, an EDNS identifier, or something, in order to distinguish between the legacy and modern systems. Otherwise, you send UTF-8 to the remote system, it treats the data as MacRoman, and the subsequent usages are working with invalid data. There must be an identifier of some kind. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 30 13:09:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13397 for ; Thu, 30 May 2002 13:09:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DTIb-0002oU-00 for idn-data@psg.com; Thu, 30 May 2002 10:01:17 -0700 Received: from sccrmhc01.attbi.com ([204.127.202.61]) by psg.com with esmtp (Exim 3.36 #1) id 17DTIa-0002oH-00 for idn@ops.ietf.org; Thu, 30 May 2002 10:01:16 -0700 Received: from c1340594a ([12.234.224.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020530170115.MXPR29266.sccrmhc01.attbi.com@c1340594a>; Thu, 30 May 2002 17:01:15 +0000 Message-ID: <003d01c207fb$c1d40ac0$8900a8c0@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Soobok Lee" , References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> <006701c207f2$84b045e0$2b19fea9@temp> Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Date: Thu, 30 May 2002 10:02:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is, to my knowledge, no such central registry. The IANA names are, unfortunately, neither unambiguous nor comprehensive (see other mail). The closest I know of to this is that the ICU team has been gathering data on different character sets based on a programmatic analysis of how conversion actually operates on different platforms (which is often different than the documentation of that mapping!). We have made provision for (but have not gathered), historical data -- unless a mapping is also in modern use on one of the platforms we collected from: aix, glibc, hpux,os390, os400, java, solaris, windows. See http://oss.software.ibm.com/icu/charset/ for an overview; http://oss.software.ibm.com/cvs/icu/charset/data/xml/ for the data in xml. However, I want to emphasize that this is an open-source project, *not* a registry. Mark __________ http://www.macchiato.com "Eppur si muove" ----- Original Message ----- From: "Soobok Lee" To: Sent: Thursday, May 30, 2002 08:56 Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > By "additions", i mean the required new tag for new version of legacy encoding, like "ks_c_5601-1992" > which should have been used, but never have been, as far as i know. Is there any central > registry that maintain the correct tag values for vaiour versions of numorous legacy encodings ?? > If not, how to ensure stable and interoperable legacy-2-unicode conversion among myriads of applications ? > > Soobok Lee > > ----- Original Message ----- > From: "Doug Ewell" > To: ; "James Seng" > Cc: > Sent: Wednesday, May 29, 2002 2:32 PM > Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > > > > Soobok Lee wrote: > > > > > What if proper and stable implementation of legacy encodings in > > > IDNA is not a tangilbe object due to their frequent updates/ > > > additions ? > > > > How "frequent" are updates to legacy encodings, or updates to the > > mapping tables between legacy encodings and Unicode? > > > > As for additions, they shouldn't cause a problem anyway, because they > > don't break existing legacy-to-Unicode mappings. An often-mentioned > > case of adding to a legacy encoding was when Microsoft retrofitted > > U+20AC EURO SIGN onto their Windows code pages (mostly at previously > > unassigned code position 0x80). The only people who suffered at all > > were the ones who thought "unassigned" somehow meant that they should > > map 0x80 to U+0080. Everyone else made it just fine. > > > > -Doug Ewell > > Fullerton, California > > (would prefer to receive only one copy of these messages) > > > > > From owner-idn@ops.ietf.org Thu May 30 13:35:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14493 for ; Thu, 30 May 2002 13:35:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DTjo-0003hG-00 for idn-data@psg.com; Thu, 30 May 2002 10:29:24 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #1) id 17DTjn-0003h8-00 for idn@ops.ietf.org; Thu, 30 May 2002 10:29:24 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 2AA80479A; Thu, 30 May 2002 19:29:57 +0200 (CEST) Date: Thu, 30 May 2002 19:29:57 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Soobok Lee Cc: idn@ops.ietf.org Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) Message-ID: <20020530172957.GA9301@rap.rap.dk> References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> <006701c207f2$84b045e0$2b19fea9@temp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006701c207f2$84b045e0$2b19fea9@temp> User-Agent: Mutt/1.3.27i Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, May 31, 2002 at 12:56:05AM +0900, Soobok Lee wrote: > By "additions", i mean the required new tag for new version of legacy encoding, like "ks_c_5601-1992" > which should have been used, but never have been, as far as i know. Is there any central > registry that maintain the correct tag values for vaiour versions of numorous legacy encodings ?? > If not, how to ensure stable and interoperable legacy-2-unicode conversion among myriads of applications ? IANA has a registry of charsets, and many of them have mappings defined for UCS. There is also an ISO register that has mappings between legacy charsets and UCS, available at http://www.dkuug.dk/cultreg/registrations/charmap Kind regards Keld From owner-idn@ops.ietf.org Thu May 30 17:40:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20476 for ; Thu, 30 May 2002 17:40:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DXQI-000AAj-00 for idn-data@psg.com; Thu, 30 May 2002 14:25:30 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17DXQH-000AAY-00 for idn@ops.ietf.org; Thu, 30 May 2002 14:25:29 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17DXQG-0000FX-00 for ; Thu, 30 May 2002 14:25:28 -0700 Date: Thu, 30 May 2002 21:25:28 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt Message-ID: <20020530212528.GA32634@nicemice.net> Reply-To: IETF idn working group References: <200205231129.HAA04661@ietf.org> <20020528221203.GC24925@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > > When systems use local character sets other than ASCII > > and Unicode, this specification leaves the transcoding > > problem up to the application. If applications implement > > different transcoding rules, they could interpret the same name > > differently and contact different servers. This problem is not > > solved by security protocols like TLS that do not take local > > character sets into account. > > Before the last sentence it could be useful to also add something > like: "Furthermore, if a single application uses one mapping table > in one version, and a subsequent version of the application uses > a modified mapping table, different interpretations of the same > internationalized text string may be possible even within the same > application which has security implications." How about simply changing "applications" to "different applications (or different versions of one application)"? AMC From owner-idn@ops.ietf.org Thu May 30 18:04:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20865 for ; Thu, 30 May 2002 18:04:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DXqa-000AxF-00 for idn-data@psg.com; Thu, 30 May 2002 14:52:40 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17DXqZ-000Ax9-00 for idn@ops.ietf.org; Thu, 30 May 2002 14:52:39 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17DXqZ-0000NQ-00 for ; Thu, 30 May 2002 14:52:39 -0700 Date: Thu, 30 May 2002 21:52:39 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020530215238.GB32634@nicemice.net> Reply-To: IETF idn working group References: <3CF5C663.9D2EFC77@trab.se> <3CF659BB.D4BE50CB@ehsco.com> <20020529235947.GC382@nicemice.net> <1756633.1022739685@localhost> <3CF64CE7.7AB11BF9@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF659BB.D4BE50CB@ehsco.com> <3CF64CE7.7AB11BF9@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Funny, I find myself almost entirely agreeing with Eric Hall on this topic. :) "Eric A. Hall" wrote: > 1) The lower seven-bit range is definitely interpreted as ASCII. For all text strings, yes, which at least includes the names and values of all resource records defined in 1035. > 2) The upper eight-bit range is definitely undefined for those RRs > and classes which do not have an interpretation. While some new > RR and/or class could define an interpretation for the eight-bit > range, the existing RRs in the IN class treat this range as > undefined values. Agreed. > 3) STD13 is quite clear that queries may contain eight-bit codes. Agreed. > So, taking all of the above into consideration, how do you treat > the eight-bit codes for existing RRs in the IN class, where an > interpretation has not been defined? Good question! > Since they are undefined, they are not alphabetic That's the one point where I don't follow you. If they are undefined, then their alphabeticness is undefined, and hence the proper way to compare them is undefined. RFC 1035 says that comparisons of text strings must be case-insensitive "without exception". Doing an exact match of 0x80-0xFF is guaranteed to violate that requirement for every charset I know of that uses the 8th bit. If you send a query containing an 8-bit name, I think you do so at your own risk, because RFC 1035 doesn't say what the server will do. > If you want to enforce an interpretation of the eight-bit range, you > have to use new RRs, a new class, an EDNS identifier, or something, in > order to distinguish between the legacy and modern systems. Agreed. AMC From owner-idn@ops.ietf.org Thu May 30 19:18:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22005 for ; Thu, 30 May 2002 19:18:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DZ40-000D6s-00 for idn-data@psg.com; Thu, 30 May 2002 16:10:36 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17DZ3z-000D6m-00 for idn@ops.ietf.org; Thu, 30 May 2002 16:10:35 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94463 for idn@ops.ietf.org; Thu, 30 May 2002 18:10:42 -0500 Message-ID: <3CF6B168.5601F150@ehsco.com> Date: Thu, 30 May 2002 18:10:32 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CF5C663.9D2EFC77@trab.se> <3CF659BB.D4BE50CB@ehsco.com> <20020529235947.GC382@nicemice.net> <1756633.1022739685@localhost> <3CF64CE7.7AB11BF9@ehsco.com> <20020530215238.GB32634@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > Since they are undefined, they are not alphabetic > > That's the one point where I don't follow you. If they are undefined, > then their alphabeticness is undefined Being undefined, they are just opaque codes. Nothing more, nothing less. They may be represented as characters within the scope of a local system who only has a charset for output purposes, but that doesn't mean the data contains characters. The data contains opaque codes. Nothing more. > If you want to enforce an interpretation of the eight-bit range, you > > have to use new RRs, a new class, an EDNS identifier, or something, in > > order to distinguish between the legacy and modern systems. > > Agreed. Then change IDNA. Mandatory transliteration introduces the same kind of absurd recklessness. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu May 30 20:40:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23007 for ; Thu, 30 May 2002 20:40:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DaKk-000FST-00 for idn-data@psg.com; Thu, 30 May 2002 17:31:58 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17DaKj-000FSM-00 for idn@ops.ietf.org; Thu, 30 May 2002 17:31:57 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17DaKj-0000z0-00 for ; Thu, 30 May 2002 17:31:57 -0700 Date: Fri, 31 May 2002 00:31:57 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020531003156.GC32634@nicemice.net> Reply-To: IETF idn working group References: <3CF5C663.9D2EFC77@trab.se> <3CF659BB.D4BE50CB@ehsco.com> <20020529235947.GC382@nicemice.net> <1756633.1022739685@localhost> <3CF64CE7.7AB11BF9@ehsco.com> <20020530215238.GB32634@nicemice.net> <3CF6B168.5601F150@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF6B168.5601F150@ehsco.com> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > Being undefined, they [80..FF] are just opaque codes. Nothing more, > nothing less. They may be represented as characters within the scope > of a local system who only has a charset for output purposes, but that > doesn't mean the data contains characters. The data contains opaque > codes. Nothing more. So you're saying that a label containing some octets in the range 0..7F and some in the range 80..FF is neither text nor binary, but actually a mixture of the two. That's a clever motivation for the comparison algorithm that you endorse, but I don't see that model described by RFC 1035. If anything, RFC 1035 appears to take the view that labels are text, at least until further notice. s make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names... Taken together, these statements strongly suggest that labels are text until further notice, and therefore label comparisons must be case-insensitive for the entire labels. I doubt we're going to agree on this, but the fact that we could keep arguing about it indicates that RFC 1035 is not clear about how to compare 80..FF. > > > If you want to enforce an interpretation of the eight-bit range, > > > you have to use new RRs, a new class, an EDNS identifier, or > > > something, in order to distinguish between the legacy and modern > > > systems. > > > > Agreed. > > Then change IDNA. Mandatory transliteration introduces the same kind > of absurd recklessness. You say it's dangerous to put non-ASCII data into a protocol message where the semantics of non-ASCII data are undefined, and I agree. That's why IDNA prohibits putting non-ASCII domain names into protocol messages (and function arguments, structured data files, etc) unless the protocol/interface/format explicitly invites IDNs. I assume it's the ASCII --> non-ASCII conversion that worries you, but that happens only when displaying names to users (the ASCII form would be user-hostile), and only when the aforementioned prohibition does not apply, so the risk is usually small, and implementors are invited to forgo this conversion when they judge the risk to be significant. AMC From owner-idn@ops.ietf.org Thu May 30 21:00:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23297 for ; Thu, 30 May 2002 21:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DahA-000G91-00 for idn-data@psg.com; Thu, 30 May 2002 17:55:08 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Dah9-000G8v-00 for idn@ops.ietf.org; Thu, 30 May 2002 17:55:07 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94478 for idn@ops.ietf.org; Thu, 30 May 2002 19:55:14 -0500 Message-ID: <3CF6C9E8.197F8346@ehsco.com> Date: Thu, 30 May 2002 19:55:05 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CF5C663.9D2EFC77@trab.se> <3CF659BB.D4BE50CB@ehsco.com> <20020529235947.GC382@nicemice.net> <1756633.1022739685@localhost> <3CF64CE7.7AB11BF9@ehsco.com> <20020530215238.GB32634@nicemice.net> <3CF6B168.5601F150@ehsco.com> <20020531003156.GC32634@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > So you're saying that a label containing some octets in the range 0..7F > and some in the range 80..FF is neither text nor binary, but actually > a mixture of the two. That's one way to read it. Another way to read it is that all of the codepoints are opaque, except that ASCII ranges A-Z and a-z are to be treated as case-neutral for the purposes of comparison ONLY. Which is, in fact, exactly what RFC 1035 says. > I assume it's the ASCII --> non-ASCII conversion that worries you, but > that happens only when displaying names to users (the ASCII form would > be user-hostile) The results are identical to what would happen if we reinvented the existing RRs. There is no practical difference to the user community. The only safe way to handle either of these ridiculous scenarios is to let the governing bodies decide how the data should be handled. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri May 31 02:30:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07205 for ; Fri, 31 May 2002 02:30:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DfhG-000PT1-00 for idn-data@psg.com; Thu, 30 May 2002 23:15:34 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17DfhF-000PSt-00 for idn@ops.ietf.org; Thu, 30 May 2002 23:15:33 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g4V6FVP21805 for ; Fri, 31 May 2002 08:15:31 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g4V6FIT21767; Fri, 31 May 2002 08:15:18 +0200 (METDST) Message-ID: <3CF714F5.B58C2096@trab.se> Date: Fri, 31 May 2002 08:15:17 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: ehall@ehsco.com, idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric A. Hall wrote: >> It is simple to standardise it. We just publish a short RFC >> defining how octet values with the 8th bit should be handled. >> >The reason why this won't work is that there is no way to determine if the >remote end-point is compliant with the updated specification. If you want >to enforce an interpretation of the eight-bit range, you have to use new >RRs, a new class, an EDNS identifier, or something, in order to >distinguish between the legacy and modern systems. Otherwise, you send >UTF-8 to the remote system, it treats the data as MacRoman, and the >subsequent usages are working with invalid data. There must be an >identifier of some kind. Why is it that IETF can change the definition on for example what characters are allowed in host names whitout an identifer of some kind, but cannot define how to handle undefined parts of a protocol? All programs created following original RFCs break when it later is changed. For example, the URI definition have changed making those applications following the original specification reject what later revisions see as valid URIs. From the areas I am interested in it looks like it is OK to change an existing specification as long as you work with ASCII characters, but when moving to non-ASCII characters you either have to create something new or add tags/identifiers. I do not understand why people are so afraid of allowing non-ASCII without complex handling. I have used non-ASCII in several IETF proticols for many years without problem even though the standards are very unclear on how to use them. Dan From owner-idn@ops.ietf.org Fri May 31 13:09:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22764 for ; Fri, 31 May 2002 13:09:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Dph2-000K2e-00 for idn-data@psg.com; Fri, 31 May 2002 09:56:00 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Dph1-000K2X-00 for idn@ops.ietf.org; Fri, 31 May 2002 09:55:59 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Dpgw-000Pdd-00; Fri, 31 May 2002 16:55:54 +0000 Date: Fri, 31 May 2002 12:55:53 -0400 From: John C Klensin To: "Eric A. Hall" , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <140776359.1022849753@localhost> In-Reply-To: <3CF6C9E8.197F8346@ehsco.com> References: <3CF6C9E8.197F8346@ehsco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 30 May, 2002 19:55 -0500 "Eric A. Hall" wrote: >... > That's one way to read it. Another way to read it is that all > of the codepoints are opaque, except that ASCII ranges A-Z and > a-z are to be treated as case-neutral for the purposes of > comparison ONLY. Which is, in fact, exactly what RFC 1035 says. Eric, In the interest of making progress in this discussion (if that is possible at all), can I ask that you, and others, try to avoid statements like "exactly what RFC 1035 says". Many of us, even among those who believe that RFC 2181 settled the issue definitively, believe that 1035 is a bit unclear. And, even when I suspend disbelief and accept that 1035 intended "binary labels" to be accepted in any RR, I'd suggest that your interpretation is not obvious from 1035. I would suggest, instead, that you would need to define three types of labels: * ASCII-only, interpreted with case-matching * Character, but not necessarily ASCII, interpreted with case-matching in the 0x00 to 0x7F range and as absolute matches outside that range. * Binary, which had best not be subject to case-matching comparisons because they might be, e.g., unsigned numbers. I think we can agree that 1035 gives little or no advice about how to interpret such labels, although it is clear that they can exist, at least for as-yet-undefined RR types or Classes. My problem is that I don't know how to tell the three cases apart (except by looking at RR type or Class definitions). If you believe that only the first two cases exist (which is what your comments seem to imply), then the first is a special case of the second and all is well... except that 1034 and 1035 clearly (at least to me) provide for binary content, which would not get case-dependent interpretation. If you believe, as I do, that only the first and third cases exist, then there is still a problem, since a binary label could reasonably have every 8th bit turned off, making it indistinguishable from the ASCII ones. And that is, it seems to me, the solution to the dilemna that Dan poses. Regardless of whether it would be a good idea, it would be plausible for IETF to come along at this point and say something much more definitive than 2181 does. One form of that might be: Heretofore, as defined by at least one reading of RFC 1034/ 1035, the labels associated with A, MX, TXT, SRV, etc., RRs in Class IN consisted of ASCII characters, with labels containing octets outside the ASCII range being treated as undefined (note, the label, not the octet) and their use being non-standard. Henceforth, octets with values greater than 0x7F are permitted in labels for those RR types. Octets with values from 0x00 to 0x7F are to be compared as specified in RFC 1035, i.e., case-independently for ASCII graphic characters. Octets with values from 0x80 to 0xFF are to be compared directly, i.e., without any mapping or translation. Such labels, and the associated RRs, will be described, for convenience, as "character labels" and "character RRs". Future RRs and Classes may be defined so that their labels are binary, i.e., that they are to be interpreted without consideration of the content or possible mappings of any octet. New RRs MUST indicate whether their labels are "character" or "binary"; new Classes MUST specify some appropriate rule, i.e., either specification on a per-label basis or a single rule for the Class. Personally, I don't particularly like the above rule, since it would give us case-independence for ASCII, but case-dependency for all other scripts and languages that make distinctions. That strikes me as a really bad idea, one that would cause far more trouble in the future. But it is a decision and change the IETF could logically make. More generally, if we are trying to _change_ a rule, or specify a rule where none existed, I think we need to do two things. The first is to be sure that our change is compatible and acceptable, either by identifying the new case as different from the old (such as with a label) or by assuring ourselves that the previous behavior was undefined and non-standard and that we can therefore safely specify a behavior. The latter probably requires looking at usage, not just text of documents, but it should still be possible and, as Dan points out, we have done it in the past. Second, we should be very clear that we are making a change. We should avoid replacing ambiguous or contradictory text with new text that claims to clarify or not change anything but that, intentionally or not, involves tricky reading that later permits people to come back and say "well, we got this into Proposed Standard by claiming it wasn't a change, but it now specifies what was previously unspecified". If nothing else, the latter approach tends to lead to a very poor level of specification, such as whether a label that contains octets in both the 0x00-0x7F and 0x80-0xFF ranges is to be interpreted as "binary" or with different comparision rules on a per-octet basis. Similarly, we should avoid pretending that cases that were never anticipated, and that have odd effects at the margins, were really what was intended all along. FWIW, there is also a small performance issue here, which people seem to be ignoring. If I know a label is all ASCII graphics and is to be compared on a case-matching basis, I can mask off the high bits (on an atomic full-string basis on some hardware) and then do a full-string compare (again, in hardware on much hardware). If I know it is "binary", then I can skip the masking and do a full-string compare. But, if some octets are to be treated a ASCII, and some as binary, I need to construct a loop and examine each octet in turn to figure out how to compare it. Not a good idea if it can be avoided. john From owner-idn@ops.ietf.org Fri May 31 13:34:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23442 for ; Fri, 31 May 2002 13:34:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DqDH-000LPj-00 for idn-data@psg.com; Fri, 31 May 2002 10:29:19 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17DqDG-000LPd-00 for idn@ops.ietf.org; Fri, 31 May 2002 10:29:18 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 94596; Fri, 31 May 2002 12:29:24 -0500 Message-ID: <3CF7B2EA.87026DAB@ehsco.com> Date: Fri, 31 May 2002 12:29:14 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CF6C9E8.197F8346@ehsco.com> <140776359.1022849753@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > My problem is that I don't know how to tell the three cases > apart (except by looking at RR type or Class definitions). If > you believe [...] What I believe is that DNS systems store and exchange raw octet values. Secondary to that point, the only time that ASCII enters into the equation is when the octet values need to be interpreted, as in: (1) the 7-bit values are rendered for display, and (2) the 7-bit values in the A-Z and a-z ranges from ASCII are compared. In all other cases, the data is treated as simple octet values. This includes ASCII character values (NB the case-specific storage rules), the non-character ASCII values, and the eight-bit non-interpreted codes. Tertiary to that point, the rules for hostnames are recommendations which act as a higher-layer octet-range mask, but this does not change the storage and transfer formats, nor does it change the interpretation rules. Instead it only defines a reasonable subset of characters with high probabilities of successful interpretation. In short, all code values in the DNS database and message are treated as octets. If a domain name contains a seven-bit code, that value must be treated as a precise ASCII character. If a domain contains an eight-bit code, then that code must be treated as undefined data. If the domain name needs to be compared with another domain name, all of the codes must be treated as eight-bit values, with the exception of the A-Z and a-z ranges. I also believe that it is entirely possible for people to think way too much about this. Finally, I also believe that any subsequent discussion on this matter should be directed to namedroppers. This WG is not the proper forum for any advancement of this discussion. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri May 31 14:58:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27388 for ; Fri, 31 May 2002 14:58:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DrOu-000OmZ-00 for idn-data@psg.com; Fri, 31 May 2002 11:45:24 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 17DrOu-000OmT-00 for idn@ops.ietf.org; Fri, 31 May 2002 11:45:24 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/TW5crSiAOWZV4w2aGUCJAw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G36LJAU9; Fri, 31 May 2002 14:44:08 EDT To: ehall@ehsco.com Cc: klensin@jck.com, idn@ops.ietf.org Date: Fri, 31 May 2002 11:43:01 -0700 Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020531.114302.1216.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-23,25-85 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric: Now that I can see where your stand comes from. 7-bit vs. 8-bit interpretation can be compared at many points of our internet transmission, or we say at many layers our communication model. In the old days, the layers were not very clear to many, and we handle 8-bit data at keyboard input level, which later continues from the wire of keyboards to the wire of internet. At this point, we trying to use only 7-bit interpretation as the standard to insure the stability and easy handling of internet security, from the bottom up, while trying to conver the 8-bit data onto the 7-bit label at some levels agreeable to implementors, service providers and the users. An 8-bit interpretation to be a standard is only possible after we can get 7-bit IDN implemented and proved to be stable. Let us leave the 8-bit interpretation undefined for now, so that we can move on. Liana On Fri, 31 May 2002 12:29:14 -0500 "Eric A. Hall" writes: > > John C Klensin wrote: > > > My problem is that I don't know how to tell the three cases > > apart (except by looking at RR type or Class definitions). If > > you believe [...] > > What I believe is that DNS systems store and exchange raw octet > values. > > Secondary to that point, the only time that ASCII enters into the > equation > is when the octet values need to be interpreted, as in: (1) the > 7-bit > values are rendered for display, and (2) the 7-bit values in the A-Z > and > a-z ranges from ASCII are compared. In all other cases, the data is > treated as simple octet values. This includes ASCII character values > (NB > the case-specific storage rules), the non-character ASCII values, > and the > eight-bit non-interpreted codes. > > Tertiary to that point, the rules for hostnames are recommendations > which > act as a higher-layer octet-range mask, but this does not change the > storage and transfer formats, nor does it change the interpretation > rules. > Instead it only defines a reasonable subset of characters with high > probabilities of successful interpretation. > > In short, all code values in the DNS database and message are > treated as > octets. If a domain name contains a seven-bit code, that value must > be > treated as a precise ASCII character. If a domain contains an > eight-bit > code, then that code must be treated as undefined data. If the > domain name > needs to be compared with another domain name, all of the codes must > be > treated as eight-bit values, with the exception of the A-Z and a-z > ranges. > > I also believe that it is entirely possible for people to think way > too > much about this. > > Finally, I also believe that any subsequent discussion on this > matter > should be directed to namedroppers. This WG is not the proper forum > for > any advancement of this discussion. > > -- > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > From owner-idn@ops.ietf.org Fri May 31 17:28:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05254 for ; Fri, 31 May 2002 17:28:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DtoL-0005aN-00 for idn-data@psg.com; Fri, 31 May 2002 14:19:49 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17DtoK-0005a9-00 for idn@ops.ietf.org; Fri, 31 May 2002 14:19:48 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g4VLJcWa009305 for ; Fri, 31 May 2002 23:19:39 +0200 To: IETF idn working group Subject: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt References: <200205231129.HAA04661@ietf.org> <20020528221203.GC24925@nicemice.net> <20020530212528.GA32634@nicemice.net> From: Simon Josefsson Date: Fri, 31 May 2002 23:19:39 +0200 In-Reply-To: <20020530212528.GA32634@nicemice.net> ("Adam M. Costello"'s message of "Thu, 30 May 2002 21:25:28 +0000") Message-ID: Lines: 24 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > Simon Josefsson wrote: > >> > When systems use local character sets other than ASCII >> > and Unicode, this specification leaves the transcoding >> > problem up to the application. If applications implement >> > different transcoding rules, they could interpret the same name >> > differently and contact different servers. This problem is not >> > solved by security protocols like TLS that do not take local >> > character sets into account. >> >> Before the last sentence it could be useful to also add something >> like: "Furthermore, if a single application uses one mapping table >> in one version, and a subsequent version of the application uses >> a modified mapping table, different interpretations of the same >> internationalized text string may be possible even within the same >> application which has security implications." > > How about simply changing "applications" to "different applications (or > different versions of one application)"? Yes, that would be clearer. What do the editors think about adopting these changes? From owner-idn@ops.ietf.org Fri May 31 20:50:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07595 for ; Fri, 31 May 2002 20:50:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17DwaR-000DHY-00 for idn-data@psg.com; Fri, 31 May 2002 17:17:39 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17DwaP-000DGX-00 for idn@ops.ietf.org; Fri, 31 May 2002 17:17:38 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g510HBOI002559; Sat, 1 Jun 2002 10:17:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206010017.g510HBOI002559@drugs.dv.isc.org> To: liana Ye Cc: ehall@ehsco.com, klensin@jck.com, idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt In-reply-to: Your message of "Fri, 31 May 2002 11:43:01 MST." <20020531.114302.1216.1.liana.ydisg@juno.com> Date: Sat, 01 Jun 2002 10:17:11 +1000 Sender: owner-idn@ops.ietf.org Precedence: bulk Below is the wire to presentation table from RFC 1034 / 1035 for label octets. BIND also escapses '"' but that is not strictly required. 00 \000 01 \001 02 \002 03 \003 04 \004 05 \005 06 \006 07 \007 08 \008 09 \009 0a \010 0b \011 0c \012 0d \013 0e \014 0f \015 10 \016 11 \017 12 \018 13 \019 14 \020 15 \021 16 \022 17 \023 18 \024 19 \025 1a \026 1b \027 1c \028 1d \029 1e \030 1f \031 20 \032 21 ! 22 " 23 # 24 \$ 25 % 26 & 27 ' 28 \( 29 \) 2a * 2b + 2c , 2d - 2e \. 2f / 30 0 31 1 32 2 33 3 34 4 35 5 36 6 37 7 38 8 39 9 3a : 3b \; 3c < 3d = 3e > 3f ? 40 \@ 41 A 42 B 43 C 44 D 45 E 46 F 47 G 48 H 49 I 4a J 4b K 4c L 4d M 4e N 4f O 50 P 51 Q 52 R 53 S 54 T 55 U 56 V 57 W 58 X 59 Y 5a Z 5b [ 5c \\ 5d ] 5e ^ 5f _ 60 ` 61 a 62 b 63 c 64 d 65 e 66 f 67 g 68 h 69 i 6a j 6b k 6c l 6d m 6e n 6f o 70 p 71 q 72 r 73 s 74 t 75 u 76 v 77 w 78 x 79 y 7a z 7b { 7c | 7d } 7e ~ 7f \127 80 \128 81 \129 82 \130 83 \131 84 \132 85 \133 86 \134 87 \135 88 \136 89 \137 8a \138 8b \139 8c \140 8d \141 8e \142 8f \143 90 \144 91 \145 92 \146 93 \147 94 \148 95 \149 96 \150 97 \151 98 \152 99 \153 9a \154 9b \155 9c \156 9d \157 9e \158 9f \159 a0 \160 a1 \161 a2 \162 a3 \163 a4 \164 a5 \165 a6 \166 a7 \167 a8 \168 a9 \169 aa \170 ab \171 ac \172 ad \173 ae \174 af \175 b0 \176 b1 \177 b2 \178 b3 \179 b4 \180 b5 \181 b6 \182 b7 \183 b8 \184 b9 \185 ba \186 bb \187 bc \188 bd \189 be \190 bf \191 c0 \192 c1 \193 c2 \194 c3 \195 c4 \196 c5 \197 c6 \198 c7 \199 c8 \200 c9 \201 ca \202 cb \203 cc \204 cd \205 ce \206 cf \207 d0 \208 d1 \209 d2 \210 d3 \211 d4 \212 d5 \213 d6 \214 d7 \215 d8 \216 d9 \217 da \218 db \219 dc \220 dd \221 de \222 df \223 e0 \224 e1 \225 e2 \226 e3 \227 e4 \228 e5 \229 e6 \230 e7 \231 e8 \232 e9 \233 ea \234 eb \235 ec \236 ed \237 ee \238 ef \239 f0 \240 f1 \241 f2 \242 f3 \243 f4 \244 f5 \245 f6 \246 f7 \247 f8 \248 f9 \249 fa \250 fb \251 fc \252 fd \253 fe \254 ff \255 Below is the table use to compare label octets in wire form by indexing into the table and then comparing the resulting mappings. As it maps to "lowercase" it is also the DNSSEC mapping table. two labels are equal if there lengths are equal and there mapped values are equal. e.g. /* compare uncompressed label */ int equal(unsigned char *l1, unsigned char *l2) { int i; /* uncompressed labels? */ INSIST(*l1 <= 63 && *l2 <= 63); /* caller is broken */ if (*l1 != *l2) return (0); for (i = 1; i <= l1[0]; i++) if (dnssec[l1[i]] != dnssec[l2[i]]) return(0); return (1); } char dnssec[] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 0x40, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f, 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f, 0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf, 0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf, 0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf, 0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff }; Whether you like the wording of RFC 1034/1035 the real world implements RFC 1034/1035 this way. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org