From owner-idn@ops.ietf.org Fri Feb 1 01:15: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 BAA23842 for ; Fri, 1 Feb 2002 01:15:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WWjM-000OGJ-00 for idn-data@psg.com; Thu, 31 Jan 2002 21:59:24 -0800 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by psg.com with esmtp (Exim 3.33 #1) id 16WWjL-000OGD-00 for idn@ops.ietf.org; Thu, 31 Jan 2002 21:59:23 -0800 Received: from DougEwell2@cs.com by imo-m02.mx.aol.com (mail_out_v31_r1.26.) id i.63.5cd1e78 (661) for ; Fri, 1 Feb 2002 00:59:11 -0500 (EST) From: DougEwell2@cs.com Message-ID: <63.5cd1e78.298b88af@cs.com> Date: Fri, 1 Feb 2002 00:59:11 EST Subject: Re: [idn] MUST/SHOULD vs. must/should To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: CompuServe 2000 32-bit sub 113 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 2002-01-31 13:45:46 Pacific Standard Time, idn.amc+0@nicemice.net.RemoveThisWord writes: > Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc? If > there is anyone else, please speak up now. I never thought it made any difference whether "must" was capitalized; it still means "must" either way. Furthermore, I find all-capitalization of ordinary words annoying, sort of like those computer magazines of the '80s like COMPUTE! that always reminded you to "SAVE a copy before you RUN it." OTOH, one of the software QA guys at my work thinks capitalizing "MUST" is a terrific idea, because it draws your eye to the actual requirements (as opposed to non-normative background information). So maybe he knows something I don't. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Fri Feb 1 02:04: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 CAA28164 for ; Fri, 1 Feb 2002 02:04:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WXd6-0000wr-00 for idn-data@psg.com; Thu, 31 Jan 2002 22:57:00 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16WXd4-0000wk-00 for idn@ops.ietf.org; Thu, 31 Jan 2002 22:56:58 -0800 Received: (qmail 29159 invoked by uid 104); 1 Feb 2002 06:56:57 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.830228 secs); 01 Feb 2002 06:56:57 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 06:56:56 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4320]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <232745@heaven.internal.realnames.com> for ; Thu, 31 Jan 2002 10:52:25 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 22:56:29 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195CF@trestles.internal.realnames.com> From: Yves Arrouye To: idn@ops.ietf.org Subject: RE: [idn] MUST/SHOULD vs. must/should Date: Thu, 31 Jan 2002 22:54:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > > Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc? If > > there is anyone else, please speak up now. MUST/SHOULD/etc. (should be ETC. ;)). Too much tradition there, we're used to vgrep for them in RFCs and other documents. YA From owner-idn@ops.ietf.org Fri Feb 1 02:08: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 CAA01302 for ; Fri, 1 Feb 2002 02:07:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WXaU-0000od-00 for idn-data@psg.com; Thu, 31 Jan 2002 22:54:18 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16WXaR-0000o5-00 for idn@ops.ietf.org; Thu, 31 Jan 2002 22:54:15 -0800 Received: (qmail 29118 invoked by uid 104); 1 Feb 2002 06:54:14 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.828389 secs); 01 Feb 2002 06:54:14 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 06:54:13 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4222]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <232737@heaven.internal.realnames.com> for ; Thu, 31 Jan 2002 10:49:53 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 22:53:57 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> From: Yves Arrouye To: "'Michel Suignard'" , Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: RE: [idn] stringprep comment 1 Date: Thu, 31 Jan 2002 22:51:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > Not a chance. Unicode and ISO 10646 collect in fact some unneeded crumbs > that way. Once a character is officially approved for inclusion it is > there forever, whatever we don't like it or not. Characters get > deprecated (i.e. usage discouraged) but never removed. This is the price > you have to pay for stability and usage by other specification (like > IDN). Sorry, I did not mean removed from Unicode (I am aware of the rule there, which makes sense), I meant one character that is added to Unicode but that a given Stringprep profile would think desirable to remove. As for case folding, as soon as one adds a new case mapping in the Nameprep profile, one needs to upgrade clients at the same time as servers. Oops. Encoding the Nameprep version in queries would solve that, but obviously at the cost of some other meaningful info in the label, thus reducing the length of IDN names. YA From owner-idn@ops.ietf.org Fri Feb 1 04:02: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 EAA05801 for ; Fri, 1 Feb 2002 04:02:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WZOr-0006Vf-00 for idn-data@psg.com; Fri, 01 Feb 2002 00:50:25 -0800 Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com) by psg.com with esmtp (Exim 3.33 #1) id 16WZOp-0006VY-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 00:50:23 -0800 Received: from [10.1.1.90] (confmad-isdn.cisco.com [10.49.42.193]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA00928 for ; Fri, 1 Feb 2002 09:50:07 +0100 (MET) Date: Fri, 01 Feb 2002 09:46:24 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: idn@ops.ietf.org Subject: Re: [idn] MUST/SHOULD vs. must/should Message-ID: <2535442.1012556784@localhost> In-Reply-To: <63.5cd1e78.298b88af@cs.com> References: <63.5cd1e78.298b88af@cs.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) 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 2002-02-01 00.59 -0500 DougEwell2@cs.com wrote: >> Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc? If >> there is anyone else, please speak up now. > > I never thought it made any difference whether "must" was capitalized; it > still means "must" either way. The IESG prefer words which have meaning defined in RFC 2119 are to be in all-caps. Other use of the same words are to be lowercase. paf Speaking as IESG member (but not AD for this wg) From owner-idn@ops.ietf.org Fri Feb 1 04:07: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 EAA06068 for ; Fri, 1 Feb 2002 04:07:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WZU5-0006kP-00 for idn-data@psg.com; Fri, 01 Feb 2002 00:55:49 -0800 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.33 #1) id 16WZTz-0006kD-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 00:55:43 -0800 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GQUJIA00.QNH; Fri, 1 Feb 2002 16:56:34 +0800 Message-ID: <003a01c1aafd$ebc52c20$4607e29f@xiaodonglee> Reply-To: "Xiaodong LEE" From: "xiaodong lee" To: Cc: , , Subject: [idn] Requirements of Chinese Domain Name Date: Fri, 1 Feb 2002 16:53:29 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0038_01C1AB40.F9C86100" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C1AB40.F9C86100 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBJRVRGJklETiBXRzoNCiANCiAgICBBdHRhY2htZW50IGlzIG91ciBkcmFmdCBhYm91dCBS ZXF1aXJlbWVudHMgb2YgQ2hpbmVzZSBEb21haW4gTmFtZVtWZXJzaW9uMDBdLCB3aGljaCBkZWZp bmVzIHRoZSByZXF1aXJlbWVudCBvZiBDaGluZXNlIGRvbWFpbiBuYW1lLg0KICAgIFdlIGRvIHdp c2ggaXQgd2lsbCBoZWxwZnVsIGZvciB5b3UgdG8gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbXMuDQog ICAgVGhhbmtzIGZvciBhbnkgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzIQ0KIA0KTGkgTWluZyBU c2VuZyxIbyBKYW4tTWluZyxYaWFuZyBEZW5nLCBLZW5ueSBIdWFuZyxFcmluIENoZW4sIA0KWGlh by1Eb25nIExlZSwgR3VvTmlhbiBTdW4NCkNOTklDJlRXTklDJkNETkMNCiANCg== ------=_NextPart_000_0038_01C1AB40.F9C86100 Content-Type: text/plain; name="draft-ietf-idn-CDNReq-00.txt" Content-Disposition: attachment; filename="draft-ietf-idn-CDNReq-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Authors: Li Ming Tseng Ho Jan-Ming Jan 1, 2002 Xiang Deng Expires in six months Kenny Huang Erin Chen Xiao-Dong Lee GuoNian Sun Requirements of Chinese Domain Name Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1. Premise to be emphasized All requirements of such memo focus on the requirements of Traditional and Simplified Chinese Domain Name Equivalence Matching and delimiter folding. So which is important in this paper is not the definition of Chinese Domain Name but that Internationalized Domain Name SHOULD satisfy such requirements. Any Internationalized Domain Name that includes any character defined by [1] and appendix A SHOULD satisfy such requirements, no matter what character is included in all the labels of it. That is, for any IDN-aware application with IDNA support, if it is CDN-aware too, it should check if the domain name inputted is defined by [1] and appendix A, furthermore, it SHOULD satisfy the requirements defined in this memo. 2. Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119[6]. "TC" is an abbreviation for Traditional Chinese. "SC" is an abbreviation for Simplified Chinese. "CDN" is defined as an acronym of Chinese Domain Name that represents internationalized domain name, which contains at least one Chinese character. As to the scope of Chinese character, please refer to ISO/IEC 10646-1:2000(E) [second edition 2000-09-15], if one character is marked "C and G-Hanzi-T", it MUST be a Chinese character, such definition does not mean it is not the character of other countries that use HAN ideograph. "Equivalent CDN" is defined as CDNs that have at least one character from SC-TC tables [1]. "TC-only CDN" is a CDN that all characters of all its labels are TC characters. "SC-only CDN" is a CDN that all characters of all its labels are SC characters. "Mixed-use TC and SC CDN" is a CDN that in all labels of the domain name, at least one traditional and one simplified Chinese character appear. 3. Problems Traditional Chinese and Simplified Chinese themselves are not a problem. It is a fact of life. If IDN does not deal with this fact, then it isn't a complete solution. There are mainly four problems associated with CDN as follows: [1] TC and SC CDN equivalent matching SC is derived from TC, and Chinese people use both SC and TC. So Chinese people consider that TC CDN as being equivalent to its corresponding SC forms. [2] Mixed-use TC and SC CDN cause an exponential problem If we want to ensure a CDN in both TC/SC forms to be resolved correctly, we could register all combinations with mixed equivalent TC and SC characters. But, along with the length of a label, the number of different combinations grows exponentially. An ordinary Chinese domain name may have dozens, hundreds, even thousands of TC/SC records. That is unreasonable for users to register, and is also difficult for administrators to manage. [3] Registration and delegation of multiple equivalent CDN Without the support of proper delegation and resolution architecture, when a user registers a Chinese domain name, he may have to obtain many forms of it and must operate many domains. The lower level delegation domain name servers may adopt a different domain administrative policy which differs from the one adopted by the upper level, Consistency of TC/SC domain names then can't be ensured. [4] Multiple possible periods (e.g. U+3002 , U+2022, U+FF0E) In Mainland China, there is a different period other than dot. While user input Chinese domain name, he or she types the delimiter of domain name, and he or she will certainly get period (such as: U+3002). In Taiwan Chinese IME, user might type or copy and paste U+2022 or U+FF0E as the delimiter. 4. Requirements 4.1 Requirements of Traditional and Simplified Chinese Domain Name [1] Traditional/Simplified CDN solution MUST be consistent for all CDN users, including but not limited to end users and administrators. [2] The need to do multiple registrations and delegation for an equivalent CDN MUST be minimized. There MUST be only one registration for equivalent CDN. The delegation(s) for an equivalent CDN MUST be consistent. [3] Equivalent CDN SHOULD be treated as equivalent in IDN comparison. [4] Applications that support CDN MAY display the equivalent CDN to users depending on the priority order of user preference followed by default original form and then lastly ACE fallback. [5] Implementation of IDN that supports CDN MUST preserve the original form of CDN. [6] IDN requirements MUST accommodate CDN user requirements. 4.2 Requirement of Delimiter Folding [1] U+3002, U+2022, and U+FF0E MUST be treated as domain names delimiter. 5. Wish List [1] We wish that every implementation would support CDN if and when there is an IDN standard. [2] We wish to see a quick conclusion to the CDN/IDN standardization process. [3] We wish software to have the capability to support both Traditional and Simplified CDN. 6. Authors Li Ming Tseng, tsenglm@cc.ncu.edu.tw, TWNIC Ho Jan-Ming, hoho@iis.sinica.edu.tw, TWNIC Xiang Deng, deng@cnnic.net.cn, CNNIC Kenny Huang, huangk@sinica.edu.tw, TWNIC Erin Chen, erin@twnic.net.tw, TWNIC Xiao-Dong Lee, lee@cnnic.net.cn, CNNIC GuoNian Sun, sun@cnnic.net.cn, CNNIC 7. Acknowledgement The original list of problems, requirements and wish list are derived from the result of the consensus of 7th JET meeting held on Nov 19th, 2001 in Beijing. Thanks for all participants of the meeting. Moreover, some persons as follows are high appreciated. Shian-Shyong Tseng Wen-Sung Chen Wenhui Zhang Wei Mao Hualin Qian 8. References [1] A Complete Set of Simplified Chinese Characters, published in 1986 by the Committee of National Language and Chinese Character of China. [2] Dictionary of Chinese Character Variants, compiled by Mandarin Promotion Council of Taiwan. Version 2 was published in Aug 2001 on Web site. http://140.111.1.40/ [3] Paul Hoffman, Marc Blanchet, " Stringprep Profile for Internationalized Host Names" September 27, 2001, draft-hoffman-stringprep-00.txt [4] Patrik Falstrom, Paul Hoffman, "Internationalizing Host Names In Applications (IDNA)", July 20, 2001, draft-ietf-idn-idna-06.txt [5] The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/unicode/standard/standard.html. [6] Scott Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997, RFC 2119. [7] ISO/IEC 10646-1:2000(E). International Standard - Information technology -- Universal Multiple-Octet Coded Character Set (UCS) Appendix A. Delimiter Set U+3002 U+2022 U+FF0E ------=_NextPart_000_0038_01C1AB40.F9C86100-- From owner-idn@ops.ietf.org Fri Feb 1 05:32: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 FAA13435 for ; Fri, 1 Feb 2002 05:32:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WarI-000AsL-00 for idn-data@psg.com; Fri, 01 Feb 2002 02:23:52 -0800 Received: from twnic.net.tw ([211.72.210.250]) by psg.com with esmtp (Exim 3.33 #1) id 16WarG-000AsC-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 02:23:50 -0800 Received: from twnic.net.tw (pc160.twnic.net.tw [211.72.211.160]) by twnic.net.tw (8.9.3/8.9.3) with ESMTP id SAA25162; Fri, 1 Feb 2002 18:23:08 +0800 Message-ID: <3C5A6DAE.9040905@twnic.net.tw> Date: Fri, 01 Feb 2002 18:27:58 +0800 From: Erin Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: IESG , IAB , IETF IDN WG , "Vinton G. Cerf" , "Masanobu Katoh <" , John klensin , harald , Fred baker , Stuart Lynn , Paul Haffman , Mohamed Sharil Tarmizi , JET Members , Thomas Narten , Erik Nordmark , Andrew McLaughlin , "H. T. Kung" , Marc Blanchet , James Seng/Personal , Masanobu Katoh , Mouhamet Diop , Patrik F?lstr?m , Qiheng Hu , Sang-Hyon Kyong , Elisabeth Porteneuve CC: hlqian , mao , Zhang Wen Hui , xiang deng , xiaodong lee , "=?Big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?=" , hoho , Kenny Huang , Chun-Hsin Wu , sstseng , Wen-Sung Chen , Nai-Wen Hsu , yktham , jasonho , alanysho , christine Subject: [idn] Chinese Domain Name Consortium (CDNC) Declaration Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------- Chinese Domain Name Consortium (CDNC) Declaration ------------------------------------------------------------------------- Based on current status of Internationalized Domain Name, CDNC makes following declaration: 1. Currently, IETF IDN WG begins Last Call for the WG core documents (IDNA, NAMEPREP, STRINGPREP, and PUNYCODE). But, the architecture of IDN defined in above four documents does not solve the traditional and simplified Chinese character variant problem. That will cause serious delegation problem in the application of Chinese Domain Name. This technical flaw can't be compensated by registration policy; it'll prevent Chinese Domain Name from being used widely. All the future Internet applications based on Chinese Domain Name hierarchy will fail and ultimately Chinese Domain Name technology will result in failure. 2. Under the commercial and social pressure, IETF IDN WG issues Last Call hastily without presenting a proper Chinese Domain Name technical solution. It will be detrimental to the ethnic-Chinese Internet community. 3. IETF IDN WG does not solve Chinese Domain Name technical problem, but it is IETF IDN WG's responsibility to sincerely consider the consequences from adopting these drafts. Under the current condition, if IETF approves these IDN drafts, registrars will open Chinese Domain Name registration without considering the requirement of Chinese Domain Name and Chinese Domain Name will fall into confusion. This will damage Chinese Internet community seriously. 4. IDN would be flawed by not adopting CDN requirements. Chinese Domain Name Consortium CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC Co-chair of CDNC: Qian Hualin, Professor Co-chair of CDNC: Shian-Shyong Tseng, Professor 2002.2.1 --------------------------------------------------------------------------- From owner-idn@ops.ietf.org Fri Feb 1 11:33: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 LAA02353 for ; Fri, 1 Feb 2002 11:33:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WgNH-000PyR-00 for idn-data@psg.com; Fri, 01 Feb 2002 08:17:15 -0800 Received: from rwcrmhc51.attbi.com ([204.127.198.38]) by psg.com with esmtp (Exim 3.33 #1) id 16WgNG-000PyL-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 08:17:14 -0800 Received: from c1340594a ([12.234.216.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020201161713.CXNJ26243.rwcrmhc51.attbi.com@c1340594a>; Fri, 1 Feb 2002 16:17:13 +0000 Message-ID: <006a01c1ab3c$376248a0$08d8ea0c@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Yves Arrouye" , "'Michel Suignard'" , "Paul Hoffman / IMC" Cc: References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> Subject: Re: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 08:19:25 -0800 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 Stringprep keeps its own tables. What any implementation of Unicode needs to do if they want to maintain strict backwards compatibility for case folding is to only *add* to tables in the future, not change the values of characters that are already in the tables. While it is extremely unlikely that Unicode will make a change that causes problems for nameprep, using the above strategy guarantees backwards compatibility. To repeat, the loose vs strict approach works as follows: Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As long as the client produces names that are only 3.1, no problem. Stringprep on the client will produce results that the server accepts. Suppose the user has characters that are unassigned in 3.1 (but are in 4.0). As long as the user (manually) picks lowercase characters (in the right canonical form), those names will be accepted by the 4.0 server. While it is not as easy as when the software does it for the user, it will work for any new characters. This is important for another scenario. Client A is on Unicode 4.0, client B is on Unicode 3.1, and the server is on Unicode 4.0. Client A namepreps a string, sends to client B. Client B sends the string on to the server. Everything works. It even works if client B re-namepreps the string. Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "Yves Arrouye" To: "'Michel Suignard'" ; "Paul Hoffman / IMC" Cc: Sent: Thursday, January 31, 2002 22:51 Subject: RE: [idn] stringprep comment 1 > > Not a chance. Unicode and ISO 10646 collect in fact some unneeded crumbs > > that way. Once a character is officially approved for inclusion it is > > there forever, whatever we don't like it or not. Characters get > > deprecated (i.e. usage discouraged) but never removed. This is the price > > you have to pay for stability and usage by other specification (like > > IDN). > > Sorry, I did not mean removed from Unicode (I am aware of the rule there, > which makes sense), I meant one character that is added to Unicode but that > a given Stringprep profile would think desirable to remove. > > As for case folding, as soon as one adds a new case mapping in the Nameprep > profile, one needs to upgrade clients at the same time as servers. Oops. > Encoding the Nameprep version in queries would solve that, but obviously at > the cost of some other meaningful info in the label, thus reducing the > length of IDN names. > > YA > > > > From owner-idn@ops.ietf.org Fri Feb 1 11:38: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 LAA02570 for ; Fri, 1 Feb 2002 11:38:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WgU4-0000Bt-00 for idn-data@psg.com; Fri, 01 Feb 2002 08:24:16 -0800 Received: from [211.218.145.193] (helo=postel2) by psg.com with esmtp (Exim 3.33 #1) id 16WgU3-0000Bm-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 08:24:16 -0800 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g11GO8R27013 for idn@ops.ietf.org; Sat, 2 Feb 2002 01:24:08 +0900 To: "IETF idn working group" Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g11GO6627010 for ; Sat, 2 Feb 2002 01:24:06 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 X-Msmail-Priority: Normal Message-Id: <00b101c1ab3c$d6821000$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 2 From: "Soobok Lee" X-Priority: 3 References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net> <098801c1a9ff$43f2ba20$ec1bd9d2@temp> <20020131220302.GA22764@nicemice.net> X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 01:23:52 +0900 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjEwcHQnPgoK LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAKRnJvbSYjNTg7ICJBZGFt IE0uIENvc3RlbGxvIiA8aWRuLmFtYyswQG5pY2VtaWNlLm5ldC5SZW1vdmVU aGlzV29yZD4KVG8mIzU4OyAiSUVURiBpZG4gd29ya2luZyBncm91cCIgPGlk bkBvcHMuaWV0Zi5vcmc+ClNlbnQmIzU4OyBGcmlkYXksIEZlYnJ1YXJ5IDAx LCAyMDAyIDcmIzU4OzAzIEFNClN1YmplY3QmIzU4OyBSZSYjNTg7IFtpZG5d IHN0cmluZ3ByZXAgY29tbWVudCAyCgoKPiBUaGlzIG1lc3NhZ2UgYXJndWVz IGJvdGggc2lkZXMgb2YgdGhlIGlzc3VlLiAgJiM1ODspCj4gCj4gU29vYm9r IExlZSA8bHNiQHBvc3RlbC5jby5rcj4gd3JvdGUmIzU4Owo+IAo+ID4gVGhl IGxhdHRlciBjYW4gYmUgYXMgY2F0YXN0cm9waGljIGFzIHRoZSBmb3JtZXIu Cj4gCj4gSSBhc3N1bWUgeW91IG1lYW50IHRoYXQgZmFsc2UgbmVnYXRpdmVz ICh3aGVyZSBuYW1lcyBkb24ndCBtYXRjaCB3aGVuCj4gdGhleSBzaG91bGQp IGNhbiBiZSBhcyBjYXRhc3Ryb3BoaWMgYXMgZmFsc2UgcG9zaXRpdmVzICh3 aGVyZSBuYW1lcwo+IG1hdGNoIHdoZW4gdGhleSBzaG91bGRuJ3QpLiAgQ2Fu IHlvdSBiYWNrIHVwIHRoYXQgY2xhaW0/CiAKIApmYWxzZSBwb3N0aXZlcyBy ZXN1bHQgaW4gImVycm9ycyIuCmZhbHNlIG5lZ2F0aXZlIHJlc3VsdCBpbiAi ZmFpbHVyZXMiLCBsaWtlIHNodXRkb3duIG9mIGF1dGhvcml0YWl2ZSBETlMg c2VydmVycy4KCmVuZCB1c2VycyBvZiBvbGQgY2xpZW50cyB3b3VsZCBtZWV0 CiJob3N0IG5vdCBmb3VuZCIsICJlbWFpbCBhZGRyZXNzIGlzIG5vdCBmb3Vu ZCIgZmFpbHR1cmUgbm90aWNlcy4KVGhleSB3aWxsIGJlIHJlamVjdGVkIHRv IGFjY2VzcyB0aGUgZGVzaXJlZCBpbmZvcm1hdGlvbnMvcmVzb3VyY2VzL3Bl b3BsZSBpbiBhIHRpbWVseSBtYW5uZXIsCmV2ZW4gd2l0aG91dCBhbnkgY2x1 ZXMvZXhwbGFuYXRpb25zIHRvIHN1Y2ggZmFpbHVyZXMuIFRoZXkgd2lsbCBi ZSBnZXQgbG9zdCBhbmQgYmUgZnJ1c3RyYXRlZC4KIApQZXJtYW5lbnQvdGVt cG9yYXJ5IHNodXRkb3duIG9mIHRoZSAxMyByb290IHNlcnZlcnMgYXJlIG5v dCBlcnJvcnMsIGJ1dCBjYXRhc3Ryb3BoaWMgLgoKU29vYm9rIExlZQoKCjwv UFJFPgo8aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVh ZC8xMDEyNTgwNjMyLWViNDE5ODRlMzkwMDhhMzA0YTE1MzQ4YTg4OGMzMDIy LjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBv c3RlbC50byB3aWR0aD0xIGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K From owner-idn@ops.ietf.org Fri Feb 1 12:01: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 MAA03616 for ; Fri, 1 Feb 2002 12:01:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wgx5-00015d-00 for idn-data@psg.com; Fri, 01 Feb 2002 08:54:15 -0800 Received: from [211.218.145.193] (helo=postel2) by psg.com with esmtp (Exim 3.33 #1) id 16Wgx4-00014n-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 08:54:14 -0800 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g11Gs0927906 for idn@ops.ietf.org; Sat, 2 Feb 2002 01:54:00 +0900 To: "IETF idn working group" Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g11Grx627902 for ; Sat, 2 Feb 2002 01:53:59 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 X-Msmail-Priority: Normal Message-Id: <00ca01c1ab41$02ff6340$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 2 From: "Soobok Lee" X-Priority: 3 References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net> <098801c1a9ff$43f2ba20$ec1bd9d2@temp> <20020131220302.GA22764@nicemice.net> <008801c1aaa5$1a7a8f50$08d8ea0c@c1340594a> X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 01:53:44 +0900 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjEwcHQnPgoK LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAKRnJvbSYjNTg7ICJNYXJr IERhdmlzIiA8bWFya0BtYWNjaGlhdG8uY29tPgpUbyYjNTg7ICJJRVRGIGlk biB3b3JraW5nIGdyb3VwIiA8aWRuQG9wcy5pZXRmLm9yZz4KU2VudCYjNTg7 IEZyaWRheSwgRmVicnVhcnkgMDEsIDIwMDIgNyYjNTg7MTcgQU0KU3ViamVj dCYjNTg7IFJlJiM1ODsgW2lkbl0gc3RyaW5ncHJlcCBjb21tZW50IDIKCgo+ IFRoZSBjb21wYXJpc29uIG9mIGxvb3NlIHZzIGxvb3NlIHNob3VsZCBuZXZl ciBiZSBkb25lLCBmb3IgdGhlIHJlYXNvbnMKPiB5b3Ugb3V0bGluZS4gVGhh dCBsZWF2ZXMKPiAKPiBhKSBzdHJpY3QgdnMgc3RyaWN0Cj4gYikgc3RyaWN0 IHZzIGxvb3NlCj4gCj4gKGEpIGlzIGFsd2F5cyBzYWZlLgo+IAo+IChiKSB3 b3JrcyBmb3Igc2l0dWF0aW9ucyBsaWtlIEROUywgd2hlcmUgdGhlcmUgaXMg YSBzZXJ2ZXIgb24gb25lIHNpZGUKPiBzdG9yaW5nIHN0cmljdCBrZXlzLCBh bmQgcXVlcmllcyBhcmUgbWFkZSBvbiB0aGUgb3RoZXIgYW5kIG1heSBiZQo+ IGxvb3NlIG9yIHN0cmljdC4gSXQgd291bGQgd29yayBmb3Igc2ltaWxhciBz aXR1YXRpb25zLCBzdWNoIGFzIGVtYWlsLAo+IGlmIGF0IG9uZSBlbmQgdGhl cmUgaXMgYSBzZXJ2ZXIgdGhhdCBkb2VzIHZhbGlkYXRpb24gKG9mLCBpbiB0 aGlzCj4gY2FzZSwgZW1haWwgbmFtZXMpLgogCkluICBWQ0FSRCAsIFAzUCAs IE1TTiBQYXNzcG9ydCBvciBhZGRyZXNzYm9vayBlbnRyeSBmb3JtLCAKYnkg d2hhdCBjcml0ZXJpYSBjYW4gd2UgZGVjaWRlICB3aGljaCBuYW1lcHJlcCAg dGhlIGlucHV0IGVtYWlsIGFkZHJlc3NlcyAKc2hvdWxkIGdvIHRocm91Z2gg JiM1ODsgIHN0cmljdCBuYW1lcHJlcCBvciBsb29zZSBuYW1lcHJlcCA/CgpU aGUgc2FtZSBxdWVzdGlvbiBpcyB2YWxpZCBmb3IgIHRoZSAgc2VuZGVycycg ZW1haWwgYWRkcmVzc2VzICAKICAgaW4gUkZDODIyICJGcm9tJiM1ODsiIGhl YWRlciB2YWx1ZXMgYW5kICBpbiBTTVRQICJNQUlMIEZST00mIzU4OyIgIGhl YWRlciB2YWx1ZXMgICAsCiAgaW4gaW5zdGFudCB3ZWItYmFzZWQgRk9STU1B SUwgc3VibWlzc2lvbnMgYW5kCiAgaW4gam9iIGFwcGxpY2F0aW9ucyBmb3Jt cy4KCkluIHRoZXJlIGFueSBwb3NzaWJpbGl0eSB0aGF0IGFueSBJRE4gbGFi ZWxzICB3aGljaCBhcmUgaW50ZW5kZWQgYXMgInF1ZXJpZXMiIGFuZCBldmVy IGluamVjdGVkIGludG8gdGhlIGludGVybmV0CmZyb20gb25lIGFwcGxpY2F0 aW9uICwgYmVjb21lIHBlcm1hbmVudC9wZXJzaXN0YW50IGlkZW50aWZpZXJz IAphdCBvdGhlciBhcHBsaWNhdGlvbnM/ICBBQ0UgbGFiZWxzIGNhcnJ5ICBu byBzdWNoIGNvbnRleHQgZHVyaW5nIHRoZWlyIHRyaXAgdGhyb3VnaCBvdXQg dGhpZXIgbGlmZSB0aW1lIAppbiB0aGUgaW50ZXJjb25uZWN0ZWQgYXBwbGlj YXRpb25zLiAgSG93IGNhbiB3ZSBwcmV2ZW50ICBibGluZCB0cnVzdHMgb3Ig bWlzdXNlcyBvZiAicXVlcmllcyI/CgpTb29ib2sgTGVlCgoKPC9QUkU+Cjxp bWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5jby5rci9yZWFkLzEwMTI1 ODI0MjQtZWI0MTk4NGUzOTAwOGEzMDRhMTUzNDhhODg4YzMwMjIuNDFlNWZk NmYxOTdlYmMxMC9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRv IHdpZHRoPTEgaGVpZ2h0PTE+CjwvQk9EWT4KPC9IVE1MPgo= From owner-idn@ops.ietf.org Fri Feb 1 12:13: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 MAA04401 for ; Fri, 1 Feb 2002 12:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WhAZ-0001UX-00 for idn-data@psg.com; Fri, 01 Feb 2002 09:08:11 -0800 Received: from [211.218.145.193] (helo=postel2) by psg.com with esmtp (Exim 3.33 #1) id 16WhAX-0001UR-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 09:08:10 -0800 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g11H82Z28361 for idn@ops.ietf.org; Sat, 2 Feb 2002 02:08:02 +0900 To: idn@ops.ietf.org Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g11H81628358 for ; Sat, 2 Feb 2002 02:08:01 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 X-Msmail-Priority: Normal Message-Id: <00de01c1ab42$f8fd0fd0$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 From: "Soobok Lee" X-Priority: 3 References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> <006a01c1ab3c$376248a0$08d8ea0c@c1340594a> X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 02:07:47 +0900 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjEwcHQnPgoK LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tJiM1ODsgIk1hcmsg RGF2aXMiIDxtYXJrQG1hY2NoaWF0by5jb20+ClRvJiM1ODsgIll2ZXMgQXJy b3V5ZSIgPHl2ZXNAcmVhbG5hbWVzLmNvbT47ICInTWljaGVsIFN1aWduYXJk JyIgPG1pY2hlbHN1QG1pY3Jvc29mdC5jb20+OyAiUGF1bCBIb2ZmbWFuIC8g SU1DIiA8cGhvZmZtYW5AaW1jLm9yZz4KQ2MmIzU4OyA8aWRuQG9wcy5pZXRm Lm9yZz4KU2VudCYjNTg7IFNhdHVyZGF5LCBGZWJydWFyeSAwMiwgMjAwMiAx JiM1ODsxOSBBTQpTdWJqZWN0JiM1ODsgUmUmIzU4OyBbaWRuXSBzdHJpbmdw cmVwIGNvbW1lbnQgMQoKCj4gU3RyaW5ncHJlcCBrZWVwcyBpdHMgb3duIHRh Ymxlcy4gV2hhdCBhbnkgaW1wbGVtZW50YXRpb24gb2YgVW5pY29kZQo+IG5l ZWRzIHRvIGRvIGlmIHRoZXkgd2FudCB0byBtYWludGFpbiBzdHJpY3QgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkKPiBmb3IgY2FzZSBmb2xkaW5nIGlzIHRv IG9ubHkgKmFkZCogdG8gdGFibGVzIGluIHRoZSBmdXR1cmUsIG5vdCBjaGFu Z2UKPiB0aGUgdmFsdWVzIG9mIGNoYXJhY3RlcnMgdGhhdCBhcmUgYWxyZWFk eSBpbiB0aGUgdGFibGVzLgo+Cj4gV2hpbGUgaXQgaXMgZXh0cmVtZWx5IHVu bGlrZWx5IHRoYXQgVW5pY29kZSB3aWxsIG1ha2UgYSBjaGFuZ2UgdGhhdAo+ IGNhdXNlcyBwcm9ibGVtcyBmb3IgbmFtZXByZXAsIHVzaW5nIHRoZSBhYm92 ZSBzdHJhdGVneSBndWFyYW50ZWVzCj4gYmFja3dhcmRzIGNvbXBhdGliaWxp dHkuCj4KPiBUbyByZXBlYXQsIHRoZSBsb29zZSB2cyBzdHJpY3QgYXBwcm9h Y2ggd29ya3MgYXMgZm9sbG93cyYjNTg7Cj4KPiBTdXBwb3NlIHRoZSBjbGll bnQgaXMgVW5pY29kZSAzLjEgYW5kIHRoZSBzZXJ2ZXIgaXMgVW5pY29kZSA0 LjAuIEFzCj4gbG9uZyBhcyB0aGUgY2xpZW50IHByb2R1Y2VzIG5hbWVzIHRo YXQgYXJlIG9ubHkgMy4xLCBubyBwcm9ibGVtLgo+IFN0cmluZ3ByZXAgb24g dGhlIGNsaWVudCB3aWxsIHByb2R1Y2UgcmVzdWx0cyB0aGF0IHRoZSBzZXJ2 ZXIgYWNjZXB0cy4KPgo+IFN1cHBvc2UgdGhlIHVzZXIgaGFzIGNoYXJhY3Rl cnMgdGhhdCBhcmUgdW5hc3NpZ25lZCBpbiAzLjEgKGJ1dCBhcmUgaW4KPiA0 LjApLiBBcyBsb25nIGFzIHRoZSB1c2VyIChtYW51YWxseSkgcGlja3MgbG93 ZXJjYXNlIGNoYXJhY3RlcnMgKGluCj4gdGhlIHJpZ2h0IGNhbm9uaWNhbCBm b3JtKSwgdGhvc2UgbmFtZXMgd2lsbCBiZSBhY2NlcHRlZCBieSB0aGUgNC4w Cj4gc2VydmVyLiBXaGlsZSBpdCBpcyBub3QgYXMgZWFzeSBhcyB3aGVuIHRo ZSBzb2Z0d2FyZSBkb2VzIGl0IGZvciB0aGUKPiB1c2VyLCBpdCB3aWxsIHdv cmsgZm9yIGFueSBuZXcgY2hhcmFjdGVycy4KPgo+IFRoaXMgaXMgaW1wb3J0 YW50IGZvciBhbm90aGVyIHNjZW5hcmlvLiBDbGllbnQgQSBpcyBvbiBVbmlj b2RlIDQuMCwKPiBjbGllbnQgQiBpcyBvbiBVbmljb2RlIDMuMSwgYW5kIHRo ZSBzZXJ2ZXIgaXMgb24gVW5pY29kZSA0LjAuIENsaWVudCBBCj4gbmFtZXBy ZXBzIGEgc3RyaW5nLCBzZW5kcyB0byBjbGllbnQgQi4gQ2xpZW50IEIgc2Vu ZHMgdGhlIHN0cmluZyBvbiB0bwo+IHRoZSBzZXJ2ZXIuIEV2ZXJ5dGhpbmcg d29ya3MuIEl0IGV2ZW4gd29ya3MgaWYgY2xpZW50IEIgcmUtbmFtZXByZXBz Cj4gdGhlIHN0cmluZy4KCldvdWxkIHlvdSBjbGFyaWZ5IHlvdXIgYXNzZXJ0 aW9uIGZvciBwZWVyLXRvLXBlZXIgdHJhbnNhY3Rpb25zID8KCkV2ZW4gaW4g c29tZSBjbGllbnQgdG8gc2VydmVyIHRyYW5zYWN0aW9ucywgc2VydmVyIHNp ZGVzIG1heSBoYXZlCm5vIHBlcnNpc3RhbnQvc3RvcmVkIHN0cmluZ3MgKG5v dC1hdXRob3JpdGF0aXZlKSAgdG8gY29tcGFyZSBhZ2FpbnN0IHRoZSBxdWVy aWVzLCBidXQKanVzdCBzdG9yZSBhbmQgdHJ1c3Qgb3IgdHJhbnNtaXQgd2l0 aG91dCBnaXZpbmcgYmFjayBubyBuZWdhdGl2ZSByZXNwb25zZS4uCgpTb29i b2sgTGVlCgo+Cj4gTWFyawo+IOKAlOKAlOKAlOKAlOKAlAo+Cj4gzqDPjM67 zrvigJkg4bygz4DOr8+Dz4TOsc+Ezr8g4byUz4HOs86xLCDOus6xzrrhv7bP giDOtOKAmSDhvKDPgM6vz4PPhM6xz4TOvyDPgM6szr3PhM6xIOKAlCDhvYnO vM6uz4HOv8+FIM6czrHPgc6zzq/PhOG/gwo+IFtGb3IgdHJhbnNsaXRlcmF0 aW9uLCBzZWUgaHR0cCYjNTg7Ly9vc3Muc29mdHdhcmUuaWJtLmNvbS9jZ2kt YmluL2ljdS90cl0KPgo+IGh0dHAmIzU4Oy8vd3d3Lm1hY2NoaWF0by5jb20K Pgo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tJiM1ODsg Ill2ZXMgQXJyb3V5ZSIgPHl2ZXNAcmVhbG5hbWVzLmNvbT4KPiBUbyYjNTg7 ICInTWljaGVsIFN1aWduYXJkJyIgPG1pY2hlbHN1QG1pY3Jvc29mdC5jb20+ OyAiUGF1bCBIb2ZmbWFuIC8gSU1DIgo+IDxwaG9mZm1hbkBpbWMub3JnPgo+ IENjJiM1ODsgPGlkbkBvcHMuaWV0Zi5vcmc+Cj4gU2VudCYjNTg7IFRodXJz ZGF5LCBKYW51YXJ5IDMxLCAyMDAyIDIyJiM1ODs1MQo+IFN1YmplY3QmIzU4 OyBSRSYjNTg7IFtpZG5dIHN0cmluZ3ByZXAgY29tbWVudCAxCj4KPgo+ID4g PiBOb3QgYSBjaGFuY2UuIFVuaWNvZGUgYW5kIElTTyAxMDY0NiBjb2xsZWN0 IGluIGZhY3Qgc29tZSB1bm5lZWRlZAo+IGNydW1icwo+ID4gPiB0aGF0IHdh eS4gT25jZSBhIGNoYXJhY3RlciBpcyBvZmZpY2lhbGx5IGFwcHJvdmVkIGZv ciBpbmNsdXNpb24gaXQKPiBpcwo+ID4gPiB0aGVyZSBmb3JldmVyLCB3aGF0 ZXZlciB3ZSBkb24ndCBsaWtlIGl0IG9yIG5vdC4gQ2hhcmFjdGVycyBnZXQK PiA+ID4gZGVwcmVjYXRlZCAoaS5lLiB1c2FnZSBkaXNjb3VyYWdlZCkgYnV0 IG5ldmVyIHJlbW92ZWQuIFRoaXMgaXMgdGhlCj4gcHJpY2UKPiA+ID4geW91 IGhhdmUgdG8gcGF5IGZvciBzdGFiaWxpdHkgYW5kIHVzYWdlIGJ5IG90aGVy IHNwZWNpZmljYXRpb24KPiAobGlrZQo+ID4gPiBJRE4pLgo+ID4KPiA+IFNv cnJ5LCBJIGRpZCBub3QgbWVhbiByZW1vdmVkIGZyb20gVW5pY29kZSAoSSBh bSBhd2FyZSBvZiB0aGUgcnVsZQo+IHRoZXJlLAo+ID4gd2hpY2ggbWFrZXMg c2Vuc2UpLCBJIG1lYW50IG9uZSBjaGFyYWN0ZXIgdGhhdCBpcyBhZGRlZCB0 byBVbmljb2RlCj4gYnV0IHRoYXQKPiA+IGEgZ2l2ZW4gU3RyaW5ncHJlcCBw cm9maWxlIHdvdWxkIHRoaW5rIGRlc2lyYWJsZSB0byByZW1vdmUuCj4gPgo+ ID4gQXMgZm9yIGNhc2UgZm9sZGluZywgYXMgc29vbiBhcyBvbmUgYWRkcyBh IG5ldyBjYXNlIG1hcHBpbmcgaW4gdGhlCj4gTmFtZXByZXAKPiA+IHByb2Zp bGUsIG9uZSBuZWVkcyB0byB1cGdyYWRlIGNsaWVudHMgYXQgdGhlIHNhbWUg dGltZSBhcyBzZXJ2ZXJzLgo+IE9vcHMuCj4gPiBFbmNvZGluZyB0aGUgTmFt ZXByZXAgdmVyc2lvbiBpbiBxdWVyaWVzIHdvdWxkIHNvbHZlIHRoYXQsIGJ1 dAo+IG9idmlvdXNseSBhdAo+ID4gdGhlIGNvc3Qgb2Ygc29tZSBvdGhlciBt ZWFuaW5nZnVsIGluZm8gaW4gdGhlIGxhYmVsLCB0aHVzIHJlZHVjaW5nCj4g dGhlCj4gPiBsZW5ndGggb2YgSUROIG5hbWVzLgo+ID4KPiA+IFlBCj4gPgo+ ID4KPiA+Cj4gPgo+Cgo8L1BSRT4KPGltZyBzcmM9aHR0cDovL3Bvc3RlbDIu cG9zdGVsLmNvLmtyL3JlYWQvMTAxMjU4MzI2Ny0yYWY0MWM2MTkxNjA5MjNk YTU5NGZjNmU3NGRiMThjYy40MWU1ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMuaWV0 Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT4KPC9C T0RZPgo8L0hUTUw+Cg== From owner-idn@ops.ietf.org Fri Feb 1 12:22: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 MAA04772 for ; Fri, 1 Feb 2002 12:22:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WhIC-0001nW-00 for idn-data@psg.com; Fri, 01 Feb 2002 09:16:04 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16WhIB-0001nQ-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 09:16:03 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11HG0310481 for ; Fri, 1 Feb 2002 09:16:00 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> Date: Fri, 1 Feb 2002 09:02:38 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: RE: [idn] stringprep comment 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:51 PM -0800 1/31/02, Yves Arrouye wrote: >As for case folding, as soon as one adds a new case mapping in the Nameprep >profile, one needs to upgrade clients at the same time as servers. Oops. Could you give an example of this? Why would we ever want to add a new casefolding rule for a current character? Adding a casefolding rule for a *new* character should not make a difference because the new character is not yet stored in domain names. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 1 12:26: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 MAA04891 for ; Fri, 1 Feb 2002 12:26:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WhMb-0001xA-00 for idn-data@psg.com; Fri, 01 Feb 2002 09:20:37 -0800 Date: Fri, 01 Feb 2002 09:09:35 -0800 To: Erin Chen From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: IESG , IAB , IETF IDN WG , "Vinton G. Cerf" , Masanobu Katoh , John klensin , harald , Fred baker , Stuart Lynn , Paul Haffman , Mohamed Sharil Tarmizi , JET Members , Thomas Narten , Erik Nordmark , Andrew McLaughlin , "H. T. Kung" , Marc Blanchet , James Seng/Personal , Masanobu Katoh , Mouhamet Diop , Patrik F?lstr?m , Qiheng Hu , Sang-Hyon Kyong , Elisabeth Porteneuve , hlqian , mao , Zhang Wen Hui , xiang deng , xiaodong lee , "=?Big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?="@psg.com Message-Id: , hoho , Kenny Huang , Chun-Hsin Wu , sstseng , Wen-Sung Chen , Nai-Wen Hsu , yktham , jasonho , alanysho , christine In-Reply-To: <3C5A6DAE.9040905@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 06:27 PM 2/1/2002 +0800, Erin Chen wrote: >But, the architecture of IDN defined in above four documents does not >solve the traditional and simplified Chinese character variant problem. There are many things the IDN specifications do not do. Rather, the specifications focus on solving satisfying only the requirement they are supposed to satisfy. Solution of TC/SC is one example of equivalence among Unicode sets. Indeed, IDN does not attempt to specify such equivalences. Equivalence among separate Unicode sets is essentially an open technical topic for which there are no accepted practises. Still, this topic has been discussed, debated and explained extensively within the IDN working group. . The purpose of IDN is to permit use of an increased range of characters in domain name, beyond the current limit of ASCII. It is not the goal of the working group to invent character set conventions such as equivalence between different sets. It will be wonderful when equivalence between sets is achieved. However it is not the charter of IDN to solve basic issues of character set equivalence and it is not reasonable to delay the utility of the character set enhancement specified by IDN, in the hope that some day the question of character set equivalence is achieved. Contrary to the claim that the working group is moving too quickly, my own guess is that it has been a major source of delay for the working group for at least 6 months. Perhaps much longer. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Fri Feb 1 12:28: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 MAA04940 for ; Fri, 1 Feb 2002 12:28:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WhK2-0001rm-00 for idn-data@psg.com; Fri, 01 Feb 2002 09:17:58 -0800 Date: Fri, 01 Feb 2002 09:09:35 -0800 To: Erin Chen From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: IESG , IAB , IETF.IDN.WG Message-Id: , "Vinton G. Cerf" , Masanobu Katoh , John klensin , harald , Fred baker , Stuart Lynn , Paul Haffman , Mohamed Sharil Tarmizi , JET Members , Thomas Narten , Erik Nordmark , Andrew McLaughlin , "H. T. Kung" , Marc Blanchet , James Seng/Personal , Masanobu Katoh , Mouhamet Diop , Patrik F?lstr?m , Qiheng Hu , Sang-Hyon Kyong , Elisabeth Porteneuve , hlqian , mao , Zhang Wen Hui , xiang deng , xiaodong lee , "=?Big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?=" , hoho , Kenny Huang , Chun-Hsin Wu , sstseng , Wen-Sung Chen , Nai-Wen Hsu , yktham , jasonho , alanysho , christine In-Reply-To: <3C5A6DAE.9040905@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 06:27 PM 2/1/2002 +0800, Erin Chen wrote: >But, the architecture of IDN defined in above four documents does not >solve the traditional and simplified Chinese character variant problem. There are many things the IDN specifications do not do. Rather, the specifications focus on solving satisfying only the requirement they are supposed to satisfy. Solution of TC/SC is one example of equivalence among Unicode sets. Indeed, IDN does not attempt to specify such equivalences. Equivalence among separate Unicode sets is essentially an open technical topic for which there are no accepted practises. Still, this topic has been discussed, debated and explained extensively within the IDN working group. . The purpose of IDN is to permit use of an increased range of characters in domain name, beyond the current limit of ASCII. It is not the goal of the working group to invent character set conventions such as equivalence between different sets. It will be wonderful when equivalence between sets is achieved. However it is not the charter of IDN to solve basic issues of character set equivalence and it is not reasonable to delay the utility of the character set enhancement specified by IDN, in the hope that some day the question of character set equivalence is achieved. Contrary to the claim that the working group is moving too quickly, my own guess is that it has been a major source of delay for the working group for at least 6 months. Perhaps much longer. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Fri Feb 1 12:28: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 MAA04966 for ; Fri, 1 Feb 2002 12:28:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WhNy-0001yU-00 for idn-data@psg.com; Fri, 01 Feb 2002 09:22:02 -0800 Date: Fri, 01 Feb 2002 09:09:35 -0800 To: Erin Chen From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: IESG , IAB , IETF IDN WG , "Vinton G. Cerf" , Masanobu Katoh , John klensin , harald , Fred baker , Stuart Lynn , Paul Haffman , Mohamed Sharil Tarmizi , JET Members , Thomas Narten , Erik Nordmark , Andrew McLaughlin , "H. T. Kung" , Marc Blanchet , James Seng/Personal , Masanobu Katoh , Mouhamet Diop , Patrik F?lstr?m , Qiheng Hu , Sang-Hyon Kyong , Elisabeth Porteneuve , hlqian , mao , Zhang Wen Hui , xiang deng , xiaodong lee , , hoho , Kenny Huang , Chun-Hsin Wu , sstseng , Wen-Sung Chen , Nai-Wen Hsu , yktham , jasonho , alanysho , christine In-Reply-To: <3C5A6DAE.9040905@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: At 06:27 PM 2/1/2002 +0800, Erin Chen wrote: >But, the architecture of IDN defined in above four documents does not >solve the traditional and simplified Chinese character variant problem. There are many things the IDN specifications do not do. Rather, the specifications focus on solving satisfying only the requirement they are supposed to satisfy. Solution of TC/SC is one example of equivalence among Unicode sets. Indeed, IDN does not attempt to specify such equivalences. Equivalence among separate Unicode sets is essentially an open technical topic for which there are no accepted practises. Still, this topic has been discussed, debated and explained extensively within the IDN working group. . The purpose of IDN is to permit use of an increased range of characters in domain name, beyond the current limit of ASCII. It is not the goal of the working group to invent character set conventions such as equivalence between different sets. It will be wonderful when equivalence between sets is achieved. However it is not the charter of IDN to solve basic issues of character set equivalence and it is not reasonable to delay the utility of the character set enhancement specified by IDN, in the hope that some day the question of character set equivalence is achieved. Contrary to the claim that the working group is moving too quickly, my own guess is that it has been a major source of delay for the working group for at least 6 months. Perhaps much longer. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Fri Feb 1 13:14: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 NAA06410 for ; Fri, 1 Feb 2002 13:14:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Why1-0003z7-00 for idn-data@psg.com; Fri, 01 Feb 2002 09:59:17 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16Why0-0003yr-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 09:59:16 -0800 Received: (qmail 21925 invoked by uid 104); 1 Feb 2002 17:59:15 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.820599 secs); 01 Feb 2002 17:59:15 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 17:59:14 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:2406]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <234804@heaven.internal.realnames.com> for ; Fri, 1 Feb 2002 9:54:36 AM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 09:58:40 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195D3@trestles.internal.realnames.com> From: Yves Arrouye To: "'Mark Davis'" , "'Michel Suignard'" , Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: RE: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 09:56:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > To repeat, the loose vs strict approach works as follows: > > Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As > long as the client produces names that are only 3.1, no problem. > Stringprep on the client will produce results that the server accepts. > > Suppose the user has characters that are unassigned in 3.1 (but are in > 4.0). As long as the user (manually) picks lowercase characters (in > the right canonical form), those names will be accepted by the 4.0 > server. While it is not as easy as when the software does it for the > user, it will work for any new characters. > > This is important for another scenario. Client A is on Unicode 4.0, > client B is on Unicode 3.1, and the server is on Unicode 4.0. Client A > namepreps a string, sends to client B. Client B sends the string on to > the server. Everything works. It even works if client B re-namepreps > the string. The interesting scenario is: Server S is on Nameprep-08 (where a deletion mapping has been introduced for codepoint U+XXXXX), Client A is on Nameprep-07 but his OS supports Unicode 4.0 and its IME generates U+XXXXX. Client A will then pas U+XXXXX unchanged (since it was unassigned when Nameprep-07's tables were generated) and Server S won't find a match, since its stored strings do not have U+XXXXX. Same for case mapping, if that were to happen. The user has no clue what is happening to her. YA From owner-idn@ops.ietf.org Fri Feb 1 13:57: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 NAA08022 for ; Fri, 1 Feb 2002 13:57:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wik6-0005cd-00 for idn-data@psg.com; Fri, 01 Feb 2002 10:48:58 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Wik5-0005cX-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 10:48:57 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Ims313174 for ; Fri, 1 Feb 2002 10:48:54 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <7FC3066C236FD511BC5900508BAC86FE9195D3@trestles.internal.realnames.com> References: <7FC3066C236FD511BC5900508BAC86FE9195D3@trestles.internal.realnames.com> Date: Fri, 1 Feb 2002 10:48:47 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: RE: [idn] stringprep comment 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 9:56 AM -0800 2/1/02, Yves Arrouye wrote: >The interesting scenario is: Server S is on Nameprep-08 (where a deletion >mapping has been introduced for codepoint U+XXXXX), Client A is on >Nameprep-07 but his OS supports Unicode 4.0 and its IME generates U+XXXXX. >Client A will then pas U+XXXXX unchanged (since it was unassigned when >Nameprep-07's tables were generated) and Server S won't find a match, since >its stored strings do not have U+XXXXX. That scenario will happen, and it is *supposed* to happen. It is identical to if Nameprep-08 mapped U+XXXX to U+XYZX. The client must not get a positive response to a query that includes characters that are not allowed in the version on the authoritative server. > Same for case mapping, if that were >to happen. The user has no clue what is happening to her. Correct. It is identical to a user accidentally entering a Greek capital Alpha instead of a Latin capital A. Or, even if we didn't do IDN, the user accidentally enters numeral 0 instead of Latin capital O. The DNS matching scheme will simply say "no match". In other words, these failure scenarios are not a criticism of the versioning method, they are a criticism of the simple matching in DNS. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 1 16:19: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 QAA12227 for ; Fri, 1 Feb 2002 16:19:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wks7-000A3N-00 for idn-data@psg.com; Fri, 01 Feb 2002 13:05:23 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16Wks6-000A3H-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 13:05:22 -0800 Received: (qmail 2988 invoked by uid 104); 1 Feb 2002 21:05:22 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.820741 secs); 01 Feb 2002 21:05:22 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 21:05:21 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1525]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <235891@heaven.internal.realnames.com> for ; Fri, 1 Feb 2002 1:00:57 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 13:05:02 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195E5@trestles.internal.realnames.com> From: Yves Arrouye To: "'Paul Hoffman / IMC'" , idn@ops.ietf.org Subject: RE: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 13:02:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > At 9:56 AM -0800 2/1/02, Yves Arrouye wrote: > >The interesting scenario is: Server S is on Nameprep-08 (where a deletion > >mapping has been introduced for codepoint U+XXXXX), Client A is on > >Nameprep-07 but his OS supports Unicode 4.0 and its IME generates U+XXXXX. > >Client A will then pas U+XXXXX unchanged (since it was unassigned when > >Nameprep-07's tables were generated) and Server S won't find a match, > since > >its stored strings do not have U+XXXXX. > > That scenario will happen, and it is *supposed* to happen. It is > identical to if Nameprep-08 mapped U+XXXX to U+XYZX. The client must > not get a positive response to a query that includes characters that > are not allowed in the version on the authoritative server. But they *are* allowed because the Server S uses Nameprep-08! > > Same for case mapping, if that were > >to happen. The user has no clue what is happening to her. > > Correct. It is identical to a user accidentally entering a Greek > capital Alpha instead of a Latin capital A. Or, even if we didn't do > IDN, the user accidentally enters numeral 0 instead of Latin capital > O. The DNS matching scheme will simply say "no match". In other > words, these failure scenarios are not a criticism of the versioning > method, they are a criticism of the simple matching in DNS. No this one is a specific critic of IDN breaking the existing DNS "matching must be case insensitive rule." If it is not must (MUST) then maybe it's not an issue. YA From owner-idn@ops.ietf.org Fri Feb 1 16:55: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 QAA12826 for ; Fri, 1 Feb 2002 16:55:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WlYD-000BQf-00 for idn-data@psg.com; Fri, 01 Feb 2002 13:48:53 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16WlYC-000BQZ-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 13:48:52 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Lme318330; Fri, 1 Feb 2002 13:48:48 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <7FC3066C236FD511BC5900508BAC86FE9195E5@trestles.internal.realnames.com> References: <7FC3066C236FD511BC5900508BAC86FE9195E5@trestles.internal.realnames.com> Date: Fri, 1 Feb 2002 13:48:39 -0800 To: Yves Arrouye , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: RE: [idn] stringprep comment 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 1:02 PM -0800 2/1/02, Yves Arrouye wrote: > > At 9:56 AM -0800 2/1/02, Yves Arrouye wrote: >> >The interesting scenario is: Server S is on Nameprep-08 (where a deletion >> >mapping has been introduced for codepoint U+XXXXX), Client A is on >> >Nameprep-07 but his OS supports Unicode 4.0 and its IME generates >U+XXXXX. >> >Client A will then pas U+XXXXX unchanged (since it was unassigned when >> >Nameprep-07's tables were generated) and Server S won't find a match, >> since >> >its stored strings do not have U+XXXXX. >> >> That scenario will happen, and it is *supposed* to happen. It is >> identical to if Nameprep-08 mapped U+XXXX to U+XYZX. The client must >> not get a positive response to a query that includes characters that >> are not allowed in the version on the authoritative server. > >But they *are* allowed because the Server S uses Nameprep-08! I'm misunderstanding your scenario then. You said in nameprep-08, character U+XXXX has a "deleting mapping". I understood that as "character U+XXXX is now assigned but is prohibited". If that's not what you meant, please help me. >No this one is a specific critic of IDN breaking the existing DNS "matching >must be case insensitive rule." If it is not must (MUST) then maybe it's not >an issue. There is no such rule: there is a strong attempt. The Turkish dotless I is an example of where the attempt will inherently fail in one case or the other. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 1 17:01: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 RAA12923 for ; Fri, 1 Feb 2002 17:01:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wlfa-000Bgz-00 for idn-data@psg.com; Fri, 01 Feb 2002 13:56:30 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16WlfZ-000Bgs-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 13:56:30 -0800 Received: (qmail 6085 invoked by uid 104); 1 Feb 2002 21:56:29 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.821058 secs); 01 Feb 2002 21:56:29 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 21:56:28 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:3405]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <236118@heaven.internal.realnames.com> for ; Fri, 1 Feb 2002 1:51:49 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 13:55:53 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195E9@trestles.internal.realnames.com> From: Yves Arrouye To: "'Paul Hoffman / IMC'" , idn@ops.ietf.org Subject: RE: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 13:53:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > >But they *are* allowed because the Server S uses Nameprep-08! > > I'm misunderstanding your scenario then. You said in nameprep-08, > character U+XXXX has a "deleting mapping". I understood that as > "character U+XXXX is now assigned but is prohibited". If that's not > what you meant, please help me. I meant that Nameprep-08 maps the codepoint out (to reuse the language in Nameprep). Let's say because this codepoint is a new variant selector, another zero-width thingamagic, whatever. > >No this one is a specific critic of IDN breaking the existing DNS > "matching > >must be case insensitive rule." If it is not must (MUST) then maybe it's > not > >an issue. > > There is no such rule: there is a strong attempt. The Turkish dotless > I is an example of where the attempt will inherently fail in one case > or the other. OK. Forget the case argument then. (Man, I am glad I won't be at the end of customer support for IDN. And that's not a reflection on the IDN work, just the complexity of the issue and the user expectations.) YA From owner-idn@ops.ietf.org Fri Feb 1 17:19: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 RAA13179 for ; Fri, 1 Feb 2002 17:19:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wlvu-000CEh-00 for idn-data@psg.com; Fri, 01 Feb 2002 14:13:22 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16Wlvt-000CEb-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 14:13:21 -0800 Received: (qmail 7170 invoked by uid 104); 1 Feb 2002 22:13:16 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.819846 secs); 01 Feb 2002 22:13:16 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 22:13:15 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4020]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <236195@heaven.internal.realnames.com> for ; Fri, 1 Feb 2002 2:08:50 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 14:12:54 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195EA@trestles.internal.realnames.com> From: Yves Arrouye To: "'Paul Hoffman / IMC'" , idn@ops.ietf.org Subject: RE: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 14:10:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > At 10:51 PM -0800 1/31/02, Yves Arrouye wrote: > >As for case folding, as soon as one adds a new case mapping in the > Nameprep > >profile, one needs to upgrade clients at the same time as servers. Oops. > > Could you give an example of this? Why would we ever want to add a > new casefolding rule for a current character? Adding a casefolding > rule for a *new* character should not make a difference because the > new character is not yet stored in domain names. Sure. I'll use the same example I just used and used before. Server S runs Nameprep-08. It *does* have names that use this new character, and it has been case folded since Nameprep-08 has a case mapping for it. Client A has an email client using Nameprep-07. At the same time, this email client runs on the latest and greatest which has support for the version of Unicode that is used in Nameprep-08 (and has this new character in both upper and lower case--I am speaking of the Unicode version here). Now, this character (the uppercase one) is typed by the user (since the OS supports it). The email client sees it as being unassigned as far as its Nameprep-07 tables go, and thus pass it unchanged to the server. On the server, there is no match, because the registered string was case folded (since the server uses Nameprep-08). But since you said that DNS makes no guarantee of case mapping (and I guess it's fair to say that if IDNA does not make any guarantee, it doesn't matter what DNS for ASCII did) I guess it's okay. It's just going to be fun when the user registers his IDN with uppercase but cannot use it from his own email client :) It's all about user education... (And fortunately, most people type these things all-lowercase anyway.) YA From owner-idn@ops.ietf.org Fri Feb 1 17:21: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 RAA13209 for ; Fri, 1 Feb 2002 17:21:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WlyX-000CJa-00 for idn-data@psg.com; Fri, 01 Feb 2002 14:16:05 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16WlyW-000CJU-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 14:16:04 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11MG0319549; Fri, 1 Feb 2002 14:16:00 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <7FC3066C236FD511BC5900508BAC86FE9195E9@trestles.internal.realnames.com> References: <7FC3066C236FD511BC5900508BAC86FE9195E9@trestles.internal.realnames.com> Date: Fri, 1 Feb 2002 14:16:00 -0800 To: Yves Arrouye , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: RE: [idn] stringprep comment 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 1:53 PM -0800 2/1/02, Yves Arrouye wrote: > > >But they *are* allowed because the Server S uses Nameprep-08! >> >> I'm misunderstanding your scenario then. You said in nameprep-08, >> character U+XXXX has a "deleting mapping". I understood that as >> "character U+XXXX is now assigned but is prohibited". If that's not >> what you meant, please help me. > >I meant that Nameprep-08 maps the codepoint out (to reuse the language in >Nameprep). Let's say because this codepoint is a new variant selector, >another zero-width thingamagic, whatever. OK, then I did understand what you were saying, but I don't understand the problem. You originally said: The interesting scenario is: Server S is on Nameprep-08 (where a deletion mapping has been introduced for codepoint U+XXXXX), Client A is on Nameprep-07 but his OS supports Unicode 4.0 and its IME generates U+XXXXX. Client A will then pas U+XXXXX unchanged (since it was unassigned when Nameprep-07's tables were generated) and Server S won't find a match, since its stored strings do not have U+XXXXX. Client A sends out a character that will never match something that could be stored in a name server under -07 (because it is unassigned) or under -08 or later (because it is mapped to nothing). Why would you expect the server to ever match it? What is the problem here that you see and that I don't? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 1 17:37: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 RAA13446 for ; Fri, 1 Feb 2002 17:37:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WmBV-000Cmb-00 for idn-data@psg.com; Fri, 01 Feb 2002 14:29:29 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16WmBU-000CmV-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 14:29:28 -0800 Received: (qmail 8056 invoked by uid 104); 1 Feb 2002 22:29:27 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.820626 secs); 01 Feb 2002 22:29:27 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 1 Feb 2002 22:29:26 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4577]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <236263@heaven.internal.realnames.com> for ; Fri, 1 Feb 2002 2:24:41 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 14:28:46 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195EB@trestles.internal.realnames.com> From: Yves Arrouye To: "'Paul Hoffman / IMC'" , idn@ops.ietf.org Subject: RE: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 14:26:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > Client A sends out a character that will never match something that > could be stored in a name server under -07 (because it is unassigned) > or under -08 or later (because it is mapped to nothing). Why would > you expect the server to ever match it? What is the problem here that > you see and that I don't? No I don't expect the server to match it, since it is deleted. All I am saying is that the assumption that has been stated here many times that "an application that uses a former version of Nameprep to speak to a server using a later one has nothing to worry about because it just passes all unassigned codepoints (from its former Nameprep perspective) to the server" is not true. If that assumption is old / has been revised then I am just wasting your bandwidth :) YA From owner-idn@ops.ietf.org Fri Feb 1 17:40: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 RAA13487 for ; Fri, 1 Feb 2002 17:40:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WmGx-000CyX-00 for idn-data@psg.com; Fri, 01 Feb 2002 14:35:07 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16WmGx-000CyQ-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 14:35:07 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11MZ2320402; Fri, 1 Feb 2002 14:35:02 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <7FC3066C236FD511BC5900508BAC86FE9195EB@trestles.internal.realnames.com> References: <7FC3066C236FD511BC5900508BAC86FE9195EB@trestles.internal.realnames.com> Date: Fri, 1 Feb 2002 14:35:02 -0800 To: Yves Arrouye , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: RE: [idn] stringprep comment 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 2:26 PM -0800 2/1/02, Yves Arrouye wrote: > > Client A sends out a character that will never match something that >> could be stored in a name server under -07 (because it is unassigned) >> or under -08 or later (because it is mapped to nothing). Why would >> you expect the server to ever match it? What is the problem here that >> you see and that I don't? > >No I don't expect the server to match it, since it is deleted. All I am >saying is that the assumption that has been stated here many times that "an >application that uses a former version of Nameprep to speak to a server >using a later one has nothing to worry about because it just passes all >unassigned codepoints (from its former Nameprep perspective) to the server" >is not true. If that assumption is old / has been revised then I am just >wasting your bandwidth :) I think so. :-) "Nothing to worry about" means "the server won't falsely give a positive result when it should have been negative". You should worry if the protocol had a state where the client was asking for something that would never exist but the server could mistakenly give a positive answer. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 1 18:02: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 SAA13822 for ; Fri, 1 Feb 2002 18:02:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WmZ0-000Dbv-00 for idn-data@psg.com; Fri, 01 Feb 2002 14:53:46 -0800 Received: from rwcrmhc54.attbi.com ([216.148.227.87]) by psg.com with esmtp (Exim 3.33 #1) id 16WmYz-000Dbo-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 14:53:45 -0800 Received: from c1340594a ([12.234.216.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020201225344.FBWM7443.rwcrmhc54.attbi.com@c1340594a>; Fri, 1 Feb 2002 22:53:44 +0000 Message-ID: <007201c1ab73$9c053420$08d8ea0c@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: , "Soobok Lee" References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> <006a01c1ab3c$376248a0$08d8ea0c@c1340594a> <00de01c1ab42$f8fd0fd0$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 14:55:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C1AB30.8DA957F0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C1AB30.8DA957F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit As discussed before, comparisons only work if you are matching loose vs strict // where the strict is authoritative strict vs strict Simple transmission or store and transmission is not an issue, as long as no comparison is made. Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: Soobok Lee To: idn@ops.ietf.org Sent: Friday, February 01, 2002 09:07 Subject: Re: [idn] stringprep comment 1 ----- Original Message ----- From: "Mark Davis" To: "Yves Arrouye" ; "'Michel Suignard'" ; "Paul Hoffman / IMC" Cc: Sent: Saturday, February 02, 2002 1:19 AM Subject: Re: [idn] stringprep comment 1 > Stringprep keeps its own tables. What any implementation of Unicode > needs to do if they want to maintain strict backwards compatibility > for case folding is to only *add* to tables in the future, not change > the values of characters that are already in the tables. > > While it is extremely unlikely that Unicode will make a change that > causes problems for nameprep, using the above strategy guarantees > backwards compatibility. > > To repeat, the loose vs strict approach works as follows: > > Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As > long as the client produces names that are only 3.1, no problem. > Stringprep on the client will produce results that the server accepts. > > Suppose the user has characters that are unassigned in 3.1 (but are in > 4.0). As long as the user (manually) picks lowercase characters (in > the right canonical form), those names will be accepted by the 4.0 > server. While it is not as easy as when the software does it for the > user, it will work for any new characters. > > This is important for another scenario. Client A is on Unicode 4.0, > client B is on Unicode 3.1, and the server is on Unicode 4.0. Client A > namepreps a string, sends to client B. Client B sends the string on to > the server. Everything works. It even works if client B re-namepreps > the string. Would you clarify your assertion for peer-to-peer transactions ? Even in some client to server transactions, server sides may have no persistant/stored strings (not-authoritative) to compare against the queries, but just store and trust or transmit without giving back no negative response.. Soobok Lee > > Mark > ————— > > Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > http://www.macchiato.com > > ----- Original Message ----- > From: "Yves Arrouye" > To: "'Michel Suignard'" ; "Paul Hoffman / IMC" > > Cc: > Sent: Thursday, January 31, 2002 22:51 > Subject: RE: [idn] stringprep comment 1 > > > > > Not a chance. Unicode and ISO 10646 collect in fact some unneeded > crumbs > > > that way. Once a character is officially approved for inclusion it > is > > > there forever, whatever we don't like it or not. Characters get > > > deprecated (i.e. usage discouraged) but never removed. This is the > price > > > you have to pay for stability and usage by other specification > (like > > > IDN). > > > > Sorry, I did not mean removed from Unicode (I am aware of the rule > there, > > which makes sense), I meant one character that is added to Unicode > but that > > a given Stringprep profile would think desirable to remove. > > > > As for case folding, as soon as one adds a new case mapping in the > Nameprep > > profile, one needs to upgrade clients at the same time as servers. > Oops. > > Encoding the Nameprep version in queries would solve that, but > obviously at > > the cost of some other meaningful info in the label, thus reducing > the > > length of IDN names. > > > > YA > > > > > > > > > ------=_NextPart_000_006E_01C1AB30.8DA957F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
As discussed before, comparisons only = work if you=20 are matching
 
loose vs strict // where the strict is=20 authoritative
strict vs strict
 
Simple transmission or store and = transmission is=20 not an issue, as long as no comparison is made.
 
Mark
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
=CE=A0=CF=8C=CE=BB=CE=BB=E2=80=99 = =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =E1=BC=94=CF=81=CE=B3=CE=B1, =CE=BA=CE=B1=CE=BA=E1=BF=B6=CF=82 = =CE=B4=E2=80=99 =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =CF=80=CE=AC=CE=BD=CF=84=CE=B1 =E2=80=94 = =E1=BD=89=CE=BC=CE=AE=CF=81=CE=BF=CF=85 = =CE=9C=CE=B1=CF=81=CE=B3=CE=AF=CF=84=E1=BF=83
[For=20 transliteration, see http://oss.software.i= bm.com/cgi-bin/icu/tr]
 
----- Original Message -----
From:=20 Soobok = Lee
Sent: Friday, February 01, 2002 = 09:07
Subject: Re: [idn] stringprep = comment=20 1

----- Original Message -----
From: "Mark Davis" 
To: "Yves Arrouye" ; "'Michel Suignard'" =
; "Paul Hoffman / IMC" 
Cc: 
Sent: Saturday, February 02, 2002 1:19 AM
Subject: Re: [idn] stringprep comment 1


> Stringprep keeps its own tables. What any implementation of Unicode
> needs to do if they want to maintain strict backwards compatibility
> for case folding is to only *add* to tables in the future, not =
change
> the values of characters that are already in the tables.
>
> While it is extremely unlikely that Unicode will make a change that
> causes problems for nameprep, using the above strategy guarantees
> backwards compatibility.
>
> To repeat, the loose vs strict approach works as follows:
>
> Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As
> long as the client produces names that are only 3.1, no problem.
> Stringprep on the client will produce results that the server =
accepts.
>
> Suppose the user has characters that are unassigned in 3.1 (but are =
in
> 4.0). As long as the user (manually) picks lowercase characters (in
> the right canonical form), those names will be accepted by the 4.0
> server. While it is not as easy as when the software does it for =
the
> user, it will work for any new characters.
>
> This is important for another scenario. Client A is on Unicode 4.0,
> client B is on Unicode 3.1, and the server is on Unicode 4.0. =
Client A
> namepreps a string, sends to client B. Client B sends the string on =
to
> the server. Everything works. It even works if client B =
re-namepreps
> the string.

Would you clarify your assertion for peer-to-peer transactions ?

Even in some client to server transactions, server sides may have
no persistant/stored strings (not-authoritative)  to compare against the =
queries, but
just store and trust or transmit without giving back no negative =
response..

Soobok Lee

>
> Mark
> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>
> =CE=A0=CF=8C=CE=BB=CE=BB=E2=80=99 =
=E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF =
=E1=BC=94=CF=81=CE=B3=CE=B1, =CE=BA=CE=B1=CE=BA=E1=BF=B6=CF=82 =
=CE=B4=E2=80=99 =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF =
=CF=80=CE=AC=CE=BD=CF=84=CE=B1 =E2=80=94 =
=E1=BD=89=CE=BC=CE=AE=CF=81=CE=BF=CF=85 =
=CE=9C=CE=B1=CF=81=CE=B3=CE=AF=CF=84=E1=BF=83
> [For transliteration, see =
http://oss.software.ibm.com/cgi-bin/icu/tr]
>
> http://www.macchiato.com
>
> ----- Original Message -----
> From: "Yves Arrouye" 
> To: "'Michel Suignard'" ; "Paul Hoffman / =
IMC"
> 
> Cc: 
> Sent: Thursday, January 31, 2002 22:51
> Subject: RE: [idn] stringprep comment 1
>
>
> > > Not a chance. Unicode and ISO 10646 collect in fact some =
unneeded
> crumbs
> > > that way. Once a character is officially approved for =
inclusion it
> is
> > > there forever, whatever we don't like it or not. =
Characters get
> > > deprecated (i.e. usage discouraged) but never removed. =
This is the
> price
> > > you have to pay for stability and usage by other =
specification
> (like
> > > IDN).
> >
> > Sorry, I did not mean removed from Unicode (I am aware of the =
rule
> there,
> > which makes sense), I meant one character that is added to =
Unicode
> but that
> > a given Stringprep profile would think desirable to remove.
> >
> > As for case folding, as soon as one adds a new case mapping in =
the
> Nameprep
> > profile, one needs to upgrade clients at the same time as =
servers.
> Oops.
> > Encoding the Nameprep version in queries would solve that, but
> obviously at
> > the cost of some other meaningful info in the label, thus =
reducing
> the
> > length of IDN names.
> >
> > YA
> >
> >
> >
> >
>
------=_NextPart_000_006E_01C1AB30.8DA957F0-- From owner-idn@ops.ietf.org Fri Feb 1 19:29: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 TAA14840 for ; Fri, 1 Feb 2002 19:29:16 -0500 (EST) From: owner-idn@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WnvX-000GM5-00 for idn-data@psg.com; Fri, 01 Feb 2002 16:21:07 -0800 To: "Mark Davis" , idn@ops.ietf.org Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g120Hn610030; Sat, 2 Feb 2002 09:17:49 +0900 MIME-Version: 1.0 Message-Id: Date: Fri, 01 Feb 2002 16:21:07 -0800 receipt_mdn/1012609056-ad35b82791025b11a594b9684123baf2.41e5fd6f197ebc10 @postel2.postel.co.kr X-Msmail-Priority: Normal Message-Id: <018601c1ab7f$0550c420$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 From: "Postel Services, Inc" X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 09:17:36 +0900 Content-Disposition: inline Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Sender: owner-idn@ops.ietf.org Precedence: bulk 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQu MCBUcmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAt ZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2MDAuMCIg bmFtZT1HRU5FUkFUT1I+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+CjxCT0RZ IGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48U1RST05HPjxGT05UIGZhY2U96rW0 66a8IHNpemU9Mj48L0ZPTlQ+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+CjxCTE9D S1FVT1RFIGRpcj1sdHIgCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVG VDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4KICA8 RElWIHN0eWxlPSJGT05UOiAxMHB0IOq1tOumvCI+LS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSA8L0RJVj4KICA8RElWIAogIHN0eWxlPSJCQUNLR1JP VU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IOq1tOumvDsgZm9udC1jb2xvcjog YmxhY2siPjxCPkZyb206PC9CPiA8QSAKICB0aXRsZT1tYXJrQG1hY2NoaWF0 by5jb20gaHJlZj0ibWFpbHRvOm1hcmtAbWFjY2hpYXRvLmNvbSI+TWFyayBE YXZpczwvQT4gCjwvRElWPgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW0 66a8Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWlkbkBvcHMuaWV0Zi5vcmcgCiAg aHJlZj0ibWFpbHRvOmlkbkBvcHMuaWV0Zi5vcmciPmlkbkBvcHMuaWV0Zi5v cmc8L0E+IDsgPEEgCiAgdGl0bGU9bHNiQHBvc3RlbC5jby5rciBocmVmPSJt YWlsdG86bHNiQHBvc3RlbC5jby5rciI+U29vYm9rIExlZTwvQT4gPC9ESVY+ CiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCDqtbTrprwiPjxCPlNlbnQ6PC9C PiBTYXR1cmRheSwgRmVicnVhcnkgMDIsIDIwMDIgNzo1NSAKICBBTTwvRElW PgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW066a8Ij48Qj5TdWJqZWN0 OjwvQj4gUmU6IFtpZG5dIHN0cmluZ3ByZXAgY29tbWVudCAKMTwvRElWPgog IDxESVY+PEJSPjwvRElWPgogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+QXMgZGlzY3Vzc2VkIGJlZm9yZSwgY29tcGFyaXNvbnMgb25seSB3b3Jr IGlmIHlvdSAKICBhcmUgbWF0Y2hpbmcgPC9GT05UPjwvRElWPgogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgog IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+bG9vc2UgdnMgc3RyaWN0 IC8vIHdoZXJlIHRoZSBzdHJpY3QgaXMgCiAgYXV0aG9yaXRhdGl2ZTwvRk9O VD48L0RJVj4KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPnN0cmlj dCB2cyBzdHJpY3Q8L0ZPTlQ+PC9ESVY+CiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+CiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj5TaW1wbGUgdHJhbnNtaXNzaW9uIG9yIHN0b3Jl IGFuZCB0cmFuc21pc3Npb24gaXMgCiAgbm90IGFuIGlzc3VlLCBhcyBsb25n IGFzIG5vIGNvbXBhcmlzb24gaXMgbWFkZS48L0ZPTlQ+PC9ESVY+CiAgPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgogIDxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JMT0NLUVVPVEU+CjxE SVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+Jm5ic3A7U29tZSBhcHBsaWNhdGlv bnMmbmJzcDsgaW4gdGhlIGVuZCBvZiAKdHJhbnNtaXNzaW9uIHN1cmVseSBk byBjb21wYXJpc29ucyBvbiB0aGVtJm5ic3A7PC9GT05UPjxGT05UIHNpemU9 Mj4mbmJzcDtsYXRlciAKdGltZSBzaWxlbnRseSZuYnNwOy4gPC9GT05UPjwv RElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoZSBpbnRlcm1lZGlh dGUvZmluYWwgYXBwbGljYXRpb25zIG1heSBub3QgZ2l2ZSBiYWNrIAp0aGUg bmVnYXRpdmUgYW5zd2VycyB0byB0aGUgPC9GT05UPjwvRElWPgo8RElWIGRp cj1sdHI+PEZPTlQgc2l6ZT0yPm9yaWdpbmF0aW5nIGVuZCB1c2VycyBpbW1l ZGlhdGVseSBvciBmaW5hbGx5IG9yIGJvdGguIAplZykgc2VuZGluZyBlbWFp bHMgb3IgZW5saXN0aW5nIGluIHRoZSBvbmxpbmUgd2hpdGUgcGFnZS48L0ZP TlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoZWlyIGZh aWx1cmUgaXMgYXMgc2lsZW50IGFzIGFudGhyYXggdGhyZWF0LiAKYW5kPC9G T05UPjwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoYXQnIGxp a2UgYSBsb3N0IGxhbmQgbWluZSB3aGljaCBzb21lIGNpdmlsIApjaGlsZHJl biZuYnNwOyBtYXkgc3RlcCBvbiAuPC9GT05UPjwvRElWPgo8RElWIGRpcj1s dHI+PEZPTlQgc2l6ZT0yPlRoZSBzb2xkaWVycyBkb24ndCBrbm93IHdoYXQm bmJzcDsgaGFwcGVucyB1bnRpbCB0aGV5IApnZXQgcmVwb3J0Jm5ic3A7dGhh dCBzb21lb25lIGxvc3QmbmJzcDsgdGhlaXIgZmVldCBieSB0aGUgbG9zdCAK bWluZS48L0ZPTlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0y PlNvb2JvayBMZWU8L0ZPTlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRy IApzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVw eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4 IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+CiAgPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5NYXJrPC9GT05UPjwvRElWPgogIDxESVY+ 4oCU4oCU4oCU4oCU4oCUPC9ESVY+CiAgPERJVj4mbmJzcDs8L0RJVj4KICA8 RElWPs6gz4zOu8674oCZIOG8oM+Azq/Pg8+EzrHPhM6/IOG8lM+BzrPOsSwg zrrOsc664b+2z4IgzrTigJkg4bygz4DOr8+Dz4TOsc+Ezr8gz4DOrM69z4TO sSDigJQg4b2JzrzOrs+Bzr/PhSDOnM6xz4HOs86vz4Thv4M8QlI+W0ZvciAK ICB0cmFuc2xpdGVyYXRpb24sIHNlZSA8QSAKICBocmVmPSJodHRwOi8vb3Nz LnNvZnR3YXJlLmlibS5jb20vY2dpLWJpbi9pY3UvdHIiPmh0dHA6Ly9vc3Mu c29mdHdhcmUuaWJtLmNvbS9jZ2ktYmluL2ljdS90cjwvQT5dPC9ESVY+CiAg PERJVj4mbmJzcDs8L0RJVj4KICA8RElWPjxBIGhyZWY9Imh0dHA6Ly93d3cu bWFjY2hpYXRvLmNvbSI+aHR0cDovL3d3dy5tYWNjaGlhdG8uY29tPC9BPjxC Uj48L0RJVj4KICA8QkxPQ0tRVU9URSAKICBzdHlsZT0iUEFERElORy1SSUdI VDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsg Qk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+CiAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPgogICAgPERJViAKICAg IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IGFyaWFs OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IAogICAgPEEgdGl0 bGU9bHNiQHBvc3RlbC5jby5rciBocmVmPSJtYWlsdG86bHNiQHBvc3RlbC5j by5rciI+U29vYm9rIExlZTwvQT4gCiAgICA8L0RJVj4KICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4gPEEgdGl0bGU9aWRu QG9wcy5pZXRmLm9yZyAKICAgIGhyZWY9Im1haWx0bzppZG5Ab3BzLmlldGYu b3JnIj5pZG5Ab3BzLmlldGYub3JnPC9BPiA8L0RJVj4KICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIEZl YnJ1YXJ5IDAxLCAyMDAyIAogICAgMDk6MDc8L0RJVj4KICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6PC9CPiBSZTogW2lk bl0gc3RyaW5ncHJlcCBjb21tZW50IAogICAgMTwvRElWPgogICAgPERJVj48 QlI+PC9ESVY+PEZPTlQgc2l6ZT0rMT48UFJFIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KRnJvbTogIk1h cmsgRGF2aXMiIDxNQVJLQE1BQ0NISUFUTy5DT00+ClRvOiAiWXZlcyBBcnJv dXllIiA8WVZFU0BSRUFMTkFNRVMuQ09NPjsgIidNaWNoZWwgU3VpZ25hcmQn IiA8TUlDSEVMU1VATUlDUk9TT0ZULkNPTT47ICJQYXVsIEhvZmZtYW4gLyBJ TUMiIDxQSE9GRk1BTkBJTUMuT1JHPgpDYzogPElETkBPUFMuSUVURi5PUkc+ ClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAwMiwgMjAwMiAxOjE5IEFNClN1 YmplY3Q6IFJlOiBbaWRuXSBzdHJpbmdwcmVwIGNvbW1lbnQgMQoKCiZndDsg U3RyaW5ncHJlcCBrZWVwcyBpdHMgb3duIHRhYmxlcy4gV2hhdCBhbnkgaW1w bGVtZW50YXRpb24gb2YgVW5pY29kZQomZ3Q7IG5lZWRzIHRvIGRvIGlmIHRo ZXkgd2FudCB0byBtYWludGFpbiBzdHJpY3QgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkKJmd0OyBmb3IgY2FzZSBmb2xkaW5nIGlzIHRvIG9ubHkgKmFkZCog dG8gdGFibGVzIGluIHRoZSBmdXR1cmUsIG5vdCBjaGFuZ2UKJmd0OyB0aGUg dmFsdWVzIG9mIGNoYXJhY3RlcnMgdGhhdCBhcmUgYWxyZWFkeSBpbiB0aGUg dGFibGVzLgomZ3Q7CiZndDsgV2hpbGUgaXQgaXMgZXh0cmVtZWx5IHVubGlr ZWx5IHRoYXQgVW5pY29kZSB3aWxsIG1ha2UgYSBjaGFuZ2UgdGhhdAomZ3Q7 IGNhdXNlcyBwcm9ibGVtcyBmb3IgbmFtZXByZXAsIHVzaW5nIHRoZSBhYm92 ZSBzdHJhdGVneSBndWFyYW50ZWVzCiZndDsgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuCiZndDsKJmd0OyBUbyByZXBlYXQsIHRoZSBsb29zZSB2cyBzdHJp Y3QgYXBwcm9hY2ggd29ya3MgYXMgZm9sbG93czoKJmd0OwomZ3Q7IFN1cHBv c2UgdGhlIGNsaWVudCBpcyBVbmljb2RlIDMuMSBhbmQgdGhlIHNlcnZlciBp cyBVbmljb2RlIDQuMC4gQXMKJmd0OyBsb25nIGFzIHRoZSBjbGllbnQgcHJv ZHVjZXMgbmFtZXMgdGhhdCBhcmUgb25seSAzLjEsIG5vIHByb2JsZW0uCiZn dDsgU3RyaW5ncHJlcCBvbiB0aGUgY2xpZW50IHdpbGwgcHJvZHVjZSByZXN1 bHRzIHRoYXQgdGhlIHNlcnZlciBhY2NlcHRzLgomZ3Q7CiZndDsgU3VwcG9z ZSB0aGUgdXNlciBoYXMgY2hhcmFjdGVycyB0aGF0IGFyZSB1bmFzc2lnbmVk IGluIDMuMSAoYnV0IGFyZSBpbgomZ3Q7IDQuMCkuIEFzIGxvbmcgYXMgdGhl IHVzZXIgKG1hbnVhbGx5KSBwaWNrcyBsb3dlcmNhc2UgY2hhcmFjdGVycyAo aW4KJmd0OyB0aGUgcmlnaHQgY2Fub25pY2FsIGZvcm0pLCB0aG9zZSBuYW1l cyB3aWxsIGJlIGFjY2VwdGVkIGJ5IHRoZSA0LjAKJmd0OyBzZXJ2ZXIuIFdo aWxlIGl0IGlzIG5vdCBhcyBlYXN5IGFzIHdoZW4gdGhlIHNvZnR3YXJlIGRv ZXMgaXQgZm9yIHRoZQomZ3Q7IHVzZXIsIGl0IHdpbGwgd29yayBmb3IgYW55 IG5ldyBjaGFyYWN0ZXJzLgomZ3Q7CiZndDsgVGhpcyBpcyBpbXBvcnRhbnQg Zm9yIGFub3RoZXIgc2NlbmFyaW8uIENsaWVudCBBIGlzIG9uIFVuaWNvZGUg NC4wLAomZ3Q7IGNsaWVudCBCIGlzIG9uIFVuaWNvZGUgMy4xLCBhbmQgdGhl IHNlcnZlciBpcyBvbiBVbmljb2RlIDQuMC4gQ2xpZW50IEEKJmd0OyBuYW1l cHJlcHMgYSBzdHJpbmcsIHNlbmRzIHRvIGNsaWVudCBCLiBDbGllbnQgQiBz ZW5kcyB0aGUgc3RyaW5nIG9uIHRvCiZndDsgdGhlIHNlcnZlci4gRXZlcnl0 aGluZyB3b3Jrcy4gSXQgZXZlbiB3b3JrcyBpZiBjbGllbnQgQiByZS1uYW1l cHJlcHMKJmd0OyB0aGUgc3RyaW5nLgoKV291bGQgeW91IGNsYXJpZnkgeW91 ciBhc3NlcnRpb24gZm9yIHBlZXItdG8tcGVlciB0cmFuc2FjdGlvbnMgPwoK RXZlbiBpbiBzb21lIGNsaWVudCB0byBzZXJ2ZXIgdHJhbnNhY3Rpb25zLCBz ZXJ2ZXIgc2lkZXMgbWF5IGhhdmUKbm8gcGVyc2lzdGFudC9zdG9yZWQgc3Ry aW5ncyAobm90LWF1dGhvcml0YXRpdmUpICB0byBjb21wYXJlIGFnYWluc3Qg dGhlIHF1ZXJpZXMsIGJ1dApqdXN0IHN0b3JlIGFuZCB0cnVzdCBvciB0cmFu c21pdCB3aXRob3V0IGdpdmluZyBiYWNrIG5vIG5lZ2F0aXZlIHJlc3BvbnNl Li4KClNvb2JvayBMZWUKCiZndDsKJmd0OyBNYXJrCiZndDsg4oCU4oCU4oCU 4oCU4oCUCiZndDsKJmd0OyDOoM+MzrvOu+KAmSDhvKDPgM6vz4PPhM6xz4TO vyDhvJTPgc6zzrEsIM66zrHOuuG/ts+CIM604oCZIOG8oM+Azq/Pg8+EzrHP hM6/IM+AzqzOvc+EzrEg4oCUIOG9ic68zq7Pgc6/z4UgzpzOsc+BzrPOr8+E 4b+DCiZndDsgW0ZvciB0cmFuc2xpdGVyYXRpb24sIHNlZSBodHRwOi8vb3Nz LnNvZnR3YXJlLmlibS5jb20vY2dpLWJpbi9pY3UvdHJdCiZndDsKJmd0OyBo dHRwOi8vd3d3Lm1hY2NoaWF0by5jb20KJmd0OwomZ3Q7IC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0KJmd0OyBGcm9tOiAiWXZlcyBBcnJvdXllIiA8 WVZFU0BSRUFMTkFNRVMuQ09NPgomZ3Q7IFRvOiAiJ01pY2hlbCBTdWlnbmFy ZCciIDxNSUNIRUxTVUBNSUNST1NPRlQuQ09NPjsgIlBhdWwgSG9mZm1hbiAv IElNQyIKJmd0OyA8UEhPRkZNQU5ASU1DLk9SRz4KJmd0OyBDYzogPElETkBP UFMuSUVURi5PUkc+CiZndDsgU2VudDogVGh1cnNkYXksIEphbnVhcnkgMzEs IDIwMDIgMjI6NTEKJmd0OyBTdWJqZWN0OiBSRTogW2lkbl0gc3RyaW5ncHJl cCBjb21tZW50IDEKJmd0OwomZ3Q7CiZndDsgJmd0OyAmZ3Q7IE5vdCBhIGNo YW5jZS4gVW5pY29kZSBhbmQgSVNPIDEwNjQ2IGNvbGxlY3QgaW4gZmFjdCBz b21lIHVubmVlZGVkCiZndDsgY3J1bWJzCiZndDsgJmd0OyAmZ3Q7IHRoYXQg d2F5LiBPbmNlIGEgY2hhcmFjdGVyIGlzIG9mZmljaWFsbHkgYXBwcm92ZWQg Zm9yIGluY2x1c2lvbiBpdAomZ3Q7IGlzCiZndDsgJmd0OyAmZ3Q7IHRoZXJl IGZvcmV2ZXIsIHdoYXRldmVyIHdlIGRvbid0IGxpa2UgaXQgb3Igbm90LiBD aGFyYWN0ZXJzIGdldAomZ3Q7ICZndDsgJmd0OyBkZXByZWNhdGVkIChpLmUu IHVzYWdlIGRpc2NvdXJhZ2VkKSBidXQgbmV2ZXIgcmVtb3ZlZC4gVGhpcyBp cyB0aGUKJmd0OyBwcmljZQomZ3Q7ICZndDsgJmd0OyB5b3UgaGF2ZSB0byBw YXkgZm9yIHN0YWJpbGl0eSBhbmQgdXNhZ2UgYnkgb3RoZXIgc3BlY2lmaWNh dGlvbgomZ3Q7IChsaWtlCiZndDsgJmd0OyAmZ3Q7IElETikuCiZndDsgJmd0 OwomZ3Q7ICZndDsgU29ycnksIEkgZGlkIG5vdCBtZWFuIHJlbW92ZWQgZnJv bSBVbmljb2RlIChJIGFtIGF3YXJlIG9mIHRoZSBydWxlCiZndDsgdGhlcmUs CiZndDsgJmd0OyB3aGljaCBtYWtlcyBzZW5zZSksIEkgbWVhbnQgb25lIGNo YXJhY3RlciB0aGF0IGlzIGFkZGVkIHRvIFVuaWNvZGUKJmd0OyBidXQgdGhh dAomZ3Q7ICZndDsgYSBnaXZlbiBTdHJpbmdwcmVwIHByb2ZpbGUgd291bGQg dGhpbmsgZGVzaXJhYmxlIHRvIHJlbW92ZS4KJmd0OyAmZ3Q7CiZndDsgJmd0 OyBBcyBmb3IgY2FzZSBmb2xkaW5nLCBhcyBzb29uIGFzIG9uZSBhZGRzIGEg bmV3IGNhc2UgbWFwcGluZyBpbiB0aGUKJmd0OyBOYW1lcHJlcAomZ3Q7ICZn dDsgcHJvZmlsZSwgb25lIG5lZWRzIHRvIHVwZ3JhZGUgY2xpZW50cyBhdCB0 aGUgc2FtZSB0aW1lIGFzIHNlcnZlcnMuCiZndDsgT29wcy4KJmd0OyAmZ3Q7 IEVuY29kaW5nIHRoZSBOYW1lcHJlcCB2ZXJzaW9uIGluIHF1ZXJpZXMgd291 bGQgc29sdmUgdGhhdCwgYnV0CiZndDsgb2J2aW91c2x5IGF0CiZndDsgJmd0 OyB0aGUgY29zdCBvZiBzb21lIG90aGVyIG1lYW5pbmdmdWwgaW5mbyBpbiB0 aGUgbGFiZWwsIHRodXMgcmVkdWNpbmcKJmd0OyB0aGUKJmd0OyAmZ3Q7IGxl bmd0aCBvZiBJRE4gbmFtZXMuCiZndDsgJmd0OwomZ3Q7ICZndDsgWUEKJmd0 OyAmZ3Q7CiZndDsgJmd0OwomZ3Q7ICZndDsKJmd0OyAmZ3Q7CiZndDsKCjwv UFJFPjxJTUcgaGVpZ2h0PTEgCiAgICBzcmM9Imh0dHA6Ly9wb3N0ZWwyLnBv c3RlbC5jby5rci9yZWFkLzEwMTI1ODMyNjctMmFmNDFjNjE5MTYwOTIzZGE1 OTRmYzZlNzRkYjE4Y2MuNDFlNWZkNmYxOTdlYmMxMC9pZG5Ab3BzLmlldGYu b3JnLmNvbmZpcm0ucG9zdGVsLnRvIiAKICAgIHdpZHRoPTE+IDwvRk9OVD48 L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPgo8aW1nIHNyYz1odHRwOi8vcG9z dGVsMi5wb3N0ZWwuY28ua3IvcmVhZC8xMDEyNjA5MDU2LWFkMzViODI3OTEw MjViMTFhNTk0Yjk2ODQxMjNiYWYyLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9w cy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0x PjxpbWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5jby5rci9yZWFkcS8x MDEyNjA5MDU2LWFkMzViODI3OTEwMjViMTFhNTk0Yjk2ODQxMjNiYWYyLjQx ZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3Rl bC50by9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRvIHdpZHRo PTEgaGVpZ2h0PTE+CjwvQk9EWT4KPC9IVE1MPgo= From owner-idn@ops.ietf.org Fri Feb 1 19:29: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 TAA14852 for ; Fri, 1 Feb 2002 19:29:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WnwQ-000GO9-00 for idn-data@psg.com; Fri, 01 Feb 2002 16:22:02 -0800 Received: from [211.218.145.193] (helo=postel2) by psg.com with esmtp (Exim 3.33 #1) id 16WnwO-000GO3-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 16:22:00 -0800 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g120Ll011616 for idn@ops.ietf.org; Sat, 2 Feb 2002 09:21:47 +0900 To: "Mark Davis" , idn@ops.ietf.org Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g120Lc611584; Sat, 2 Feb 2002 09:21:38 +0900 MIME-Version: 1.0 X-Msmail-Priority: Normal Message-Id: <01a501c1ab7f$8daf3270$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 From: "Soobok Lee" X-Priority: 3 References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> <006a01c1ab3c$376248a0$08d8ea0c@c1340594a> <00de01c1ab42$f8fd0fd0$ec1bd9d2@temp> <007201c1ab73$9c053420$08d8ea0c@c1340594a> X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 09:21:25 +0900 Content-Disposition: inline Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQu MCBUcmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAt ZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2MDAuMCIg bmFtZT1HRU5FUkFUT1I+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+CjxCT0RZ IGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48U1RST05HPjxGT05UIGZhY2U96rW0 66a8IHNpemU9Mj48L0ZPTlQ+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+CjxCTE9D S1FVT1RFIGRpcj1sdHIgCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVG VDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4KICA8 RElWIHN0eWxlPSJGT05UOiAxMHB0IOq1tOumvCI+LS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSA8L0RJVj4KICA8RElWIAogIHN0eWxlPSJCQUNLR1JP VU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IOq1tOumvDsgZm9udC1jb2xvcjog YmxhY2siPjxCPkZyb206PC9CPiA8QSAKICB0aXRsZT1tYXJrQG1hY2NoaWF0 by5jb20gaHJlZj0ibWFpbHRvOm1hcmtAbWFjY2hpYXRvLmNvbSI+TWFyayBE YXZpczwvQT4gCjwvRElWPgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW0 66a8Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWlkbkBvcHMuaWV0Zi5vcmcgCiAg aHJlZj0ibWFpbHRvOmlkbkBvcHMuaWV0Zi5vcmciPmlkbkBvcHMuaWV0Zi5v cmc8L0E+IDsgPEEgCiAgdGl0bGU9bHNiQHBvc3RlbC5jby5rciBocmVmPSJt YWlsdG86bHNiQHBvc3RlbC5jby5rciI+U29vYm9rIExlZTwvQT4gPC9ESVY+ CiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCDqtbTrprwiPjxCPlNlbnQ6PC9C PiBTYXR1cmRheSwgRmVicnVhcnkgMDIsIDIwMDIgNzo1NSAKICBBTTwvRElW PgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW066a8Ij48Qj5TdWJqZWN0 OjwvQj4gUmU6IFtpZG5dIHN0cmluZ3ByZXAgY29tbWVudCAKMTwvRElWPgog IDxESVY+PEJSPjwvRElWPgogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+QXMgZGlzY3Vzc2VkIGJlZm9yZSwgY29tcGFyaXNvbnMgb25seSB3b3Jr IGlmIHlvdSAKICBhcmUgbWF0Y2hpbmcgPC9GT05UPjwvRElWPgogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgog IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+bG9vc2UgdnMgc3RyaWN0 IC8vIHdoZXJlIHRoZSBzdHJpY3QgaXMgCiAgYXV0aG9yaXRhdGl2ZTwvRk9O VD48L0RJVj4KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPnN0cmlj dCB2cyBzdHJpY3Q8L0ZPTlQ+PC9ESVY+CiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+CiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj5TaW1wbGUgdHJhbnNtaXNzaW9uIG9yIHN0b3Jl IGFuZCB0cmFuc21pc3Npb24gaXMgCiAgbm90IGFuIGlzc3VlLCBhcyBsb25n IGFzIG5vIGNvbXBhcmlzb24gaXMgbWFkZS48L0ZPTlQ+PC9ESVY+PC9CTE9D S1FVT1RFPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlNvbWUgYXBwbGlj YXRpb25zJm5ic3A7IGluIHRoZSBlbmQgb2YgdHJhbnNtaXNzaW9uIApzdXJl bHkgZG8gY29tcGFyaXNvbnMgb24gdGhlbSZuYnNwOzxGT05UIHNpemU9Mj4m bmJzcDtsYXRlciB0aW1lIHNpbGVudGx5Jm5ic3A7LiAKPC9GT05UPgo8RElW IGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoZSBpbnRlcm1lZGlhdGUvZmluYWwg YXBwbGljYXRpb25zIG1heSBub3QgZ2l2ZSBiYWNrIAp0aGUgbmVnYXRpdmUg YW5zd2VycyB0byB0aGUgPC9GT05UPjwvRElWPgo8RElWIGRpcj1sdHI+PEZP TlQgc2l6ZT0yPm9yaWdpbmF0aW5nIGVuZCB1c2VycyBpbW1lZGlhdGVseSBv ciBmaW5hbGx5IG9yIGJvdGguIAplZykgc2VuZGluZyBlbWFpbHMgb3IgZW5s aXN0aW5nIGluIHRoZSBvbmxpbmUgd2hpdGUgcGFnZS48L0ZPTlQ+PC9ESVY+ CjxESVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoZWlyIGZhaWx1cmUgaXMg YXMgc2lsZW50IGFzIGFudGhyYXggdGhyZWF0LiAKYW5kPC9GT05UPjwvRElW Pgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoYXQnIGxpa2UgYSBsb3N0 IGxhbmQgbWluZSB3aGljaCBzb21lIGNpdmlsIApjaGlsZHJlbiZuYnNwOyBt YXkgc3RlcCBvbiAuPC9GT05UPjwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQg c2l6ZT0yPlRoZSBzb2xkaWVycyBkb24ndCBrbm93IHdoYXQmbmJzcDsgaGFw cGVucyB1bnRpbCB0aGV5IApnZXQgcmVwb3J0Jm5ic3A7dGhhdCBzb21lb25l IGxvc3QmbmJzcDsgdGhlaXIgZmVldCBieSB0aGUgbG9zdCAKbWluZS48L0ZP TlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlNvb2JvayBM ZWU8L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRElWPgo8QkxPQ0tRVU9URSBkaXI9 bHRyIApzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6 IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAg MnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgogIDxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgogIDxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+TWFyazwvRk9OVD48L0RJVj4KICA8RElWPuKA lOKAlOKAlOKAlOKAlDwvRElWPgogIDxESVY+Jm5ic3A7PC9ESVY+CiAgPERJ Vj7OoM+MzrvOu+KAmSDhvKDPgM6vz4PPhM6xz4TOvyDhvJTPgc6zzrEsIM66 zrHOuuG/ts+CIM604oCZIOG8oM+Azq/Pg8+EzrHPhM6/IM+AzqzOvc+EzrEg 4oCUIOG9ic68zq7Pgc6/z4UgzpzOsc+BzrPOr8+E4b+DPEJSPltGb3IgCiAg dHJhbnNsaXRlcmF0aW9uLCBzZWUgPEEgCiAgaHJlZj0iaHR0cDovL29zcy5z b2Z0d2FyZS5pYm0uY29tL2NnaS1iaW4vaWN1L3RyIj5odHRwOi8vb3NzLnNv ZnR3YXJlLmlibS5jb20vY2dpLWJpbi9pY3UvdHI8L0E+XTwvRElWPgogIDxE SVY+Jm5ic3A7PC9ESVY+CiAgPERJVj48QSBocmVmPSJodHRwOi8vd3d3Lm1h Y2NoaWF0by5jb20iPmh0dHA6Ly93d3cubWFjY2hpYXRvLmNvbTwvQT48QlI+ PC9ESVY+CiAgPEJMT0NLUVVPVEUgCiAgc3R5bGU9IlBBRERJTkctUklHSFQ6 IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJP UkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAw cHgiPgogICAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+LS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4KICAgIDxESVYgCiAgICBz dHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsg Zm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiAKICAgIDxBIHRpdGxl PWxzYkBwb3N0ZWwuY28ua3IgaHJlZj0ibWFpbHRvOmxzYkBwb3N0ZWwuY28u a3IiPlNvb2JvayBMZWU8L0E+IAogICAgPC9ESVY+CiAgICA8RElWIHN0eWxl PSJGT05UOiAxMHB0IGFyaWFsIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPWlkbkBv cHMuaWV0Zi5vcmcgCiAgICBocmVmPSJtYWlsdG86aWRuQG9wcy5pZXRmLm9y ZyI+aWRuQG9wcy5pZXRmLm9yZzwvQT4gPC9ESVY+CiAgICA8RElWIHN0eWxl PSJGT05UOiAxMHB0IGFyaWFsIj48Qj5TZW50OjwvQj4gRnJpZGF5LCBGZWJy dWFyeSAwMSwgMjAwMiAKICAgIDA5OjA3PC9ESVY+CiAgICA8RElWIHN0eWxl PSJGT05UOiAxMHB0IGFyaWFsIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtpZG5d IHN0cmluZ3ByZXAgY29tbWVudCAKICAgIDE8L0RJVj4KICAgIDxESVY+PEJS PjwvRElWPjxGT05UIHNpemU9KzE+PFBSRSBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCkZyb206ICJNYXJr IERhdmlzIiA8TUFSS0BNQUNDSElBVE8uQ09NPgpUbzogIll2ZXMgQXJyb3V5 ZSIgPFlWRVNAUkVBTE5BTUVTLkNPTT47ICInTWljaGVsIFN1aWduYXJkJyIg PE1JQ0hFTFNVQE1JQ1JPU09GVC5DT00+OyAiUGF1bCBIb2ZmbWFuIC8gSU1D IiA8UEhPRkZNQU5ASU1DLk9SRz4KQ2M6IDxJRE5AT1BTLklFVEYuT1JHPgpT ZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMDIsIDIwMDIgMToxOSBBTQpTdWJq ZWN0OiBSZTogW2lkbl0gc3RyaW5ncHJlcCBjb21tZW50IDEKCgomZ3Q7IFN0 cmluZ3ByZXAga2VlcHMgaXRzIG93biB0YWJsZXMuIFdoYXQgYW55IGltcGxl bWVudGF0aW9uIG9mIFVuaWNvZGUKJmd0OyBuZWVkcyB0byBkbyBpZiB0aGV5 IHdhbnQgdG8gbWFpbnRhaW4gc3RyaWN0IGJhY2t3YXJkcyBjb21wYXRpYmls aXR5CiZndDsgZm9yIGNhc2UgZm9sZGluZyBpcyB0byBvbmx5ICphZGQqIHRv IHRhYmxlcyBpbiB0aGUgZnV0dXJlLCBub3QgY2hhbmdlCiZndDsgdGhlIHZh bHVlcyBvZiBjaGFyYWN0ZXJzIHRoYXQgYXJlIGFscmVhZHkgaW4gdGhlIHRh Ymxlcy4KJmd0OwomZ3Q7IFdoaWxlIGl0IGlzIGV4dHJlbWVseSB1bmxpa2Vs eSB0aGF0IFVuaWNvZGUgd2lsbCBtYWtlIGEgY2hhbmdlIHRoYXQKJmd0OyBj YXVzZXMgcHJvYmxlbXMgZm9yIG5hbWVwcmVwLCB1c2luZyB0aGUgYWJvdmUg c3RyYXRlZ3kgZ3VhcmFudGVlcwomZ3Q7IGJhY2t3YXJkcyBjb21wYXRpYmls aXR5LgomZ3Q7CiZndDsgVG8gcmVwZWF0LCB0aGUgbG9vc2UgdnMgc3RyaWN0 IGFwcHJvYWNoIHdvcmtzIGFzIGZvbGxvd3M6CiZndDsKJmd0OyBTdXBwb3Nl IHRoZSBjbGllbnQgaXMgVW5pY29kZSAzLjEgYW5kIHRoZSBzZXJ2ZXIgaXMg VW5pY29kZSA0LjAuIEFzCiZndDsgbG9uZyBhcyB0aGUgY2xpZW50IHByb2R1 Y2VzIG5hbWVzIHRoYXQgYXJlIG9ubHkgMy4xLCBubyBwcm9ibGVtLgomZ3Q7 IFN0cmluZ3ByZXAgb24gdGhlIGNsaWVudCB3aWxsIHByb2R1Y2UgcmVzdWx0 cyB0aGF0IHRoZSBzZXJ2ZXIgYWNjZXB0cy4KJmd0OwomZ3Q7IFN1cHBvc2Ug dGhlIHVzZXIgaGFzIGNoYXJhY3RlcnMgdGhhdCBhcmUgdW5hc3NpZ25lZCBp biAzLjEgKGJ1dCBhcmUgaW4KJmd0OyA0LjApLiBBcyBsb25nIGFzIHRoZSB1 c2VyIChtYW51YWxseSkgcGlja3MgbG93ZXJjYXNlIGNoYXJhY3RlcnMgKGlu CiZndDsgdGhlIHJpZ2h0IGNhbm9uaWNhbCBmb3JtKSwgdGhvc2UgbmFtZXMg d2lsbCBiZSBhY2NlcHRlZCBieSB0aGUgNC4wCiZndDsgc2VydmVyLiBXaGls ZSBpdCBpcyBub3QgYXMgZWFzeSBhcyB3aGVuIHRoZSBzb2Z0d2FyZSBkb2Vz IGl0IGZvciB0aGUKJmd0OyB1c2VyLCBpdCB3aWxsIHdvcmsgZm9yIGFueSBu ZXcgY2hhcmFjdGVycy4KJmd0OwomZ3Q7IFRoaXMgaXMgaW1wb3J0YW50IGZv ciBhbm90aGVyIHNjZW5hcmlvLiBDbGllbnQgQSBpcyBvbiBVbmljb2RlIDQu MCwKJmd0OyBjbGllbnQgQiBpcyBvbiBVbmljb2RlIDMuMSwgYW5kIHRoZSBz ZXJ2ZXIgaXMgb24gVW5pY29kZSA0LjAuIENsaWVudCBBCiZndDsgbmFtZXBy ZXBzIGEgc3RyaW5nLCBzZW5kcyB0byBjbGllbnQgQi4gQ2xpZW50IEIgc2Vu ZHMgdGhlIHN0cmluZyBvbiB0bwomZ3Q7IHRoZSBzZXJ2ZXIuIEV2ZXJ5dGhp bmcgd29ya3MuIEl0IGV2ZW4gd29ya3MgaWYgY2xpZW50IEIgcmUtbmFtZXBy ZXBzCiZndDsgdGhlIHN0cmluZy4KCldvdWxkIHlvdSBjbGFyaWZ5IHlvdXIg YXNzZXJ0aW9uIGZvciBwZWVyLXRvLXBlZXIgdHJhbnNhY3Rpb25zID8KCkV2 ZW4gaW4gc29tZSBjbGllbnQgdG8gc2VydmVyIHRyYW5zYWN0aW9ucywgc2Vy dmVyIHNpZGVzIG1heSBoYXZlCm5vIHBlcnNpc3RhbnQvc3RvcmVkIHN0cmlu Z3MgKG5vdC1hdXRob3JpdGF0aXZlKSAgdG8gY29tcGFyZSBhZ2FpbnN0IHRo ZSBxdWVyaWVzLCBidXQKanVzdCBzdG9yZSBhbmQgdHJ1c3Qgb3IgdHJhbnNt aXQgd2l0aG91dCBnaXZpbmcgYmFjayBubyBuZWdhdGl2ZSByZXNwb25zZS4u CgpTb29ib2sgTGVlCgomZ3Q7CiZndDsgTWFyawomZ3Q7IOKAlOKAlOKAlOKA lOKAlAomZ3Q7CiZndDsgzqDPjM67zrvigJkg4bygz4DOr8+Dz4TOsc+Ezr8g 4byUz4HOs86xLCDOus6xzrrhv7bPgiDOtOKAmSDhvKDPgM6vz4PPhM6xz4TO vyDPgM6szr3PhM6xIOKAlCDhvYnOvM6uz4HOv8+FIM6czrHPgc6zzq/PhOG/ gwomZ3Q7IFtGb3IgdHJhbnNsaXRlcmF0aW9uLCBzZWUgaHR0cDovL29zcy5z b2Z0d2FyZS5pYm0uY29tL2NnaS1iaW4vaWN1L3RyXQomZ3Q7CiZndDsgaHR0 cDovL3d3dy5tYWNjaGlhdG8uY29tCiZndDsKJmd0OyAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tCiZndDsgRnJvbTogIll2ZXMgQXJyb3V5ZSIgPFlW RVNAUkVBTE5BTUVTLkNPTT4KJmd0OyBUbzogIidNaWNoZWwgU3VpZ25hcmQn IiA8TUlDSEVMU1VATUlDUk9TT0ZULkNPTT47ICJQYXVsIEhvZmZtYW4gLyBJ TUMiCiZndDsgPFBIT0ZGTUFOQElNQy5PUkc+CiZndDsgQ2M6IDxJRE5AT1BT LklFVEYuT1JHPgomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDMxLCAy MDAyIDIyOjUxCiZndDsgU3ViamVjdDogUkU6IFtpZG5dIHN0cmluZ3ByZXAg Y29tbWVudCAxCiZndDsKJmd0OwomZ3Q7ICZndDsgJmd0OyBOb3QgYSBjaGFu Y2UuIFVuaWNvZGUgYW5kIElTTyAxMDY0NiBjb2xsZWN0IGluIGZhY3Qgc29t ZSB1bm5lZWRlZAomZ3Q7IGNydW1icwomZ3Q7ICZndDsgJmd0OyB0aGF0IHdh eS4gT25jZSBhIGNoYXJhY3RlciBpcyBvZmZpY2lhbGx5IGFwcHJvdmVkIGZv ciBpbmNsdXNpb24gaXQKJmd0OyBpcwomZ3Q7ICZndDsgJmd0OyB0aGVyZSBm b3JldmVyLCB3aGF0ZXZlciB3ZSBkb24ndCBsaWtlIGl0IG9yIG5vdC4gQ2hh cmFjdGVycyBnZXQKJmd0OyAmZ3Q7ICZndDsgZGVwcmVjYXRlZCAoaS5lLiB1 c2FnZSBkaXNjb3VyYWdlZCkgYnV0IG5ldmVyIHJlbW92ZWQuIFRoaXMgaXMg dGhlCiZndDsgcHJpY2UKJmd0OyAmZ3Q7ICZndDsgeW91IGhhdmUgdG8gcGF5 IGZvciBzdGFiaWxpdHkgYW5kIHVzYWdlIGJ5IG90aGVyIHNwZWNpZmljYXRp b24KJmd0OyAobGlrZQomZ3Q7ICZndDsgJmd0OyBJRE4pLgomZ3Q7ICZndDsK Jmd0OyAmZ3Q7IFNvcnJ5LCBJIGRpZCBub3QgbWVhbiByZW1vdmVkIGZyb20g VW5pY29kZSAoSSBhbSBhd2FyZSBvZiB0aGUgcnVsZQomZ3Q7IHRoZXJlLAom Z3Q7ICZndDsgd2hpY2ggbWFrZXMgc2Vuc2UpLCBJIG1lYW50IG9uZSBjaGFy YWN0ZXIgdGhhdCBpcyBhZGRlZCB0byBVbmljb2RlCiZndDsgYnV0IHRoYXQK Jmd0OyAmZ3Q7IGEgZ2l2ZW4gU3RyaW5ncHJlcCBwcm9maWxlIHdvdWxkIHRo aW5rIGRlc2lyYWJsZSB0byByZW1vdmUuCiZndDsgJmd0OwomZ3Q7ICZndDsg QXMgZm9yIGNhc2UgZm9sZGluZywgYXMgc29vbiBhcyBvbmUgYWRkcyBhIG5l dyBjYXNlIG1hcHBpbmcgaW4gdGhlCiZndDsgTmFtZXByZXAKJmd0OyAmZ3Q7 IHByb2ZpbGUsIG9uZSBuZWVkcyB0byB1cGdyYWRlIGNsaWVudHMgYXQgdGhl IHNhbWUgdGltZSBhcyBzZXJ2ZXJzLgomZ3Q7IE9vcHMuCiZndDsgJmd0OyBF bmNvZGluZyB0aGUgTmFtZXByZXAgdmVyc2lvbiBpbiBxdWVyaWVzIHdvdWxk IHNvbHZlIHRoYXQsIGJ1dAomZ3Q7IG9idmlvdXNseSBhdAomZ3Q7ICZndDsg dGhlIGNvc3Qgb2Ygc29tZSBvdGhlciBtZWFuaW5nZnVsIGluZm8gaW4gdGhl IGxhYmVsLCB0aHVzIHJlZHVjaW5nCiZndDsgdGhlCiZndDsgJmd0OyBsZW5n dGggb2YgSUROIG5hbWVzLgomZ3Q7ICZndDsKJmd0OyAmZ3Q7IFlBCiZndDsg Jmd0OwomZ3Q7ICZndDsKJmd0OyAmZ3Q7CiZndDsgJmd0OwomZ3Q7Cgo8L1BS RT48SU1HIGhlaWdodD0xIAogICAgc3JjPSJodHRwOi8vcG9zdGVsMi5wb3N0 ZWwuY28ua3IvcmVhZC8xMDEyNTgzMjY3LTJhZjQxYzYxOTE2MDkyM2RhNTk0 ZmM2ZTc0ZGIxOGNjLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9y Zy5jb25maXJtLnBvc3RlbC50byIgCiAgICB3aWR0aD0xPiA8L0ZPTlQ+PC9C TE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4KPGltZyBzcmM9aHR0cDovL3Bvc3Rl bDIucG9zdGVsLmNvLmtyL3JlYWQvMTAxMjYwOTI4NS0yYWY0MWM2MTkxNjA5 MjNkYTU5NGZjNmU3NGRiMThjYy40MWU1ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMu aWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT48 aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZHEvMTAx MjYwOTI4NS0yYWY0MWM2MTkxNjA5MjNkYTU5NGZjNmU3NGRiMThjYy40MWU1 ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMuaWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwu dG8vaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0x IGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K From owner-idn@ops.ietf.org Fri Feb 1 19:44: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 TAA15148 for ; Fri, 1 Feb 2002 19:44:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WoBs-000Gx5-00 for idn-data@psg.com; Fri, 01 Feb 2002 16:38:00 -0800 Received: from rwcrmhc52.attbi.com ([216.148.227.88]) by psg.com with esmtp (Exim 3.33 #1) id 16WoBr-000Gwz-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 16:37:59 -0800 Received: from c1340594a ([12.234.216.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020202003758.NCEH3578.rwcrmhc52.attbi.com@c1340594a>; Sat, 2 Feb 2002 00:37:58 +0000 Message-ID: <0b4701c1ab82$2bcdcb90$08d8ea0c@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: , "Soobok Lee" References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> <006a01c1ab3c$376248a0$08d8ea0c@c1340594a> <00de01c1ab42$f8fd0fd0$ec1bd9d2@temp> <007201c1ab73$9c053420$08d8ea0c@c1340594a> <01a501c1ab7f$8daf3270$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 Date: Fri, 1 Feb 2002 16:40:10 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B43_01C1AB3F.1D6433C0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0B43_01C1AB3F.1D6433C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > surely do comparisons on them later time silently When stringprep is used correctly, loose vs loose comparisons alone will never happen. If loose vs loose comparisons must be used; one needs to also transmit additional information in order to make a valid comparison. Let's restate the obvious: 1. Stringprep is appropriate in certain environments. 2. Stringprep is not appropriate in other environments, Simply stating that there could be cases where stringprep may cause problems is just reiterating (2), and adds no useful information to the discussion. Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: Soobok Lee To: Mark Davis ; idn@ops.ietf.org Sent: Friday, February 01, 2002 16:21 Subject: Re: [idn] stringprep comment 1 ----- Original Message ----- From: Mark Davis To: idn@ops.ietf.org ; Soobok Lee Sent: Saturday, February 02, 2002 7:55 AM Subject: Re: [idn] stringprep comment 1 As discussed before, comparisons only work if you are matching loose vs strict // where the strict is authoritative strict vs strict Simple transmission or store and transmission is not an issue, as long as no comparison is made. Some applications in the end of transmission surely do comparisons on them later time silently . The intermediate/final applications may not give back the negative answers to the originating end users immediately or finally or both. eg) sending emails or enlisting in the online white page. Their failure is as silent as anthrax threat. and That' like a lost land mine which some civil children may step on . The soldiers don't know what happens until they get report that someone lost their feet by the lost mine. Soobok Lee Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: Soobok Lee To: idn@ops.ietf.org Sent: Friday, February 01, 2002 09:07 Subject: Re: [idn] stringprep comment 1 ----- Original Message ----- From: "Mark Davis" To: "Yves Arrouye" ; "'Michel Suignard'" ; "Paul Hoffman / IMC" Cc: Sent: Saturday, February 02, 2002 1:19 AM Subject: Re: [idn] stringprep comment 1 > Stringprep keeps its own tables. What any implementation of Unicode > needs to do if they want to maintain strict backwards compatibility > for case folding is to only *add* to tables in the future, not change > the values of characters that are already in the tables. > > While it is extremely unlikely that Unicode will make a change that > causes problems for nameprep, using the above strategy guarantees > backwards compatibility. > > To repeat, the loose vs strict approach works as follows: > > Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As > long as the client produces names that are only 3.1, no problem. > Stringprep on the client will produce results that the server accepts. > > Suppose the user has characters that are unassigned in 3.1 (but are in > 4.0). As long as the user (manually) picks lowercase characters (in > the right canonical form), those names will be accepted by the 4.0 > server. While it is not as easy as when the software does it for the > user, it will work for any new characters. > > This is important for another scenario. Client A is on Unicode 4.0, > client B is on Unicode 3.1, and the server is on Unicode 4.0. Client A > namepreps a string, sends to client B. Client B sends the string on to > the server. Everything works. It even works if client B re-namepreps > the string. Would you clarify your assertion for peer-to-peer transactions ? Even in some client to server transactions, server sides may have no persistant/stored strings (not-authoritative) to compare against the queries, but just store and trust or transmit without giving back no negative response.. Soobok Lee > > Mark > ————— > > Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] > > http://www.macchiato.com > > ----- Original Message ----- > From: "Yves Arrouye" > To: "'Michel Suignard'" ; "Paul Hoffman / IMC" > > Cc: > Sent: Thursday, January 31, 2002 22:51 > Subject: RE: [idn] stringprep comment 1 > > > > > Not a chance. Unicode and ISO 10646 collect in fact some unneeded > crumbs > > > that way. Once a character is officially approved for inclusion it > is > > > there forever, whatever we don't like it or not. Characters get > > > deprecated (i.e. usage discouraged) but never removed. This is the > price > > > you have to pay for stability and usage by other specification > (like > > > IDN). > > > > Sorry, I did not mean removed from Unicode (I am aware of the rule > there, > > which makes sense), I meant one character that is added to Unicode > but that > > a given Stringprep profile would think desirable to remove. > > > > As for case folding, as soon as one adds a new case mapping in the > Nameprep > > profile, one needs to upgrade clients at the same time as servers. > Oops. > > Encoding the Nameprep version in queries would solve that, but > obviously at > > the cost of some other meaningful info in the label, thus reducing > the > > length of IDN names. > > > > YA > > > > > > > > > ------=_NextPart_000_0B43_01C1AB3F.1D6433C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
> surely do comparisons on = them  later time silently
 
When stringprep is used correctly, = loose vs loose=20 comparisons alone will never happen. If loose vs loose comparisons must = be used;=20 one needs to also transmit additional information in order to make a = valid=20 comparison. Let's restate the obvious:
 
1. Stringprep is appropriate in = certain=20 environments.
2. Stringprep is not = appropriate in other=20 environments,
 
Simply stating that there could be = cases where=20 stringprep may cause problems is just reiterating (2), and adds no = useful=20 information to the discussion.
 
Mark
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
=CE=A0=CF=8C=CE=BB=CE=BB=E2=80=99 = =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =E1=BC=94=CF=81=CE=B3=CE=B1, =CE=BA=CE=B1=CE=BA=E1=BF=B6=CF=82 = =CE=B4=E2=80=99 =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =CF=80=CE=AC=CE=BD=CF=84=CE=B1 =E2=80=94=20 =E1=BD=89=CE=BC=CE=AE=CF=81=CE=BF=CF=85 = =CE=9C=CE=B1=CF=81=CE=B3=CE=AF=CF=84=E1=BF=83
[For transliteration, = see http://oss.software.i= bm.com/cgi-bin/icu/tr]
 
http://www.macchiato.com
=
----- Original Message -----
From:=20 Soobok = Lee
Sent: Friday, February 01, 2002 = 16:21
Subject: Re: [idn] stringprep = comment=20 1

 
----- Original Message = -----
From:=20 Mark Davis=20
To: idn@ops.ietf.org ; Soobok = Lee
Sent: Saturday, = February 02, 2002 7:55=20 AM
Subject: Re: = [idn] stringprep comment=20 1

As discussed before, comparisons = only work if=20 you are matching
 
loose vs strict // where the strict = is=20 authoritative
strict vs strict
 
Simple transmission or store and = transmission=20 is not an issue, as long as no comparison is = made.
Some applications  in the end of = transmission=20 surely do comparisons on them  later time=20 silently .
The intermediate/final applications may = not give=20 back the negative answers to the
originating end users immediately or = finally or=20 both. eg) sending emails or enlisting in the online white = page.
 
Their failure is as silent as anthrax = threat.=20 and
That' like a lost land mine which some = civil=20 children  may step on .
The soldiers don't know what  = happens until=20 they get report that someone lost  their feet by the lost=20 mine.
 
Soobok Lee
 
 
Mark
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
=CE=A0=CF=8C=CE=BB=CE=BB=E2=80=99 = =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =E1=BC=94=CF=81=CE=B3=CE=B1, =CE=BA=CE=B1=CE=BA=E1=BF=B6=CF=82 = =CE=B4=E2=80=99 =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =CF=80=CE=AC=CE=BD=CF=84=CE=B1 =E2=80=94 = =E1=BD=89=CE=BC=CE=AE=CF=81=CE=BF=CF=85 = =CE=9C=CE=B1=CF=81=CE=B3=CE=AF=CF=84=E1=BF=83
[For=20 transliteration, see http://oss.software.i= bm.com/cgi-bin/icu/tr]
 
http://www.macchiato.com
----- Original Message ----- =
From:=20 Soobok Lee=20
Sent: Friday, February 01, = 2002=20 09:07
Subject: Re: [idn] = stringprep comment=20 1

----- Original Message -----
From: "Mark Davis" 
To: "Yves Arrouye" ; "'Michel Suignard'" =
; "Paul Hoffman / IMC" 
Cc: 
Sent: Saturday, February 02, 2002 1:19 AM
Subject: Re: [idn] stringprep comment 1


> Stringprep keeps its own tables. What any implementation of Unicode
> needs to do if they want to maintain strict backwards compatibility
> for case folding is to only *add* to tables in the future, not =
change
> the values of characters that are already in the tables.
>
> While it is extremely unlikely that Unicode will make a change that
> causes problems for nameprep, using the above strategy guarantees
> backwards compatibility.
>
> To repeat, the loose vs strict approach works as follows:
>
> Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As
> long as the client produces names that are only 3.1, no problem.
> Stringprep on the client will produce results that the server =
accepts.
>
> Suppose the user has characters that are unassigned in 3.1 (but are =
in
> 4.0). As long as the user (manually) picks lowercase characters (in
> the right canonical form), those names will be accepted by the 4.0
> server. While it is not as easy as when the software does it for =
the
> user, it will work for any new characters.
>
> This is important for another scenario. Client A is on Unicode 4.0,
> client B is on Unicode 3.1, and the server is on Unicode 4.0. =
Client A
> namepreps a string, sends to client B. Client B sends the string on =
to
> the server. Everything works. It even works if client B =
re-namepreps
> the string.

Would you clarify your assertion for peer-to-peer transactions ?

Even in some client to server transactions, server sides may have
no persistant/stored strings (not-authoritative)  to compare against the =
queries, but
just store and trust or transmit without giving back no negative =
response..

Soobok Lee

>
> Mark
> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>
> =CE=A0=CF=8C=CE=BB=CE=BB=E2=80=99 =
=E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF =
=E1=BC=94=CF=81=CE=B3=CE=B1, =CE=BA=CE=B1=CE=BA=E1=BF=B6=CF=82 =
=CE=B4=E2=80=99 =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF =
=CF=80=CE=AC=CE=BD=CF=84=CE=B1 =E2=80=94 =
=E1=BD=89=CE=BC=CE=AE=CF=81=CE=BF=CF=85 =
=CE=9C=CE=B1=CF=81=CE=B3=CE=AF=CF=84=E1=BF=83
> [For transliteration, see =
http://oss.software.ibm.com/cgi-bin/icu/tr]
>
> http://www.macchiato.com
>
> ----- Original Message -----
> From: "Yves Arrouye" 
> To: "'Michel Suignard'" ; "Paul Hoffman / =
IMC"
> 
> Cc: 
> Sent: Thursday, January 31, 2002 22:51
> Subject: RE: [idn] stringprep comment 1
>
>
> > > Not a chance. Unicode and ISO 10646 collect in fact some =
unneeded
> crumbs
> > > that way. Once a character is officially approved for =
inclusion it
> is
> > > there forever, whatever we don't like it or not. =
Characters get
> > > deprecated (i.e. usage discouraged) but never removed. =
This is the
> price
> > > you have to pay for stability and usage by other =
specification
> (like
> > > IDN).
> >
> > Sorry, I did not mean removed from Unicode (I am aware of the =
rule
> there,
> > which makes sense), I meant one character that is added to =
Unicode
> but that
> > a given Stringprep profile would think desirable to remove.
> >
> > As for case folding, as soon as one adds a new case mapping in =
the
> Nameprep
> > profile, one needs to upgrade clients at the same time as =
servers.
> Oops.
> > Encoding the Nameprep version in queries would solve that, but
> obviously at
> > the cost of some other meaningful info in the label, thus =
reducing
> the
> > length of IDN names.
> >
> > YA
> >
> >
> >
> >
>
------=_NextPart_000_0B43_01C1AB3F.1D6433C0-- From owner-idn@ops.ietf.org Fri Feb 1 20:12: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 UAA15443 for ; Fri, 1 Feb 2002 20:12:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wodo-000HuM-00 for idn-data@psg.com; Fri, 01 Feb 2002 17:06:52 -0800 Received: from [211.218.145.193] (helo=postel2) by psg.com with esmtp (Exim 3.33 #1) id 16Wodn-000HuG-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 17:06:51 -0800 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g1216fH18420 for idn@ops.ietf.org; Sat, 2 Feb 2002 10:06:41 +0900 To: "Yves Arrouye" , idn@ops.ietf.org, "Paul Hoffman / IMC" Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g1216c618409; Sat, 2 Feb 2002 10:06:38 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 X-Msmail-Priority: Normal Message-Id: <022401c1ab85$d72c0170$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 From: "Soobok Lee" X-Priority: 3 References: <7FC3066C236FD511BC5900508BAC86FE9195EB@trestles.internal.realnames.com> X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 10:06:22 +0900 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjEwcHQnPgoK LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAKRnJvbSYjNTg7ICJQYXVs IEhvZmZtYW4gLyBJTUMiIDxwaG9mZm1hbkBpbWMub3JnPgpUbyYjNTg7ICJZ dmVzIEFycm91eWUiIDx5dmVzQHJlYWxuYW1lcy5jb20+OyA8aWRuQG9wcy5p ZXRmLm9yZz4KU2VudCYjNTg7IFNhdHVyZGF5LCBGZWJydWFyeSAwMiwgMjAw MiA3JiM1ODszNSBBTQpTdWJqZWN0JiM1ODsgUkUmIzU4OyBbaWRuXSBzdHJp bmdwcmVwIGNvbW1lbnQgMQoKCj4gQXQgMiYjNTg7MjYgUE0gLTA4MDAgMi8x LzAyLCBZdmVzIEFycm91eWUgd3JvdGUmIzU4Owo+ID4gID4gQ2xpZW50IEEg c2VuZHMgb3V0IGEgY2hhcmFjdGVyIHRoYXQgd2lsbCBuZXZlciBtYXRjaCBz b21ldGhpbmcgdGhhdAo+ID4+ICBjb3VsZCBiZSBzdG9yZWQgaW4gYSBuYW1l IHNlcnZlciB1bmRlciAtMDcgKGJlY2F1c2UgaXQgaXMgdW5hc3NpZ25lZCkK PiA+PiAgb3IgdW5kZXIgLTA4IG9yIGxhdGVyIChiZWNhdXNlIGl0IGlzIG1h cHBlZCB0byBub3RoaW5nKS4gV2h5IHdvdWxkCj4gPj4gIHlvdSBleHBlY3Qg dGhlIHNlcnZlciB0byBldmVyIG1hdGNoIGl0PyBXaGF0IGlzIHRoZSBwcm9i bGVtIGhlcmUgdGhhdAo+ID4+ICB5b3Ugc2VlIGFuZCB0aGF0IEkgZG9uJ3Q/ Cj4gPgo+ID5ObyBJIGRvbid0IGV4cGVjdCB0aGUgc2VydmVyIHRvIG1hdGNo IGl0LCBzaW5jZSBpdCBpcyBkZWxldGVkLiBBbGwgSSBhbQo+ID5zYXlpbmcg aXMgdGhhdCB0aGUgYXNzdW1wdGlvbiB0aGF0IGhhcyBiZWVuIHN0YXRlZCBo ZXJlIG1hbnkgdGltZXMgdGhhdCAiYW4KPiA+YXBwbGljYXRpb24gdGhhdCB1 c2VzIGEgZm9ybWVyIHZlcnNpb24gb2YgTmFtZXByZXAgdG8gc3BlYWsgdG8g YSBzZXJ2ZXIKPiA+dXNpbmcgYSBsYXRlciBvbmUgaGFzIG5vdGhpbmcgdG8g d29ycnkgYWJvdXQgYmVjYXVzZSBpdCBqdXN0IHBhc3NlcyBhbGwKPiA+dW5h c3NpZ25lZCBjb2RlcG9pbnRzIChmcm9tIGl0cyBmb3JtZXIgTmFtZXByZXAg cGVyc3BlY3RpdmUpIHRvIHRoZSBzZXJ2ZXIiCj4gPmlzIG5vdCB0cnVlLiBJ ZiB0aGF0IGFzc3VtcHRpb24gaXMgb2xkIC8gaGFzIGJlZW4gcmV2aXNlZCB0 aGVuIEkgYW0ganVzdAo+ID53YXN0aW5nIHlvdXIgYmFuZHdpZHRoICYjNTg7 KQo+IAo+IEkgdGhpbmsgc28uICYjNTg7LSkgIk5vdGhpbmcgdG8gd29ycnkg YWJvdXQiIG1lYW5zICJ0aGUgc2VydmVyIHdvbid0IAo+IGZhbHNlbHkgZ2l2 ZSBhIHBvc2l0aXZlIHJlc3VsdCB3aGVuIGl0IHNob3VsZCBoYXZlIGJlZW4g bmVnYXRpdmUiLiAKPiBZb3Ugc2hvdWxkIHdvcnJ5IGlmIHRoZSBwcm90b2Nv bCBoYWQgYSBzdGF0ZSB3aGVyZSB0aGUgY2xpZW50IHdhcyAKPiBhc2tpbmcg Zm9yIHNvbWV0aGluZyB0aGF0IHdvdWxkIG5ldmVyIGV4aXN0IGJ1dCB0aGUg c2VydmVyIGNvdWxkIAo+IG1pc3Rha2VubHkgZ2l2ZSBhIHBvc2l0aXZlIGFu c3dlci4KClRoZXJlIGFyZSBtYW55IGFwcGxpY2F0aW9ucyB0aGF0IGRvbid0 IGdpdmUgYmFjayBpbW1lZGlhdGUgbmVnYXRpdmUKYW5zd2VycyB0byBlbmQg dXNlcnMgLCByZWdhcmRlZCBhcyBpbXBsaWNpdGx5IHBvc2l0aXZlIGFuc3dl ci4KVGhlIGVuZCB1c2VycyBtYXkgYmVsaWV2ZSB0aGVpciB0cmFuc2FjdGlv bnMgCndlcmUgc3VjY2Vzc2Z1bCBhbmQgbGVhdmUgdGhlaXIgUEMgYW5kIGdv IHZhY2F0aW9uISAmIzU4Oy0pCgpNeSBoYWxmLWJha2VkIHN1Z2dlc3Rpb24g JiM1ODsKCjJyZCB0eXBlJiM1ODsgcXVlcmllcyB0aGF0ICppcyogY29tcGFy ZWQgYWdhaW5zdCBzdG9yZWQgc3RyaW5ncwppbW1lZGlhdGVseS4KCjNyZCB0 eXBlJiM1ODsgcXVlcmllcyB0aGF0IGlzICpub3QqIGNvbXBhcmVkIGFnYWlu c3Qgc3RvcmVkIHN0cmluZ3MKaW1tZWRpYXRlbHkgYW5kIG1heSBvciBtYXkg bm90IGdpdmUgYW5zd2Vycy4KCjR0aCB0eXBlJiM1ODsgcXVlcmllcyB0aGF0 IGFyZSBwb3N0ZW50aWFsbHkgZ29pbmcgdG8gYmUgY29tcGFyZWQgCndpdGgg YXQgbGVhc3QgYW5vdGhlciBxdWVyeSBvbiBhcHBsaWNhdGlvbnMgc2VydmVy cyB3aGljaCBkbyBub3QgCnJlZmVyIHRvIHRoZSBhdXRob3JpdGF0aXZlIElE TiBkYXRhIGZvciBjb21wYXJpc29ucy4KCkJ1dCB0aGlzIGRpc3RpbmN0aW9u IG1heSBub3QgY2xlYXIgdG8gaW1wbGVtZW50b3JzLCBzaW5jZQp0aG9zZSB0 eXBlcyBtYXkgb3ZlcmxhcCB0byBvbmUgYW5vdGhlci4gClF1ZXJpZXMgdGhh dCBoYXZlIDNyZCBhbmQgNHRoIHR5cGVzICByZXF1aXJlIHN0cm9uZyBuYW1l cHJlcC4KClNvb2JvayBMZWUKCgoKCj4gCj4gLS1QYXVsIEhvZmZtYW4sIERp cmVjdG9yCj4gLS1JbnRlcm5ldCBNYWlsIENvbnNvcnRpdW0KCjwvUFJFPgo8 aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZC8xMDEy NjExOTgyLTJhZjQxYzYxOTE2MDkyM2RhNTk0ZmM2ZTc0ZGIxOGNjLjQxZTVm ZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50 byB3aWR0aD0xIGhlaWdodD0xPjxpbWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBv c3RlbC5jby5rci9yZWFkcS8xMDEyNjExOTgyLTJhZjQxYzYxOTE2MDkyM2Rh NTk0ZmM2ZTc0ZGIxOGNjLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRm Lm9yZy5jb25maXJtLnBvc3RlbC50by9pZG5Ab3BzLmlldGYub3JnLmNvbmZp cm0ucG9zdGVsLnRvIHdpZHRoPTEgaGVpZ2h0PTE+CjwvQk9EWT4KPC9IVE1M Pgo= From owner-idn@ops.ietf.org Fri Feb 1 20:27: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 UAA15697 for ; Fri, 1 Feb 2002 20:27:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WoqT-000IJf-00 for idn-data@psg.com; Fri, 01 Feb 2002 17:19:57 -0800 To: "Mark Davis" , idn@ops.ietf.org Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g120Hn610030; Sat, 2 Feb 2002 09:17:49 +0900 MIME-Version: 1.0 X-Msmail-Priority: Normal Message-Id: <018601c1ab7f$0550c420$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 From: "Postel Services, Inc" X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sat, 2 Feb 2002 09:17:36 +0900 Content-Disposition: inline Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQu MCBUcmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAt ZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2MDAuMCIg bmFtZT1HRU5FUkFUT1I+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+CjxCT0RZ IGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48U1RST05HPjxGT05UIGZhY2U96rW0 66a8IHNpemU9Mj48L0ZPTlQ+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+CjxCTE9D S1FVT1RFIGRpcj1sdHIgCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVG VDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4KICA8 RElWIHN0eWxlPSJGT05UOiAxMHB0IOq1tOumvCI+LS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSA8L0RJVj4KICA8RElWIAogIHN0eWxlPSJCQUNLR1JP VU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IOq1tOumvDsgZm9udC1jb2xvcjog YmxhY2siPjxCPkZyb206PC9CPiA8QSAKICB0aXRsZT1tYXJrQG1hY2NoaWF0 by5jb20gaHJlZj0ibWFpbHRvOm1hcmtAbWFjY2hpYXRvLmNvbSI+TWFyayBE YXZpczwvQT4gCjwvRElWPgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW0 66a8Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWlkbkBvcHMuaWV0Zi5vcmcgCiAg aHJlZj0ibWFpbHRvOmlkbkBvcHMuaWV0Zi5vcmciPmlkbkBvcHMuaWV0Zi5v cmc8L0E+IDsgPEEgCiAgdGl0bGU9bHNiQHBvc3RlbC5jby5rciBocmVmPSJt YWlsdG86bHNiQHBvc3RlbC5jby5rciI+U29vYm9rIExlZTwvQT4gPC9ESVY+ CiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCDqtbTrprwiPjxCPlNlbnQ6PC9C PiBTYXR1cmRheSwgRmVicnVhcnkgMDIsIDIwMDIgNzo1NSAKICBBTTwvRElW PgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg6rW066a8Ij48Qj5TdWJqZWN0 OjwvQj4gUmU6IFtpZG5dIHN0cmluZ3ByZXAgY29tbWVudCAKMTwvRElWPgog IDxESVY+PEJSPjwvRElWPgogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+QXMgZGlzY3Vzc2VkIGJlZm9yZSwgY29tcGFyaXNvbnMgb25seSB3b3Jr IGlmIHlvdSAKICBhcmUgbWF0Y2hpbmcgPC9GT05UPjwvRElWPgogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgog IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+bG9vc2UgdnMgc3RyaWN0 IC8vIHdoZXJlIHRoZSBzdHJpY3QgaXMgCiAgYXV0aG9yaXRhdGl2ZTwvRk9O VD48L0RJVj4KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPnN0cmlj dCB2cyBzdHJpY3Q8L0ZPTlQ+PC9ESVY+CiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+CiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj5TaW1wbGUgdHJhbnNtaXNzaW9uIG9yIHN0b3Jl IGFuZCB0cmFuc21pc3Npb24gaXMgCiAgbm90IGFuIGlzc3VlLCBhcyBsb25n IGFzIG5vIGNvbXBhcmlzb24gaXMgbWFkZS48L0ZPTlQ+PC9ESVY+CiAgPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgogIDxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JMT0NLUVVPVEU+CjxE SVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+Jm5ic3A7U29tZSBhcHBsaWNhdGlv bnMmbmJzcDsgaW4gdGhlIGVuZCBvZiAKdHJhbnNtaXNzaW9uIHN1cmVseSBk byBjb21wYXJpc29ucyBvbiB0aGVtJm5ic3A7PC9GT05UPjxGT05UIHNpemU9 Mj4mbmJzcDtsYXRlciAKdGltZSBzaWxlbnRseSZuYnNwOy4gPC9GT05UPjwv RElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoZSBpbnRlcm1lZGlh dGUvZmluYWwgYXBwbGljYXRpb25zIG1heSBub3QgZ2l2ZSBiYWNrIAp0aGUg bmVnYXRpdmUgYW5zd2VycyB0byB0aGUgPC9GT05UPjwvRElWPgo8RElWIGRp cj1sdHI+PEZPTlQgc2l6ZT0yPm9yaWdpbmF0aW5nIGVuZCB1c2VycyBpbW1l ZGlhdGVseSBvciBmaW5hbGx5IG9yIGJvdGguIAplZykgc2VuZGluZyBlbWFp bHMgb3IgZW5saXN0aW5nIGluIHRoZSBvbmxpbmUgd2hpdGUgcGFnZS48L0ZP TlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoZWlyIGZh aWx1cmUgaXMgYXMgc2lsZW50IGFzIGFudGhyYXggdGhyZWF0LiAKYW5kPC9G T05UPjwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0yPlRoYXQnIGxp a2UgYSBsb3N0IGxhbmQgbWluZSB3aGljaCBzb21lIGNpdmlsIApjaGlsZHJl biZuYnNwOyBtYXkgc3RlcCBvbiAuPC9GT05UPjwvRElWPgo8RElWIGRpcj1s dHI+PEZPTlQgc2l6ZT0yPlRoZSBzb2xkaWVycyBkb24ndCBrbm93IHdoYXQm bmJzcDsgaGFwcGVucyB1bnRpbCB0aGV5IApnZXQgcmVwb3J0Jm5ic3A7dGhh dCBzb21lb25lIGxvc3QmbmJzcDsgdGhlaXIgZmVldCBieSB0aGUgbG9zdCAK bWluZS48L0ZPTlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPgo8RElWIGRpcj1sdHI+PEZPTlQgc2l6ZT0y PlNvb2JvayBMZWU8L0ZPTlQ+PC9ESVY+CjxESVYgZGlyPWx0cj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRy IApzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVw eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4 IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+CiAgPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5NYXJrPC9GT05UPjwvRElWPgogIDxESVY+ 4oCU4oCU4oCU4oCU4oCUPC9ESVY+CiAgPERJVj4mbmJzcDs8L0RJVj4KICA8 RElWPs6gz4zOu8674oCZIOG8oM+Azq/Pg8+EzrHPhM6/IOG8lM+BzrPOsSwg zrrOsc664b+2z4IgzrTigJkg4bygz4DOr8+Dz4TOsc+Ezr8gz4DOrM69z4TO sSDigJQg4b2JzrzOrs+Bzr/PhSDOnM6xz4HOs86vz4Thv4M8QlI+W0ZvciAK ICB0cmFuc2xpdGVyYXRpb24sIHNlZSA8QSAKICBocmVmPSJodHRwOi8vb3Nz LnNvZnR3YXJlLmlibS5jb20vY2dpLWJpbi9pY3UvdHIiPmh0dHA6Ly9vc3Mu c29mdHdhcmUuaWJtLmNvbS9jZ2ktYmluL2ljdS90cjwvQT5dPC9ESVY+CiAg PERJVj4mbmJzcDs8L0RJVj4KICA8RElWPjxBIGhyZWY9Imh0dHA6Ly93d3cu bWFjY2hpYXRvLmNvbSI+aHR0cDovL3d3dy5tYWNjaGlhdG8uY29tPC9BPjxC Uj48L0RJVj4KICA8QkxPQ0tRVU9URSAKICBzdHlsZT0iUEFERElORy1SSUdI VDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsg Qk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+CiAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPgogICAgPERJViAKICAg IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0IGFyaWFs OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IAogICAgPEEgdGl0 bGU9bHNiQHBvc3RlbC5jby5rciBocmVmPSJtYWlsdG86bHNiQHBvc3RlbC5j by5rciI+U29vYm9rIExlZTwvQT4gCiAgICA8L0RJVj4KICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4gPEEgdGl0bGU9aWRu QG9wcy5pZXRmLm9yZyAKICAgIGhyZWY9Im1haWx0bzppZG5Ab3BzLmlldGYu b3JnIj5pZG5Ab3BzLmlldGYub3JnPC9BPiA8L0RJVj4KICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIEZl YnJ1YXJ5IDAxLCAyMDAyIAogICAgMDk6MDc8L0RJVj4KICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6PC9CPiBSZTogW2lk bl0gc3RyaW5ncHJlcCBjb21tZW50IAogICAgMTwvRElWPgogICAgPERJVj48 QlI+PC9ESVY+PEZPTlQgc2l6ZT0rMT48UFJFIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KRnJvbTogIk1h cmsgRGF2aXMiIDxNQVJLQE1BQ0NISUFUTy5DT00+ClRvOiAiWXZlcyBBcnJv dXllIiA8WVZFU0BSRUFMTkFNRVMuQ09NPjsgIidNaWNoZWwgU3VpZ25hcmQn IiA8TUlDSEVMU1VATUlDUk9TT0ZULkNPTT47ICJQYXVsIEhvZmZtYW4gLyBJ TUMiIDxQSE9GRk1BTkBJTUMuT1JHPgpDYzogPElETkBPUFMuSUVURi5PUkc+ ClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAwMiwgMjAwMiAxOjE5IEFNClN1 YmplY3Q6IFJlOiBbaWRuXSBzdHJpbmdwcmVwIGNvbW1lbnQgMQoKCiZndDsg U3RyaW5ncHJlcCBrZWVwcyBpdHMgb3duIHRhYmxlcy4gV2hhdCBhbnkgaW1w bGVtZW50YXRpb24gb2YgVW5pY29kZQomZ3Q7IG5lZWRzIHRvIGRvIGlmIHRo ZXkgd2FudCB0byBtYWludGFpbiBzdHJpY3QgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkKJmd0OyBmb3IgY2FzZSBmb2xkaW5nIGlzIHRvIG9ubHkgKmFkZCog dG8gdGFibGVzIGluIHRoZSBmdXR1cmUsIG5vdCBjaGFuZ2UKJmd0OyB0aGUg dmFsdWVzIG9mIGNoYXJhY3RlcnMgdGhhdCBhcmUgYWxyZWFkeSBpbiB0aGUg dGFibGVzLgomZ3Q7CiZndDsgV2hpbGUgaXQgaXMgZXh0cmVtZWx5IHVubGlr ZWx5IHRoYXQgVW5pY29kZSB3aWxsIG1ha2UgYSBjaGFuZ2UgdGhhdAomZ3Q7 IGNhdXNlcyBwcm9ibGVtcyBmb3IgbmFtZXByZXAsIHVzaW5nIHRoZSBhYm92 ZSBzdHJhdGVneSBndWFyYW50ZWVzCiZndDsgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkuCiZndDsKJmd0OyBUbyByZXBlYXQsIHRoZSBsb29zZSB2cyBzdHJp Y3QgYXBwcm9hY2ggd29ya3MgYXMgZm9sbG93czoKJmd0OwomZ3Q7IFN1cHBv c2UgdGhlIGNsaWVudCBpcyBVbmljb2RlIDMuMSBhbmQgdGhlIHNlcnZlciBp cyBVbmljb2RlIDQuMC4gQXMKJmd0OyBsb25nIGFzIHRoZSBjbGllbnQgcHJv ZHVjZXMgbmFtZXMgdGhhdCBhcmUgb25seSAzLjEsIG5vIHByb2JsZW0uCiZn dDsgU3RyaW5ncHJlcCBvbiB0aGUgY2xpZW50IHdpbGwgcHJvZHVjZSByZXN1 bHRzIHRoYXQgdGhlIHNlcnZlciBhY2NlcHRzLgomZ3Q7CiZndDsgU3VwcG9z ZSB0aGUgdXNlciBoYXMgY2hhcmFjdGVycyB0aGF0IGFyZSB1bmFzc2lnbmVk IGluIDMuMSAoYnV0IGFyZSBpbgomZ3Q7IDQuMCkuIEFzIGxvbmcgYXMgdGhl IHVzZXIgKG1hbnVhbGx5KSBwaWNrcyBsb3dlcmNhc2UgY2hhcmFjdGVycyAo aW4KJmd0OyB0aGUgcmlnaHQgY2Fub25pY2FsIGZvcm0pLCB0aG9zZSBuYW1l cyB3aWxsIGJlIGFjY2VwdGVkIGJ5IHRoZSA0LjAKJmd0OyBzZXJ2ZXIuIFdo aWxlIGl0IGlzIG5vdCBhcyBlYXN5IGFzIHdoZW4gdGhlIHNvZnR3YXJlIGRv ZXMgaXQgZm9yIHRoZQomZ3Q7IHVzZXIsIGl0IHdpbGwgd29yayBmb3IgYW55 IG5ldyBjaGFyYWN0ZXJzLgomZ3Q7CiZndDsgVGhpcyBpcyBpbXBvcnRhbnQg Zm9yIGFub3RoZXIgc2NlbmFyaW8uIENsaWVudCBBIGlzIG9uIFVuaWNvZGUg NC4wLAomZ3Q7IGNsaWVudCBCIGlzIG9uIFVuaWNvZGUgMy4xLCBhbmQgdGhl IHNlcnZlciBpcyBvbiBVbmljb2RlIDQuMC4gQ2xpZW50IEEKJmd0OyBuYW1l cHJlcHMgYSBzdHJpbmcsIHNlbmRzIHRvIGNsaWVudCBCLiBDbGllbnQgQiBz ZW5kcyB0aGUgc3RyaW5nIG9uIHRvCiZndDsgdGhlIHNlcnZlci4gRXZlcnl0 aGluZyB3b3Jrcy4gSXQgZXZlbiB3b3JrcyBpZiBjbGllbnQgQiByZS1uYW1l cHJlcHMKJmd0OyB0aGUgc3RyaW5nLgoKV291bGQgeW91IGNsYXJpZnkgeW91 ciBhc3NlcnRpb24gZm9yIHBlZXItdG8tcGVlciB0cmFuc2FjdGlvbnMgPwoK RXZlbiBpbiBzb21lIGNsaWVudCB0byBzZXJ2ZXIgdHJhbnNhY3Rpb25zLCBz ZXJ2ZXIgc2lkZXMgbWF5IGhhdmUKbm8gcGVyc2lzdGFudC9zdG9yZWQgc3Ry aW5ncyAobm90LWF1dGhvcml0YXRpdmUpICB0byBjb21wYXJlIGFnYWluc3Qg dGhlIHF1ZXJpZXMsIGJ1dApqdXN0IHN0b3JlIGFuZCB0cnVzdCBvciB0cmFu c21pdCB3aXRob3V0IGdpdmluZyBiYWNrIG5vIG5lZ2F0aXZlIHJlc3BvbnNl Li4KClNvb2JvayBMZWUKCiZndDsKJmd0OyBNYXJrCiZndDsg4oCU4oCU4oCU 4oCU4oCUCiZndDsKJmd0OyDOoM+MzrvOu+KAmSDhvKDPgM6vz4PPhM6xz4TO vyDhvJTPgc6zzrEsIM66zrHOuuG/ts+CIM604oCZIOG8oM+Azq/Pg8+EzrHP hM6/IM+AzqzOvc+EzrEg4oCUIOG9ic68zq7Pgc6/z4UgzpzOsc+BzrPOr8+E 4b+DCiZndDsgW0ZvciB0cmFuc2xpdGVyYXRpb24sIHNlZSBodHRwOi8vb3Nz LnNvZnR3YXJlLmlibS5jb20vY2dpLWJpbi9pY3UvdHJdCiZndDsKJmd0OyBo dHRwOi8vd3d3Lm1hY2NoaWF0by5jb20KJmd0OwomZ3Q7IC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0KJmd0OyBGcm9tOiAiWXZlcyBBcnJvdXllIiA8 WVZFU0BSRUFMTkFNRVMuQ09NPgomZ3Q7IFRvOiAiJ01pY2hlbCBTdWlnbmFy ZCciIDxNSUNIRUxTVUBNSUNST1NPRlQuQ09NPjsgIlBhdWwgSG9mZm1hbiAv IElNQyIKJmd0OyA8UEhPRkZNQU5ASU1DLk9SRz4KJmd0OyBDYzogPElETkBP UFMuSUVURi5PUkc+CiZndDsgU2VudDogVGh1cnNkYXksIEphbnVhcnkgMzEs IDIwMDIgMjI6NTEKJmd0OyBTdWJqZWN0OiBSRTogW2lkbl0gc3RyaW5ncHJl cCBjb21tZW50IDEKJmd0OwomZ3Q7CiZndDsgJmd0OyAmZ3Q7IE5vdCBhIGNo YW5jZS4gVW5pY29kZSBhbmQgSVNPIDEwNjQ2IGNvbGxlY3QgaW4gZmFjdCBz b21lIHVubmVlZGVkCiZndDsgY3J1bWJzCiZndDsgJmd0OyAmZ3Q7IHRoYXQg d2F5LiBPbmNlIGEgY2hhcmFjdGVyIGlzIG9mZmljaWFsbHkgYXBwcm92ZWQg Zm9yIGluY2x1c2lvbiBpdAomZ3Q7IGlzCiZndDsgJmd0OyAmZ3Q7IHRoZXJl IGZvcmV2ZXIsIHdoYXRldmVyIHdlIGRvbid0IGxpa2UgaXQgb3Igbm90LiBD aGFyYWN0ZXJzIGdldAomZ3Q7ICZndDsgJmd0OyBkZXByZWNhdGVkIChpLmUu IHVzYWdlIGRpc2NvdXJhZ2VkKSBidXQgbmV2ZXIgcmVtb3ZlZC4gVGhpcyBp cyB0aGUKJmd0OyBwcmljZQomZ3Q7ICZndDsgJmd0OyB5b3UgaGF2ZSB0byBw YXkgZm9yIHN0YWJpbGl0eSBhbmQgdXNhZ2UgYnkgb3RoZXIgc3BlY2lmaWNh dGlvbgomZ3Q7IChsaWtlCiZndDsgJmd0OyAmZ3Q7IElETikuCiZndDsgJmd0 OwomZ3Q7ICZndDsgU29ycnksIEkgZGlkIG5vdCBtZWFuIHJlbW92ZWQgZnJv bSBVbmljb2RlIChJIGFtIGF3YXJlIG9mIHRoZSBydWxlCiZndDsgdGhlcmUs CiZndDsgJmd0OyB3aGljaCBtYWtlcyBzZW5zZSksIEkgbWVhbnQgb25lIGNo YXJhY3RlciB0aGF0IGlzIGFkZGVkIHRvIFVuaWNvZGUKJmd0OyBidXQgdGhh dAomZ3Q7ICZndDsgYSBnaXZlbiBTdHJpbmdwcmVwIHByb2ZpbGUgd291bGQg dGhpbmsgZGVzaXJhYmxlIHRvIHJlbW92ZS4KJmd0OyAmZ3Q7CiZndDsgJmd0 OyBBcyBmb3IgY2FzZSBmb2xkaW5nLCBhcyBzb29uIGFzIG9uZSBhZGRzIGEg bmV3IGNhc2UgbWFwcGluZyBpbiB0aGUKJmd0OyBOYW1lcHJlcAomZ3Q7ICZn dDsgcHJvZmlsZSwgb25lIG5lZWRzIHRvIHVwZ3JhZGUgY2xpZW50cyBhdCB0 aGUgc2FtZSB0aW1lIGFzIHNlcnZlcnMuCiZndDsgT29wcy4KJmd0OyAmZ3Q7 IEVuY29kaW5nIHRoZSBOYW1lcHJlcCB2ZXJzaW9uIGluIHF1ZXJpZXMgd291 bGQgc29sdmUgdGhhdCwgYnV0CiZndDsgb2J2aW91c2x5IGF0CiZndDsgJmd0 OyB0aGUgY29zdCBvZiBzb21lIG90aGVyIG1lYW5pbmdmdWwgaW5mbyBpbiB0 aGUgbGFiZWwsIHRodXMgcmVkdWNpbmcKJmd0OyB0aGUKJmd0OyAmZ3Q7IGxl bmd0aCBvZiBJRE4gbmFtZXMuCiZndDsgJmd0OwomZ3Q7ICZndDsgWUEKJmd0 OyAmZ3Q7CiZndDsgJmd0OwomZ3Q7ICZndDsKJmd0OyAmZ3Q7CiZndDsKCjwv UFJFPjxJTUcgaGVpZ2h0PTEgCiAgICBzcmM9Imh0dHA6Ly9wb3N0ZWwyLnBv c3RlbC5jby5rci9yZWFkLzEwMTI1ODMyNjctMmFmNDFjNjE5MTYwOTIzZGE1 OTRmYzZlNzRkYjE4Y2MuNDFlNWZkNmYxOTdlYmMxMC9pZG5Ab3BzLmlldGYu b3JnLmNvbmZpcm0ucG9zdGVsLnRvIiAKICAgIHdpZHRoPTE+IDwvRk9OVD48 L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPgo8aW1nIHNyYz1odHRwOi8vcG9z dGVsMi5wb3N0ZWwuY28ua3IvcmVhZC8xMDEyNjA5MDU2LWFkMzViODI3OTEw MjViMTFhNTk0Yjk2ODQxMjNiYWYyLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9w cy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0x PjxpbWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5jby5rci9yZWFkcS8x MDEyNjA5MDU2LWFkMzViODI3OTEwMjViMTFhNTk0Yjk2ODQxMjNiYWYyLjQx ZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3Rl bC50by9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRvIHdpZHRo PTEgaGVpZ2h0PTE+CjwvQk9EWT4KPC9IVE1MPgo= From owner-idn@ops.ietf.org Fri Feb 1 21:49: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 VAA17773 for ; Fri, 1 Feb 2002 21:49:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wq36-000KoF-00 for idn-data@psg.com; Fri, 01 Feb 2002 18:37:04 -0800 From: John C Klensin To: Erin Chen , IESG , IAB , IETF IDN WG , "Vinton G. Cerf" , "Masanobu Katoh" , harald , Fred baker , Stuart Lynn , Paul Haffman , Mohamed Sharil Tarmizi , JET Members , Thomas Narten , Erik Nordmark , Andrew McLaughlin , "H. T. Kung" , Marc Blanchet , "James Seng/Personal" , Masanobu Katoh , Mouhamet Diop , "Patrik F?lstr?m" , Qiheng Hu , Sang-Hyon Kyong , Elisabeth Porteneuve cc: hlqian , mao , Zhang Wen Hui , xiang deng , xiaodong lee , , hoho , Kenny Huang , Chun-Hsin Wu , sstseng , Wen-Sung Chen , Nai-Wen Hsu , yktham , jasonho , alanysho , christine Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Message-ID: <178475239.1012596275@localhost> In-Reply-To: <3C5A6DAE.9040905@twnic.net.tw> References: <3C5A6DAE.9040905@twnic.net.tw> X-Mailer: Mulberry/2.1.2 (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 Date: Fri, 01 Feb 2002 18:37:04 -0800 Content-Transfer-Encoding: 7bit Erin, Let me follow up Vint's note with some thoughts of my own, with the understanding that they are mine personally and may not reflect positions I would feel obligated to take as technical advisor to the IDN WG or as a member of the IAB; the WG or the IAB might well disagree with what I'm about to say. I believe it has been fairly well demonstrated by this point that there are _many_ problems that the protocols specified in the IDN WG core documents will not solve. Many of these problems involve Chinese Domain Names, many others do not. At the root of most of both types of problems lies a distinction between "identifiers" -- character strings used in narrow contexts and to which many restrictive rules can be applied-- and "user-visible names". The latter must obey the rules of the languages in which they are constructed and written. If they do not, confusion and astonishment results. But, while some issues can be addressed with sufficient ingenuity, the DNS cannot, in general, solve user-visible name problems within the current design and basic DNS protocols. Again, this raises especially difficult problems for Chinese names, but there are problems of one sort or another with most languages. The solutions for those user-visible name problems, as we discussed in Minneapolis, lie in non-DNS mechanisms, protocols, and database, not in the DNS or the IDN WG's effort to fit some extra characters into the DNS. As we look at the IDN WG's efforts, it is important to remember, first, that Unicode (ISO 10646) is a tool. It is a tool that is better suited to some purposes than to others and it is one that was designed in the context of very complex tradeoffs. The WG chose to use that tool, largely because, given _their_ constraints, there were no plausible alternatives. Similarly, we should view the IDN WG's outputs --if, indeed, IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out to be the outputs-- to be tools. They are not a perfect tool. It is easy to find problems they don't solve, and problems with characters that have equivalent meanings and different appearances and code points (as in TC<->SC mapping) and characters that have similar or identical appearances but belong to different scripts and have different code points (as in matching characters in Latin, Greek, and Cyrillic scripts) are high on that list of unsolved problems. But, again, they are a tool, and, while it quite drastic, I suggest that there is a registration-based solution if that tool is inappropriate. The IDN WG also has the constraints, ultimately imposed by the DNS architecture, that it cannot make a decision that solves a problem for Greek at the expense of Cyrillic, nor can it make one that solves a Chinese problem at the expense of making Japanese or Korean unusable. Perhaps the more subtle matching and equivalence problems are sufficient to make the whole notion unusable, at least for user-visible names. While I suspect that might be true, the argument has not been convincingly made. This suggests some actions you might consider: (i) Your colleagues argued quite persuasively in Minneapolis that the difficulties imposed by the IDN WG approach on Chinese-Language Domain names would cause serious consumer confusion and disruption and could be expected to provide an unreasonably good opportunity for fraudulent behavior. I believe that I understand that argument, but many of the people to whom your statement was addressed probably do not. I would strongly suggest that you try to produce a document that explains the problems, in a tutorial style, and at a level adequate to educate someone with no knowledge of Chinese and, perhaps no working knowledge of any script other than his or her own. (ii) If registrations of CDNs are dangerous, prohibit them in your own ccTLDs and, with the document mentioned above as a tool, recommend to ICANN and directly to other domain administrators (top-level and otherwise) that these codes not be registered. That advice will, I fear inevitably, be ignored in some places. But, if the explanation of the consumer risks is clear enough, governments, regulators, and injured parties will have solid grounds for holding registrars who promote the use of such names responsible for any problems they cause. (iii) Please continue to work with me and with others to develop non-DNS solutions for user-visible names that do meet your needs by accomodating matching that uses language and other information in ways that the DNS cannot. thanks and regards, john --On Friday, 01 February, 2002 18:27 +0800 Erin Chen wrote: > -------------------------------------------------------------- > ----------- Chinese Domain Name Consortium (CDNC) > Declaration > -------------------------------------------------------------- > ----------- > > Based on current status of Internationalized Domain Name, CDNC > makes following declaration: > > 1. Currently, IETF IDN WG begins Last Call for the WG core > documents (IDNA, NAMEPREP, STRINGPREP, and PUNYCODE). > > But, the architecture of IDN defined in above four documents > does not solve the traditional and simplified Chinese > character variant problem. That will cause serious delegation > problem in the application of Chinese Domain Name. This > technical flaw can't be compensated by registration policy; > it'll prevent Chinese Domain Name from being used widely. All > the future Internet applications based on Chinese Domain Name > hierarchy will fail and ultimately Chinese Domain Name > technology will result in failure. > > 2. Under the commercial and social pressure, IETF IDN WG > issues Last Call hastily without presenting a proper Chinese > Domain Name technical solution. It will be detrimental to the > ethnic-Chinese Internet community. > > 3. IETF IDN WG does not solve Chinese Domain Name technical > problem, but it is IETF IDN WG's responsibility to sincerely > consider the consequences from adopting these drafts. Under > the current condition, if IETF approves these IDN drafts, > registrars will open Chinese Domain Name registration without > considering the requirement of Chinese Domain Name and > Chinese Domain Name will fall into confusion. This will damage > Chinese Internet community seriously. > > 4. IDN would be flawed by not adopting CDN requirements. > > Chinese Domain Name Consortium > CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC > Co-chair of CDNC: Qian Hualin, Professor > Co-chair of CDNC: Shian-Shyong Tseng, Professor > 2002.2.1 > -------------------------------------------------------------- > ------------- > > > > > > > From owner-idn@ops.ietf.org Fri Feb 1 22:19: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 WAA18063 for ; Fri, 1 Feb 2002 22:19:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wqbh-000LyA-00 for idn-data@psg.com; Fri, 01 Feb 2002 19:12:49 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Wqbg-000Ly4-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 19:12:48 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g123Ci326415 for ; Fri, 1 Feb 2002 19:12:44 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <022401c1ab85$d72c0170$ec1bd9d2@temp> References: <7FC3066C236FD511BC5900508BAC86FE9195EB@trestles.internal.realnames.com> <022401c1ab85$d72c0170$ec1bd9d2@temp> Date: Fri, 1 Feb 2002 19:06:19 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] stringprep comment 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:06 AM +0900 2/2/02, Soobok Lee wrote: >There are many applications that don't give back immediate negative >answers to end users , regarded as implicitly positive answer. >The end users may believe their transactions >were successful and leave their PC and go vacation! :-) So, how is this different than today's DNS? You keep bringing up vague comparisons with no concrete examples. It sounds like you really believe what you are saying, but the rest of us cannot figure out if what you are saying has any merit to it unless you get much more specific. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 1 23:27: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 XAA19732 for ; Fri, 1 Feb 2002 23:27:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WrfC-000O7C-00 for idn-data@psg.com; Fri, 01 Feb 2002 20:20:30 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.33 #1) id 16WrfB-000O73-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 20:20:30 -0800 Received: (qmail 13591 invoked by uid 1001); 2 Feb 2002 04:19:26 -0000 Date: 2 Feb 2002 04:19:26 -0000 Message-ID: <20020202041926.32253.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt References: <68530000.1012237553@classic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk These ``Last Calls'' are absurd. The claims of consensus are fraudulent. Huge objections remain unaddressed. It is shameful that such a massive change to such a basic part of the Internet architecture is being handled in such a careless way. The proposals at hand are contrary to the interests of my users. I am speaking here as the author of * the mail software with the Internet's largest increase in SMTP-server deployment over the past 18 months (reaching #2 in total deployment, behind only Sendmail); and * the DNS software with the Internet's largest increase in domain-name deployment over the past 18 months (reaching #2 in total deployment, behind only BIND). I refuse to implement the proposals in their current form. ---Dan From owner-idn@ops.ietf.org Sat Feb 2 02:17: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 CAA29712 for ; Sat, 2 Feb 2002 02:17:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WuCz-0003ES-00 for idn-data@psg.com; Fri, 01 Feb 2002 23:03:33 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.33 #1) id 16WuCy-0003EM-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 23:03:32 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16WuCx-0003MC-00 for ; Fri, 01 Feb 2002 23:03:31 -0800 Date: Sat, 2 Feb 2002 07:03:31 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Message-ID: <20020202070330.GB10310@nicemice.net> Reply-To: IETF idn working group References: <68530000.1012237553@classic> <20020202041926.32253.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020202041926.32253.qmail@cr.yp.to> User-Agent: Mutt/1.3.25i Sender: owner-idn@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: > I am speaking here as the author of > > * the mail software with the Internet's largest increase... > * the DNS software with the Internet's largest increase... > > I refuse to implement the proposals in their current form. Good heavens, what will we do if qmail and djbdns won't support IDNA? Oh wait, they *already do*, because IDNA doesn't depend on any changes to existing DNS servers and mail transport agents. AMC From owner-idn@ops.ietf.org Sat Feb 2 02:29: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 CAA29848 for ; Sat, 2 Feb 2002 02:29:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WuSh-0006Xm-00 for idn-data@psg.com; Fri, 01 Feb 2002 23:19:47 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.33 #1) id 16WuSg-0006Xg-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 23:19:46 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16WuSf-0003Ok-00 for ; Fri, 01 Feb 2002 23:19:45 -0800 Date: Sat, 2 Feb 2002 07:19:45 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] stringprep comment 1 Message-ID: <20020202071945.GC10310@nicemice.net> Reply-To: IETF idn working group References: <7FC3066C236FD511BC5900508BAC86FE9195CE@trestles.internal.realnames.com> <006a01c1ab3c$376248a0$08d8ea0c@c1340594a> <00de01c1ab42$f8fd0fd0$ec1bd9d2@temp> <007201c1ab73$9c053420$08d8ea0c@c1340594a> <01a501c1ab7f$8daf3270$ec1bd9d2@temp> <0b4701c1ab82$2bcdcb90$08d8ea0c@c1340594a> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b4701c1ab82$2bcdcb90$08d8ea0c@c1340594a> User-Agent: Mutt/1.3.25i Sender: owner-idn@ops.ietf.org Precedence: bulk Mark Davis wrote: > When stringprep is used correctly, loose vs loose comparisons alone > will never happen. At the very least, we need to spell that out in the stringprep spec. We need to say that the ultimate purpose of the guidelines about "stored strings" and "query strings" is to make sure that two loosely prepared strings are never compared. That will at least give people a better chance of figuring out when they can safely use loose stringprep. I also suggest adding an explicit requirement that applications must use strict stringprep whenever there is doubt. They may use loose stringprep only when they know that the string will not be compared with another loosely prepared string (for example, when they are putting the string into a protocol slot that is used only for comparisons with strictly prepared strings; DNS queries qualify if we add a requirement to IDNA prohibiting DNS servers from serving loosely-prepared names). I think that's the least we should do. We could go even further and always prohibit unassigned code points. That would occasionally inconvenience people (who would have to upgrade their software), but would be a lot simpler and would avoid confusing people when new characters silently fail to match. AMC From owner-idn@ops.ietf.org Sat Feb 2 02:40: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 CAA29995 for ; Sat, 2 Feb 2002 02:40:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WuhC-000774-00 for idn-data@psg.com; Fri, 01 Feb 2002 23:34:46 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.33 #1) id 16WuhC-00076x-00 for idn@ops.ietf.org; Fri, 01 Feb 2002 23:34:46 -0800 Received: (qmail 5282 invoked by uid 1001); 2 Feb 2002 07:33:44 -0000 Date: 2 Feb 2002 07:33:44 -0000 Message-ID: <20020202073344.15904.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt References: <68530000.1012237553@classic> <20020202041926.32253.qmail@cr.yp.to> <20020202070330.GB10310@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Adam M. Costello writes: > IDNA doesn't depend on any changes > to existing DNS servers and mail transport agents. False. See http://cr.yp.to/proto/idn.html for a detailed list of the changes required to make your proposals work. The list includes changes to DNS servers, SMTP servers, and many other programs. I realize that you claim that IDNs are already ``working'' on every Internet computer today. That's because you have an idiotic definition of what it means for an IDN to ``work.'' You say that calling a string an IDN makes it an IDN, even if users read and write it as ASCII. In contrast, every user I've talked to thinks that non-ASCII displays are the whole point of IDN, and considers ASCII mangling of a so-called IDN to be a failure, just as a Quoted-Printable display is a failure. ---Dan From owner-idn@ops.ietf.org Sat Feb 2 03:10: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 DAA00277 for ; Sat, 2 Feb 2002 03:10:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WvAm-00080F-00 for idn-data@psg.com; Sat, 02 Feb 2002 00:05:20 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16WvAk-000809-00 for idn@ops.ietf.org; Sat, 02 Feb 2002 00:05:18 -0800 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 AAA09659; Sat, 2 Feb 2002 00:05:15 -0800 Message-Id: <5.1.0.14.2.20020201235625.01c28d20@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Feb 2002 23:57:40 -0800 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Cc: idn@ops.ietf.org In-Reply-To: <20020202073344.15904.qmail@cr.yp.to> References: <68530000.1012237553@classic> <20020202041926.32253.qmail@cr.yp.to> <20020202070330.GB10310@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 07:33 AM 2/2/2002 +0000, D. J. Bernstein wrote: >IDN to be a failure, just as a Quoted-Printable display is a failure. and, no doubt, just as mime is a failure. give it a rest, Dan. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Sat Feb 2 03:57: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 DAA00646 for ; Sat, 2 Feb 2002 03:57:07 -0500 (EST) From: owner-idn@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Wvue-000A2Q-00 for idn-data@psg.com; Sat, 02 Feb 2002 00:52:44 -0800 Message-Id: To: idn-data@psg.com Date: Sat, 02 Feb 2002 00:52:44 -0800 Sat, 2 Feb 2002 09:10:26 +0100 (MET) Date: Sat, 2 Feb 2002 09:10:26 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200202020810.JAA06777@balsa.cetp.ipsl.fr> To: Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net Cc: alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Sender: owner-idn@ops.ietf.org Precedence: bulk If I may add a note on Latin-Cyrillic confusion. Quoted from an explanation I have been providing to another group. An aside note - I learnt from Russian colleagues that some Russian favor to register domain names under .PY (ccTLD for Paraguay) rather that .RU (ccTLD for Russia). The reason is that "PY" is the beginning of the word "Russia" in Cyrillic - PYCCU[R]. The last caracter is Cyrillic "ya", see below, any other is identical printing in Latin and Cyrillic, different code points in Unicode, identical code point in "LDH". Best regards, Elisabeth Porteneuve -- Let have a glimpse on both end-user and intellectual property perspectives with an example. The word "COBET" reads as it is if one assumes it is Latin alphabet, but spells "soviet" if one assumes it is Cyrillic. The Unicode code point representation for Cyrillic "C", 0x0421, is different from code point representation for Latin "C", 0x0043, but they are identical on a printed paper, business cards or a screen. Taking into account the above, a usage of Unicode code points subsequently makes it impossible to communicate with anybody without knowing which language is _printed_, or, even worst, which letter or sign is printed in which language. In the famous TOYS[R]US the R in brackets is a Cyrillic code point 0x042f spelled "ya", which also happen to be the letter R seen as in mirror, spelled "are". With the exception of that letter [R], any other one in TOYS[R]US may be read either as Latin or as Cyrillic code point, different spellings, different code points, identical printing on paper or screen. In an example of a word of 6 code points, with the same printing but 2 different contents there is 2**6 = 64 possible combinations It is the number of times a 6 letters word should be registered to preserve its whole intellectual property rights in 2 alphabets, Latin and Cyrillic. It is also the maximal number of tries an end-user should made to get to a website, if she or he got only a printed information. I have no competencies to expand this example to other alphabets or code points. Hovever, as far as I understand, the problem of Chinese code points have some similarity. -- From owner-idn@ops.ietf.org Sat Feb 2 04:32: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 EAA01033 for ; Sat, 2 Feb 2002 04:32:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WwRO-000AxX-00 for idn-data@psg.com; Sat, 02 Feb 2002 01:26:34 -0800 From: John C Klensin To: Erin Chen , IESG , IAB , IETF IDN WG Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Message-ID: <178475239.1012596275@localhost> In-Reply-To: <3C5A6DAE.9040905@twnic.net.tw> References: <3C5A6DAE.9040905@twnic.net.tw> X-Mailer: Mulberry/2.1.2 (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 Date: Sat, 02 Feb 2002 01:26:34 -0800 Content-Transfer-Encoding: 7bit [Note: Header line too long so To: & Cc: line have been snapped - JS] Erin, Let me follow up Vint's note with some thoughts of my own, with the understanding that they are mine personally and may not reflect positions I would feel obligated to take as technical advisor to the IDN WG or as a member of the IAB; the WG or the IAB might well disagree with what I'm about to say. I believe it has been fairly well demonstrated by this point that there are _many_ problems that the protocols specified in the IDN WG core documents will not solve. Many of these problems involve Chinese Domain Names, many others do not. At the root of most of both types of problems lies a distinction between "identifiers" -- character strings used in narrow contexts and to which many restrictive rules can be applied-- and "user-visible names". The latter must obey the rules of the languages in which they are constructed and written. If they do not, confusion and astonishment results. But, while some issues can be addressed with sufficient ingenuity, the DNS cannot, in general, solve user-visible name problems within the current design and basic DNS protocols. Again, this raises especially difficult problems for Chinese names, but there are problems of one sort or another with most languages. The solutions for those user-visible name problems, as we discussed in Minneapolis, lie in non-DNS mechanisms, protocols, and database, not in the DNS or the IDN WG's effort to fit some extra characters into the DNS. As we look at the IDN WG's efforts, it is important to remember, first, that Unicode (ISO 10646) is a tool. It is a tool that is better suited to some purposes than to others and it is one that was designed in the context of very complex tradeoffs. The WG chose to use that tool, largely because, given _their_ constraints, there were no plausible alternatives. Similarly, we should view the IDN WG's outputs --if, indeed, IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out to be the outputs-- to be tools. They are not a perfect tool. It is easy to find problems they don't solve, and problems with characters that have equivalent meanings and different appearances and code points (as in TC<->SC mapping) and characters that have similar or identical appearances but belong to different scripts and have different code points (as in matching characters in Latin, Greek, and Cyrillic scripts) are high on that list of unsolved problems. But, again, they are a tool, and, while it quite drastic, I suggest that there is a registration-based solution if that tool is inappropriate. The IDN WG also has the constraints, ultimately imposed by the DNS architecture, that it cannot make a decision that solves a problem for Greek at the expense of Cyrillic, nor can it make one that solves a Chinese problem at the expense of making Japanese or Korean unusable. Perhaps the more subtle matching and equivalence problems are sufficient to make the whole notion unusable, at least for user-visible names. While I suspect that might be true, the argument has not been convincingly made. This suggests some actions you might consider: (i) Your colleagues argued quite persuasively in Minneapolis that the difficulties imposed by the IDN WG approach on Chinese-Language Domain names would cause serious consumer confusion and disruption and could be expected to provide an unreasonably good opportunity for fraudulent behavior. I believe that I understand that argument, but many of the people to whom your statement was addressed probably do not. I would strongly suggest that you try to produce a document that explains the problems, in a tutorial style, and at a level adequate to educate someone with no knowledge of Chinese and, perhaps no working knowledge of any script other than his or her own. (ii) If registrations of CDNs are dangerous, prohibit them in your own ccTLDs and, with the document mentioned above as a tool, recommend to ICANN and directly to other domain administrators (top-level and otherwise) that these codes not be registered. That advice will, I fear inevitably, be ignored in some places. But, if the explanation of the consumer risks is clear enough, governments, regulators, and injured parties will have solid grounds for holding registrars who promote the use of such names responsible for any problems they cause. (iii) Please continue to work with me and with others to develop non-DNS solutions for user-visible names that do meet your needs by accomodating matching that uses language and other information in ways that the DNS cannot. thanks and regards, john --On Friday, 01 February, 2002 18:27 +0800 Erin Chen wrote: > -------------------------------------------------------------- > ----------- Chinese Domain Name Consortium (CDNC) > Declaration > -------------------------------------------------------------- > ----------- > > Based on current status of Internationalized Domain Name, CDNC > makes following declaration: > > 1. Currently, IETF IDN WG begins Last Call for the WG core > documents (IDNA, NAMEPREP, STRINGPREP, and PUNYCODE). > > But, the architecture of IDN defined in above four documents > does not solve the traditional and simplified Chinese > character variant problem. That will cause serious delegation > problem in the application of Chinese Domain Name. This > technical flaw can't be compensated by registration policy; > it'll prevent Chinese Domain Name from being used widely. All > the future Internet applications based on Chinese Domain Name > hierarchy will fail and ultimately Chinese Domain Name > technology will result in failure. > > 2. Under the commercial and social pressure, IETF IDN WG > issues Last Call hastily without presenting a proper Chinese > Domain Name technical solution. It will be detrimental to the > ethnic-Chinese Internet community. > > 3. IETF IDN WG does not solve Chinese Domain Name technical > problem, but it is IETF IDN WG's responsibility to sincerely > consider the consequences from adopting these drafts. Under > the current condition, if IETF approves these IDN drafts, > registrars will open Chinese Domain Name registration without > considering the requirement of Chinese Domain Name and > Chinese Domain Name will fall into confusion. This will damage > Chinese Internet community seriously. > > 4. IDN would be flawed by not adopting CDN requirements. > > Chinese Domain Name Consortium > CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC > Co-chair of CDNC: Qian Hualin, Professor > Co-chair of CDNC: Shian-Shyong Tseng, Professor > 2002.2.1 > -------------------------------------------------------------- > ------------- > > > > > > > From owner-idn@ops.ietf.org Sat Feb 2 11:48: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 LAA05401 for ; Sat, 2 Feb 2002 11:48:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16X31X-000MEk-00 for idn-data@psg.com; Sat, 02 Feb 2002 08:28:19 -0800 From: John C Klensin To: Erin Chen , IESG , IAB , IETF IDN WG Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Message-Id: Date: Sat, 02 Feb 2002 08:28:19 -0800 (correction) Message-ID: <6315254.1012648130@localhost> X-Mailer: Mulberry/2.1.2 (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 [Note: header line too long error - To & Cc list snapped - JS] My apologies to everyone on this distribution whom I may have confused... I have been thinking about the upcoming IETF meeting in Minneapolis, and my note mentioned discussions in Minneapolis when I intended to say "Salt Lake City". I don't know if this implies that I have lost track of where or when I am, but my apologies in any event. john From owner-idn@ops.ietf.org Sun Feb 3 05:39: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 FAA23739 for ; Sun, 3 Feb 2002 05:39:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XJl6-0004k3-00 for idn-data@psg.com; Sun, 03 Feb 2002 02:20:28 -0800 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.33 #1) id 16XJl5-0004jx-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 02:20:27 -0800 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g13AKPc26290 for ; Sun, 3 Feb 2002 11:20:25 +0100 (MET) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g13AKKx26286 for ; Sun, 3 Feb 2002 11:20:24 +0100 (MET) Message-ID: <3C5D0EB7.1CDD43E8@trab.se> Date: Sun, 03 Feb 2002 11:19:35 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IDNA talks about "domain name slots". There are "internationalised domain name slots", probably meaning a domain name slot that uses the native character set of the context the slot is in, though IDNA is having all non-ASCII domain names being in ACE. And there is a "generic domain name slot", which should really be called "ASCII only domain name slot" because it is not generic. Reading more in IDNA you find that it a domain name is to be put in a "ASCII domain name slot" it has to be converted into ASCII. But you will also find a section about entry and display in applications. In it there is talk about different places where domain names can appear, including that non-ASCII character should be used if allowed. The probably first place where non-ASCII domain names will be used is the web. This is also the place where encoding domain names using ACE is not really needed (as it already can work without it). When you look at the web, it is the URL people will use non-ASCII it. They will have them both in the domain name and in the path. Where do the user enter URLs? In the location field to open new pages, and in the HTML code in links. People will NOT enter domain names using ACE. Links in HTML code will contain non-ASCII! As the context of a HTML document have a defined charactert set, URLs embedded in the will be written using the same character set. The text in the IDNA draft may be interpreted as you must use ACE encoded names in URLs inside a HTML-document. Just forget it. It must be possible to use the character set of the context of the HTML document. People will not write ACE! Only automatic software will do that. IDNA will therefore not be really usefull untill the important applications handle conversion to/from ACE automatically totally invisible to the user. The important applications include the web browser, the e-mail software and the operating system software handling host names. Dan From owner-idn@ops.ietf.org Sun Feb 3 09:46: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 JAA25720 for ; Sun, 3 Feb 2002 09:46:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XNmU-000D7I-00 for idn-data@psg.com; Sun, 03 Feb 2002 06:38:10 -0800 Received: from mail.paconline.net ([66.51.160.50]) by psg.com with esmtp (Exim 3.33 #1) id 16XNmU-000D7C-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 06:38:10 -0800 Received: from cs881964a ([24.43.70.205]) by mail.paconline.net (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35) with SMTP id net; Sun, 3 Feb 2002 06:54:03 -0800 Message-ID: <003601c1acc1$ceddea00$cd462b18@mtag.phub.net.cable.rogers.com> From: "ben" To: "Dan Oscarsson" , References: <3C5D0EB7.1CDD43E8@trab.se> Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Date: Sun, 3 Feb 2002 09:48:13 -0500 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 Hi Dan, > The text in the IDNA draft may be interpreted as you must use ACE > encoded > names in URLs inside a HTML-document. Just forget it. It must be > possible > to use the character set of the context of the HTML document. >People will not write ACE! I can not see the problem you are trying to point out and I think a specific example will help me better understand. Can you explain why the following would cause problems?

中文.com

Thanks, Ben From owner-idn@ops.ietf.org Sun Feb 3 10:48: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 KAA26742 for ; Sun, 3 Feb 2002 10:48:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XOhP-000F72-00 for idn-data@psg.com; Sun, 03 Feb 2002 07:36:59 -0800 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.33 #1) id 16XOhO-000F6w-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 07:36:58 -0800 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g13FauJ06889 for ; Sun, 3 Feb 2002 16:36:56 +0100 (MET) 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 g13Fapv06865; Sun, 3 Feb 2002 16:36:51 +0100 (MET) Message-ID: <3C5D58E8.BF303C7F@trab.se> Date: Sun, 03 Feb 2002 16:36:08 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org, ben@cc-www.com Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Ben wrote: >> The text in the IDNA draft may be interpreted as you must use ACE >> encoded >> names in URLs inside a HTML-document. Just forget it. It must be >> possible >> to use the character set of the context of the HTML document. >>People will not write ACE! > >I can not see the problem you are trying to point out and I think a >specific example will help me better understand. Can you explain why >the following would cause problems? > >

color="#FFFFFF">中-?.com

> That will not cause problems except that the person writing the HTML page may not know the ACE form and will write:

中-?.com

and that will not work in browsers that are not IDNA aware as they will not ACE encode the host name before looking it up in the DNS server (though it could work with an enhanced DNS server). What I want to say is that people will not know how to convert a host name into ACE and will use the name in the form most natural for them. And will write the host name into URLs using the native form. So before all major web browsers are fixed, non-ASCII host names will fail on the web unless you use smart DNS servers (like NUBIND and others). Dan From owner-idn@ops.ietf.org Sun Feb 3 11:10: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 LAA27026 for ; Sun, 3 Feb 2002 11:10:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XP8q-000GAl-00 for idn-data@psg.com; Sun, 03 Feb 2002 08:05:20 -0800 Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se) by psg.com with esmtp (Exim 3.33 #1) id 16XP8p-000GAe-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 08:05:19 -0800 Received: from mailc.telia.se (localhost [127.0.0.1]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g13G5Hn11430 for ; Sun, 3 Feb 2002 17:05:17 +0100 (MET) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g13G5GZ11419 for ; Sun, 3 Feb 2002 17:05:16 +0100 (MET) Message-ID: <3C5D5F90.45F43E6A@trab.se> Date: Sun, 03 Feb 2002 17:04:32 +0100 From: Dan Oscarsson X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] IDNA in real life Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Looking at IDNA and how it would enable me to use non-ASCII host names on my system, I see only two useful stages: 1) "do nothing". No change done anywhere in any software. Here I would be able to access other places with non-ASCII in host names using the ACE form. But it will be ugly for host names that can be expressed in my local character set and if somebody get a name in the native non-ASCII form they will not be able to use it, as they do not know how to convert it into ACE (and will see it as absurd that you have to convert it to ACE). It will be impossible to use non-ASCII host names on my own hosts. 2) "do everything". Implement conversion between native local character set and ACE encoded names in the resolver libraries and replace the ones delivered with my systems so that all applications get host names in native form. My DNS server must be upgraded so it can load zone files in native local character set and sendmail will have to be fixed so it can convert host names to ACE before sending. There might be some operating system software that does it own checking on what character are allowed in host names, will have to require them fixed by OS vendor. When that is done, most things should work with non-ASCII host names. I can define hosts with such names, use web pages and send e-mail. There is really no between stage. I cannot do an incremental upgrade. It is unacceptable to require people to enter or see ACE encoded names in the commonly used places. This includes URLs, log files, /etc/hosts, DNS zone files and configuration files. So I cannot get any incremental change over to native host names like the IDNA solution hopes. Instead I will have to wait until I in some way can get all important software to change at the same time. That is why the easiest way to do it is by changing the resolver library instead of changing each application. As IDNA promotes the use of ACE, many vendors with little understanding for the need of non-ASCII characters will just use ACE, I can expect a long wait before applications handle native host names instead of ACE unless you can force it on them by for example changing the resolver library. I have not tried to modify my resolver library so I do not know how many applications it will break. And as the resolver library is delivered with the OS I might have to fix it in the DNS server instead if decide I do not dare trying to replace the resolver library. Clearly, IDNA will not very much help my systems in the move to using non-ASCII in host names. Neither would UTF-8, but as the break with the ASCII world would be much more apparent I would expect applications to be fixed quicker. Dan From owner-idn@ops.ietf.org Sun Feb 3 11:12: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 LAA27089 for ; Sun, 3 Feb 2002 11:12:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XPC6-000GH5-00 for idn-data@psg.com; Sun, 03 Feb 2002 08:08:42 -0800 From: Scott Bradner Message-Id: <200202031600.g13G07n19482@newdev.harvard.edu> To: deng@cnnic.net.cn, Elisabeth.Porteneuve@cetp.ipsl.fr, erin@twnic.net.tw, mclaughlin@pobox.com Subject: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Cc: ajm@icann.org, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@Alvestrand.no, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, htk@eecs.harvard.edu, huangk@alum.sinica.edu, iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn, Marc.Blanchet@viagenie.qc.ca, mkatoh@mkatoh.net, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, snw@twnic.net.tw Sender: owner-idn@ops.ietf.org Precedence: bulk Date: Sun, 03 Feb 2002 08:08:42 -0800 > Assume Chinese name of 10 glyphs. Each one may take 2 versions, > TC or SC. how often are Chinese names written using a mixture of TC & SC? Scott From owner-idn@ops.ietf.org Sun Feb 3 11:14: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 LAA27155 for ; Sun, 3 Feb 2002 11:14:25 -0500 (EST) From: owner-idn@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XPD7-000GMH-00 for idn-data@psg.com; Sun, 03 Feb 2002 08:09:45 -0800 Message-Id: To: idn-data@psg.com Date: Sun, 03 Feb 2002 08:09:45 -0800 Sun, 3 Feb 2002 16:44:54 +0100 (MET) Date: Sun, 3 Feb 2002 16:44:54 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200202031544.QAA24080@balsa.cetp.ipsl.fr> To: deng@cnnic.net.cn, erin@twnic.net.tw, mclaughlin@pobox.com Cc: Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca, ajm@icann.org (Andrew McLaughlin), alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, fred@cisco.com (Fred Baker), harald@alvestrand.no (Harald Alvestrand), hlqian@cnnic.net.cn (Hualin Qian), hoho@iis.sinica.edu.tw (Ho Jan-Ming), htk@eecs.harvard.edu (H. T. Kung), huangk@alum.sinica.edu (Kenny Huang), iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo, jet-member@nic.ad.jp, jseng@pobox.org.sg (James Seng/Personal), klensin@jck.com (John Klensin), lee@whale.cnnic.net.cn (Xiaodong Lee), lynn@icann.org (Stuart Lynn), mao@cnnic.net.cn (Wei Mao), mkatoh@mkatoh.net (Masanobu Katoh), mouhamet@next.sn (Mouhamet Diop), narten@us.ibm.com (Thomas Narten), nordmark@eng.sun.com (Erik Nordmark), paf@cisco.com (Patrik Falstrom), phoffman@imc.org (Paul Hoffman), qhhu@public.bta.net.cn (Qiheng Hu), sharil@cmc.gov.my (Mohamed Sharil Tarmizi), shkyong@kgsm.kaist.ac.kr (Sang-Hyon Kyong), snw@twnic.net.tw (Nai-Wen Hsu), sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw (Li Ming Tseng), vcerf@mci.net (Vint Cerf), whzhang@cnnnic.net.cn (Zhang Wen Hui), wschen@twnic.net.tw (Wen-Sung Chen), wuch@gate.sinica.edu.tw (Chun-Hsin Wu), yktham@umac.mo Subject: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Sender: owner-idn@ops.ietf.org Precedence: bulk Dear Xiang Deng, Thank you very much indeed to insist on the problem, and provide an excellent pedagogical explanation using "a" and "A", and refering to the economy and cost. Latin and Cyrillic scripts have completely different code points in Unicode, while these scripts share many signs which are the same when printed on paper or on screen. No need to add that the upper and lower case of letters are different code points in Latin script and in Cyrillic script. The combinatory effects are terrible, and they are language independent. It is the same everywhere, not only for Chinese code points. Pure maths, the same for everyone. Assume Chinese name of 10 glyphs. Each one may take 2 versions, TC or SC. The number of possible configurations is 2**10 = 1024. It means that to effectively register a name (i.e., get all of the predicable variants pointing to the same place) of 10 glyphs one have to pay 1024 times for such a domain name. Assume now a Latin or Cyrillic name of 10 signs. The same reasoning apply, each character in Unicode have two different versions, one Latin, one Cyrillic. And I forget the upper and lower case, "a" and "A". The number of possible configurations is 2**10 = 1024. It means that to effectively register a name of 10 code points and protect it in Latin and Cyrillic scripts one have to pay 1024 times more than in "LDH". For a label of 5 code points we have 32 times the cost, for 5 - 64, for 7 - 128, etc. It is tremendous cost increase. The company "MacDonald", 9 code points, will have to buy 2**9 variants of its name, 512, pointing to the same place. The company "ICANN", 5 code points, will have to buy 2**5 variants of its name. It reminds me about the inventor of chess game, who requested to be paid in grains, 2 to the power of number of squares, 2 to the power of 64. There was not enough grains on the Earth to pay for it. There is not enough grains now. What will be the effect on world economy ? Is ICANN going to announce to the world that it must multiply its Internet names budget by a factor of hundred or thousand to be able to face IDN coming ? What makes me even more scared is to announce to the world that the printed information with URLs, on paper or screens alike, will become useless. The printed names will be undefined without having script precised for each and every sign. The real chaos. Elisabeth Porteneuve -- > From deng@cnnic.net.cn Sat Feb 2 05:14 MET 2002 > Message-ID: <013101c1ab9f$41ae8270$4407e29f@deng> > From: "xiang deng" > To: , "Erin Chen" > Cc: "Vinton G. Cerf" , "Masanobu Katoh <" , > "John klensin" , "Stuart Lynn" , > "Mohamed Sharil Tarmizi" , > "JET Members" , > "Masanobu Katoh" , > "Mouhamet Diop" , "Patrik F?lstr?m" , > "Qiheng Hu" , > "Sang-Hyon Kyong" , > "Elisabeth Porteneuve" , > "hlqian" , "mao" , > "Zhang Wen Hui" , > "tsenglm@-poo???s.???j.tw" , > "hoho" , > "Kenny Huang" , > "Chun-Hsin Wu" , > "sstseng" , > "Wen-Sung Chen" , "yktham" , > "jasonho" , "alanysho" , > "christine" > Subject: Re: Chinese Domain Name Consortium (CDNC) Declaration > Date: Sat, 2 Feb 2002 12:08:23 +0800 > > > Dear Andrew: > > Let me use my awkward English to do some explanations. > > 1. Identifier and name > From technical argument, IDN Protocol is discussing identifier only, > they are no meaning, no relationship totally, just identifier to > distinguish each other. > > But thing is more complex. These identifiers are not just used in > technical protocol, they are names which users must pay for. > So the identifier is identifier like name. > > 2. Traditional & Simplified Chinese character > In Chinese characters, there is a small subset. In this subset, two > glyphs have same meaning, same connotation,same extension, and > we can substitute one with the other in any situation without changing > anything. (such as: A & a) They have different code point in Unicode, > they are different identifier, they are different domain name. > > 3. Delegation problem and registration-level solution > For example: > registration-level solution: A -> 1.1.1.1 > a -> 2.2.2.2 > Delegation problem: > root > / \ > A a > / \ / \ > A a A a > / \ / \ / \ /\ > A a A a A a A a > If I have a Chinese domain name a.a.a, I will > ask level-one\level-two\level-three to follow the > regulation synchronously, and will config my > mail server, web server or other server 8 times. > > If there is a new network application like ENUM > in future, the level relationship is so important to > this application, how about Chinese domain name? > > 4. about Prohibit > My comprehension about "prohibit" is pending up temporarily. > It's the usual method to deal with unsolved part of a big problem. > > 5. Relationship among CJK > 2001.11.18 CDNC-JET Beijing Meeting had reach consensus > about solve CJK issue. > > I think one principle is: > It's a bi-blade sword, the solution don't be detrimental to each other. > > Personal best regards > Deng xiang > > > ----- Original Message ----- > > From: "Andrew McLaughlin" > > Dear Erin: > > > > Thank you for communicating this CDNC declaration. These are serious > > concerns; we will study them carefully. > > > > In order to improve my understanding, could I please ask for some additional > > information about one point: registration policy. You state that the lack > > of an equivalence-mapping capability for traditional/simplified Chinese > > characters "can't be compensated by registration policy." Could you please > > explain? I am wondering why DNS registries that offer Chinese character > > domain names could not simply ensure that any domain name registration in > > traditional Chinese characters is matched with an equivalent registration in > > simplified Chinese characters (and vice versa). DNS nameserver information > > would be the same for both the traditional and the simplified domain name. > > (I understand that this is not an ideal solution, in that it places twice as > > much DNS configuration by domain name registrants). > > > > It would be very helpful to me and others to understand why a > > registration-level solution is insufficient. > > > > Best regards, > > > > --andrew > > > ------------------------------------------------------------------- > > andrew mclaughlin - vice president & chief policy officer > > internet corporation for assigned names and numbers > > > ------------------------------------------------------------------- > > > > > From owner-idn@ops.ietf.org Sun Feb 3 11:32: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 LAA27372 for ; Sun, 3 Feb 2002 11:32:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XPUD-000H31-00 for idn-data@psg.com; Sun, 03 Feb 2002 08:27:25 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16XPUC-000H2r-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 08:27:24 -0800 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 IAA05062; Sun, 3 Feb 2002 08:26:20 -0800 Message-Id: <5.1.0.14.2.20020203082124.03a52980@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Feb 2002 08:21:55 -0800 To: Dan Oscarsson From: Dave Crocker Subject: Re: [idn] IDNA in real life Cc: idn@ops.ietf.org In-Reply-To: <3C5D5F90.45F43E6A@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 05:04 PM 2/3/2002 +0100, Dan Oscarsson wrote: >Looking at IDNA and how it would enable me to use >non-ASCII host names on my system, I see only two useful stages: Nope. Please review the presentation I gave at a working group meeting: d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Sun Feb 3 11:44: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 LAA27527 for ; Sun, 3 Feb 2002 11:44:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XPfi-000HTO-00 for idn-data@psg.com; Sun, 03 Feb 2002 08:39:18 -0800 Received: from mail.paconline.net ([66.51.160.50]) by psg.com with esmtp (Exim 3.33 #1) id 16XPfh-000HTI-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 08:39:17 -0800 Received: from cs881964a ([24.43.70.205]) by mail.paconline.net (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35) with SMTP id net; Sun, 3 Feb 2002 08:55:16 -0800 Message-ID: <002601c1acd2$bef7b920$cd462b18@mtag.phub.net.cable.rogers.com> From: "ben" To: "Dan Oscarsson" , References: <3C5D58E8.BF303C7F@trab.se> Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Date: Sun, 3 Feb 2002 11:49:27 -0500 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 Hi Dan, > What I want to say is that people will not know how to > convert a host name into ACE and will use the name in the form > most natural for them. And will write the host name into URLs > using the native form. So before all major web browsers are > fixed, non-ASCII host names will fail on the web unless you > use smart DNS servers (like NUBIND and others). > > Dan > I though there were some serious problems. If you are worry that people will not know how to convert to ACE, then please don't worry. Anyways, thanks for the clarification. Thanks, Ben From owner-idn@ops.ietf.org Sun Feb 3 12:01: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 MAA27689 for ; Sun, 3 Feb 2002 12:01:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XPwS-000I9C-00 for idn-data@psg.com; Sun, 03 Feb 2002 08:56:36 -0800 Received: from spider.nic-se.se ([212.247.3.67]) by psg.com with esmtp (Exim 3.33 #1) id 16XPwQ-000I8y-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 08:56:34 -0800 Received: from localhost (dufberg@localhost) by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g13GtDM09812; Sun, 3 Feb 2002 17:55:13 +0100 (CET) X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs Date: Sun, 3 Feb 2002 17:55:13 +0100 (CET) From: Mats Dufberg To: Dan Oscarsson cc: Subject: Re: [idn] IDNA in real life In-Reply-To: <3C5D5F90.45F43E6A@trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Feb 3, 2002, 17:04 (+0100) Dan Oscarsson wrote: > There is really no between stage. I cannot do an incremental upgrade. > It is unacceptable to require people to enter or see ACE encoded names > in the commonly used places. This includes URLs, log files, /etc/hosts, > DNS zone files and configuration files. That is your assumption. In the beginning system administrators will accept to enter domain namnes in ACE in configuration files of web servers, namn servers, mail servers etc. Soon there will be interfaces that let people enter DNS data in local character set in source zone files, which will be converted to zone files in the generic format of bind. And the same will happen to other servers, or servers will be updated. > As IDNA promotes the use of ACE, many vendors with little understanding > for the need of non-ASCII characters will just use ACE, I can expect > a long wait before applications handle native host names instead of ACE > unless you can force it on them by for example changing the resolver > library. I don't think that your assumption will come true. Next version of Windows NT (whatever it is called) will have a nameserver with support of the local character set. > Neither would UTF-8, but as the break > with the ASCII world would be much more apparent I would expect > applications to be fixed quicker. I prefer ugly ACE domain names rather than total break down. :-) Mats ---------------------------------------------------------------------- Mats Dufberg ---------------------------------------------------------------------- From owner-idn@ops.ietf.org Sun Feb 3 13:36: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 NAA28570 for ; Sun, 3 Feb 2002 13:36:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XRPV-000LkP-00 for idn-data@psg.com; Sun, 03 Feb 2002 10:30:41 -0800 From: "James Seng/Personal" To: Subject: [idn] a few notes Date: Mon, 4 Feb 2002 02:29:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; Message-Id: 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.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk For those who been recieving "corrupted" emails with a long list of headers, please accept my apologises. For the record, this is what happened: When a mail send to idn@ops.ietf.org, beside checking for valid poster (either subscribed to the mailing list or in the exceptional list), it also check for two other things, namely, a. likely subscription command (e.g. subscribe, unsubscribe etc) and b. very long header. In the thread titled "Chinese Domain Name Consortium (CDNC) Declaration", there is a long list of To & Cc list, so it bounced to me as "header too long" error. In this case, it will be send to me for approval and I have to manually bounce it to the list. And during the bouncing process, while I tried to be careful to retain the headers and making sure it is RFC822 compilence, it is *very* long and sometimes I missed. This cause some headers to leak into the body. Moral of the story: Please dont send email to the list with lots of To & Cc: or very long headers. Thank you for your co-operation. -James Seng From owner-idn@ops.ietf.org Sun Feb 3 19:58: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 TAA01648 for ; Sun, 3 Feb 2002 19:58:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XXD5-000AjC-00 for idn-data@psg.com; Sun, 03 Feb 2002 16:42:15 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.33 #1) id 16XXD4-000Aj6-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 16:42:14 -0800 Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian)) id 16XXD3-0007v2-00 for ; Sun, 03 Feb 2002 16:42:13 -0800 Date: Mon, 4 Feb 2002 00:42:13 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt Message-ID: <20020204004213.GB29133@nicemice.net> Reply-To: IETF idn working group References: <3C5D5F90.45F43E6A@trab.se> <3C5D58E8.BF303C7F@trab.se> <3C5D0EB7.1CDD43E8@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C5D5F90.45F43E6A@trab.se> <3C5D58E8.BF303C7F@trab.se> <3C5D0EB7.1CDD43E8@trab.se> User-Agent: Mutt/1.3.25i Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dan Oscarsson wrote: > There are "internationalised domain name slots", probably meaning a > domain name slot that uses the native character set of the context the > slot is in, The meaning is stated in the draft. An internationalized slot is one explicitly designated for carrying an IDN, regardless of how it is represented. > though IDNA is having all non-ASCII domain names being in ACE. All non-ASCII names in generic slots are in ACE. Non-ASCII names in internationalized slots need not be in ACE. > And there is a "generic domain name slot", which should really be > called "ASCII only domain name slot" because it is not generic. It is generic in the sense that it is for "domain names", not specifically for "internationalized domain names", and therefore you don't know what might happen if you put non-ASCII code points into it. That's why IDNA allows only ASCII code points in generic domain name slots. > Reading more in IDNA you find that it a domain name is to be put in a > "ASCII domain name slot" it has to be converted into ASCII. But you > will also find a section about entry and display in applications. In > it there is talk about different places where domain names can appear, > including that non-ASCII character should be used if allowed. Yes. There is no contradiction. "Slots" are things communicated between machines/software, like fields of protocol messages, function arguments, etc. Text widgets in user interfaces don't really count as "slots". But even if you wanted to view them as slots, an internationalized application would of course consider them to be internationalized slots, so the requirement to use only ASCII would still not apply there. > Where do the user enter URLs? In the location field to open new > pages, and in the HTML code in links. The location field is not a problem. An internationalized application will use whatever representation it likes in the location field, and convert to/from ACE as neede. > Links in HTML code will contain non-ASCII! As the context of a HTML > document have a defined charactert set, URLs embedded in the will be > written using the same character set. The HTML spec requires the href attribute to contain a URI as specified by RFC 2396, which requires the host part to contain only LDH characters. Under the current rules, ACE is the only way of using IDNs in an href attribute. It's possible that a new version of HTML will allow non-ASCII characters in the host part of the URI in an href attribute. If that happens, then you will have an easier way of typing your HTML source, and the href attribute will no longer be a generic domain name slot, but will in fact be an internationalized domain name slot, and thus the new HTML will not be in any conflict with IDNA. > the person writing the HTML page may not know the ACE form and will > write: >

color="#FFFFFF">中-?.com

> > and that will not work in browsers that are not IDNA aware It violates the HTML spec, so there's no reason to expect it to work in any browsers, regardless of whether they are IDNA aware. > sendmail will have to be fixed so it can convert host names to ACE > before sending. It was never our vision that sendmail should be altered in any way. The user program (Mutt, Pine, etc.) is what we expect to be altered. Upgrading just a few applications (a web browser, a mail client, and maybe an instant messaging client) will go a long way for most users. You don't even have to touch the resolver (though by messing with it you might be able to trick some old applications into partially working with IDNs). AMC From owner-idn@ops.ietf.org Sun Feb 3 21:04: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 VAA02183 for ; Sun, 3 Feb 2002 21:04:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XYOa-000DqC-00 for idn-data@psg.com; Sun, 03 Feb 2002 17:58:12 -0800 Received: from smtp11.singnet.com.sg ([165.21.6.31]) by psg.com with esmtp (Exim 3.33 #1) id 16XYOY-000Dq5-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 17:58:11 -0800 Received: from jamessonyvaio (bb-165-21-154-75.singnet.com.sg [165.21.154.75]) by smtp11.singnet.com.sg (8.12.2/8.12.2) with SMTP id g141w0we023906 for ; Mon, 4 Feb 2002 09:58:00 +0800 (SGT) Message-ID: <000d01c1ad1f$75afc710$0d01000a@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] Fw: BOUNCE idn@ops.ietf.org: Non-member submission from ["tsenglm" ] Date: Mon, 4 Feb 2002 09:58:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Approvws; root From: "tsenglm" To: "\"IETF IDN WG\"" Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration (correction) Date: Mon, 4 Feb 2002 09:07:40 +0800 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 Dear John: I read your note, we know it is SLT not the next meeting in Minneapolis. Actually, we have similar concepts about multi-layer architecture and external servers, but the client solution of some company that using the techniques of client domain name replacement and appending have been introduced the infringement of ML-TLD query. Now, the ASCII-IDN domain are protected by case folding of nameprep mapping and by the separation of basic codepoint part of Punycode encoding, but most ML domain is not . The ambiguity of TC/SC cause it more serious and more unpredictable to a user. The consideration of similar client solution to reduce these ambiguity can not be avoid . Until now , there are little design consideration of IDNA to protect ML-domain-name except the Kana in normalization . For other language characters, there are no explicit way to let local language related domain-name can be combined in this IDNA approach to reduce the ambiguity. That is why many engineers of CNNIC/TWNIC still to find the client solution to reduce the ambiguity of TC/SC and to avoid infringement from download module. The RFC of IDN should be point out explicitly what mapping MUST BE and what MUST NOT BE. To introduce more characters into DNS is not the correct reasons if the stability and trusty will be lost. L.M.Tseng > > My apologies to everyone on this distribution whom I may have > confused... > > I have been thinking about the upcoming IETF meeting in > Minneapolis, and my note mentioned discussions in Minneapolis > when I intended to say "Salt Lake City". I don't know if this > implies that I have lost track of where or when I am, but my > apologies in any event. > > john > From owner-idn@ops.ietf.org Sun Feb 3 21:09: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 VAA02222 for ; Sun, 3 Feb 2002 21:09:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XYSU-000E1U-00 for idn-data@psg.com; Sun, 03 Feb 2002 18:02:14 -0800 Received: from smtp14.singnet.com.sg ([165.21.6.34]) by psg.com with esmtp (Exim 3.33 #1) id 16XYST-000E1N-00 for idn@ops.ietf.org; Sun, 03 Feb 2002 18:02:13 -0800 Received: from jamessonyvaio (bb-165-21-154-75.singnet.com.sg [165.21.154.75]) by smtp14.singnet.com.sg (8.12.2/8.12.2) with SMTP id g1422CHQ002623 for ; Mon, 4 Feb 2002 10:02:12 +0800 Message-ID: <004501c1ad20$07132b20$0d01000a@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] last call reminder Date: Mon, 4 Feb 2002 10:02:41 +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 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: 7bit This is a reminder that the working group last call for 1. Internationalizing Domain Names in Applications (IDNA) http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt 2. Stringprep Profile for Internationalized Host Names http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-07.txt 3. Punycode version 0.3.3 http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt 4. Preparation of Internationalized Strings ("stringprep") http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt will end on Feb 11th 2002, 23h59m GMT-5. -James Seng From owner-idn@ops.ietf.org Sun Feb 3 21:46: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 VAA03455 for ; Sun, 3 Feb 2002 21:46:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XZ4U-000Fi2-00 for idn-data@psg.com; Sun, 03 Feb 2002 18:41:30 -0800 From: "Steven M. Bellovin" To: Elisabeth Porteneuve Cc: Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Mime-Version: 1.0 Content-Type: text/plain Date: Sun, 03 Feb 2002 21:35:29 -0500 Message-Id: <20020204023529.79C5B7B4B@berkshire.research.att.com> Sender: owner-idn@ops.ietf.org Precedence: bulk There'a a good discussion of the security risks of the code point problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140 From owner-idn@ops.ietf.org Mon Feb 4 05:57: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 FAA18275 for ; Mon, 4 Feb 2002 05:57:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XgWm-000A7R-00 for idn-data@psg.com; Mon, 04 Feb 2002 02:39:12 -0800 Received: from twnic.net.tw ([211.72.210.250]) by psg.com with esmtp (Exim 3.33 #1) id 16XgWl-000A5o-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 02:39:11 -0800 Received: from twnic.net.tw (pc160.twnic.net.tw [211.72.211.160]) by twnic.net.tw (8.9.3/8.9.3) with ESMTP id SAA01766; Mon, 4 Feb 2002 18:36:18 +0800 Message-ID: <3C5E6549.50309@twnic.net.tw> Date: Mon, 04 Feb 2002 18:41:13 +0800 From: Erin Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Scott Bradner CC: deng@cnnic.net.cn, Elisabeth.Porteneuve@cetp.ipsl.fr, mclaughlin@pobox.com, ajm@icann.org, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@Alvestrand.no, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, htk@eecs.harvard.edu, huangk@alum.sinica.edu, iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn, Marc.Blanchet@viagenie.qc.ca, mkatoh@mkatoh.net, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, snw@twnic.net.tw Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration References: <200202031600.g13G07n19482@newdev.harvard.edu> Content-Type: multipart/alternative; boundary="------------060106030900010906080201" Sender: owner-idn@ops.ietf.org Precedence: bulk --------------060106030900010906080201 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Dear Scott, Before I describe how often are Chinese Names written using a mixture of TC & SC, I explainhow theuser behavior and the current Input Method Environment ofapplicaiton which user would face to. 1. In the user behavior of writtenChinese in ones daily life,it is VERY often of using mixture of TC & SC. I say VERY often here because it is the userwritten custom. It is difficult to have a statistics to describe how often. 2.In the current Input Method Environment ofapplicaiton, user would face to a IME of could type mixture TC & SC very easily. And because of the custom of using mixture TC & SC, the boundary of TC & SC is becoming indistinct. It is also difficult to distinguish them by user. Although it is difficult to give a general statics. But I can offer some staticsof TWNIC idn.tw testbed. In our testbed there are registerd 27,665 idn.tw Chinese domain namenow. In TWNIC idn.tw testbed, we have make a experiment on a TC & SC set (U+81FA, U+53F0). May be our experimental statics can used as explain how often. In the experiment we allow registrants to choose one of the (U+81FA, U+53F0) if they need in their Chinese domain name. In our statics, there are2,311 Chinese domain namechoose TC U+81FA and 3,938 choose SC U+53F0 In A Complete Set of Simplified Chinese Characters, there are well defined more then 2,000 set of TC & SC which are frequently used in Chinese daily live. Erin Chen Scott Bradner wrote: >>Assume Chinese name of 10 glyphs. Each one may take 2 versions, >>TC or SC. >> > >how often are Chinese names written using a mixture of TC & SC? > > >Scott > > > --------------060106030900010906080201 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: 7bit Dear Scott, 
Before I describe how often are Chinese Names written using a mixture of 
TC & SC, I explain how the user behavior and the current Input Method
Environment of applicaiton which user would face to.

1. In the user behavior of written Chinese in ones daily life, it is 
   VERY often of using mixture of TC & SC. I say VERY often here
   because it is the user written custom. It is difficult to have a 
   statistics to describe how often.
2. In the current Input Method Environment of applicaiton, user would
   face to a IME of could type mixture TC & SC very easily. And because
   of the custom of using mixture TC & SC, the boundary of TC & SC is 
   becoming indistinct. It is also difficult to distinguish them by user.

Although it is difficult to give a general statics. But I can offer some
statics of TWNIC idn.tw testbed. In our testbed there are regist
erd 
27,665 idn.tw Chinese domain name now. 

In TWNIC idn.tw testbed, we have make a experiment on a TC & SC set
(U+81FA, U+53F0). May be our experimental statics can used as explain
how often. In the experiment we allow registrants to choose one of the
(U+81FA, U+53F0) if they need in their Chinese domain name. In our 
statics, there are 2,311 Chinese domain name choose TC U+81FA and 
3,938 choose SC U+53F0

In A Complete Set of Simplified Chinese Characters, there are well 
defined more then 2,000 set of TC & SC which are frequently used in 
Chinese daily live. 

Erin Chen
Scott Bradner wrote:
Assume Chinese name of 10 glyphs. Each one may take 2 versions,
TC or SC.

how often are Chinese names written using a mixture of TC & SC?


Scott




--------------060106030900010906080201-- From owner-idn@ops.ietf.org Mon Feb 4 07:08: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 HAA19434 for ; Mon, 4 Feb 2002 07:08:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XhoT-000Dav-00 for idn-data@psg.com; Mon, 04 Feb 2002 04:01:33 -0800 Received: from heron.verisign.com ([216.168.233.95]) by psg.com with esmtp (Exim 3.33 #1) id 16XhoS-000Dal-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 04:01:32 -0800 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 HAA27180 for ; Mon, 4 Feb 2002 07:01:31 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 07:01:15 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B62E@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: idn@ops.ietf.org Subject: RE: [idn] last call reminder Date: Mon, 4 Feb 2002 07:01:12 -0500 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 James, A suggestion: when the last call has been completed, will you and Marc consider summarizing the comments received during the last call and (more importantly) the actions that will be taken (if any) to address the comments before the documents are forwarded to the IESG? -Scott- From owner-idn@ops.ietf.org Mon Feb 4 07:56: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 HAA20786 for ; Mon, 4 Feb 2002 07:56:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XiYv-000FfT-00 for idn-data@psg.com; Mon, 04 Feb 2002 04:49:33 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.33 #1) id 16XiYt-000FfN-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 04:49:31 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 2D2F5FFC15; Mon, 4 Feb 2002 20:48:39 +0800 (SGT) Message-ID: <03e601c1ad7a$5dd2b570$0d01000a@jamessonyvaio> From: "James Seng/Personal" To: "Erin Chen" , "Scott Bradner" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <200202031600.g13G07n19482@newdev.harvard.edu> <3C5E6549.50309@twnic.net.tw> Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Date: Mon, 4 Feb 2002 20:49:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have tried to be silent all these while but I feel it is time for me to speak up. Note that what I said is in my own capacity, and does not represent the IDN WG, Marc (my co-chair), my company or whatever. It is solely, and primarly my own opinion. The problem of Traditional Chinese & Simplified Chinese cannot be expressed as a bicameral (upper/lower case) problem. To say it is similar to "A" and "a" is at best misleading. TC/SC is not a simple 1 to 1 mapping. Neither can it be compared to other problems in some other languages. Every language is unique, each of them face with problems that its unique only to itself, as demostrated in some of the mails in this thread. So lets please do away with any anology. The complexity of TC/SC is not something can be explained in a single word, but it is described quite well in the following articles: http://playground.i-dns.net/one/onec_sum.htm http://www.cjk.org/cjk/c2c/c2cbasis.htm. In particular, pay attention to the second article and on the section of "code-point substitution". Quote: "The easiest, but most unreliable, way to convert SC to TC, or vice versa, is to do so on a codepoint-to-codepoint basis". Some subset of TC/SC problem can be solved using using this method, however unreliable it is. But such solution have to take into consideration of conflicting languages (such as Japanese & Korean) and thus striping it down to a even smaller subset. In a JET meeting whereby we do this investigation, this would bring the simple 2400+ TC/SC pairs, down to around 300+ TC/SC pairs. (And note, (U+81FA, U+53F0) pairs, an commonly used characters since it represent "tai" in "taiwan" is not part of the sub-subset). One would therefore question the usefulness of such partial solution. There have been many attempts to solve the "TC/SC problems", and in fact, some draft have been admitted to the group. Unfortunately, none of them have managed to stand up to the scuruity of the working group. In addition, the Unicode Technical Consortium have send the following recommendation to the working group on TC/SC http://www.imc.org/idn/mail-archive/msg04005.html Nevertheless, the "Chinese language" problem is one which we cannot deny, altho it may not be as serious as others is painting it. But all problems are serious, the degree of seriousness depends on the individual perspective. But the fact we talk about "language" is a wrong start. Human language is complex. There are very few language rules that can be encapsulated within computer software accurately. And we have to ask ourselves if the expection that DNS is able to do so is fair. This is why the group have steer away from "How do I put a Chinese words into the domain name" problem and work on "How do I put a Han Ideograph into the domain name". In short, we deal with scripts, and not languages. This is not to say we close our eyes and ears away from the "language" problem. Once again, lets me remind everyone that every language have its own problems so it is not just Chinese. Instead, we need a more complex naming system, one that John have already explained in his mail, for *all* language problems: http://www.imc.org/idn/mail-archive/msg05615.html It is always easier to point out problems then to provide solution. This is why the world have more movies critics then movies directors :-) However, the world value solutions more than we value problems. And when there is only one obvious solution, it does not mean the obvious solution is the right one. As Dave points out, "When all you have is a hammer, everything look like a nail". The IDN WG is not absolute. It is a beginning of a journey to do I18N in IETF and the Internet, one that can bring the Internet closer to the world; OR it can be a end to any further attempts to do I18N in IETF. Neither is it the only forum whereby all solutions to I18N is to be conducted. Not all solutions are technical in nature, and even if it is, not all problems can be solve within IETF. ps: It is not my intention to be argumentive so this will be my first and only mail on this thread. -James Seng ----- Original Message ----- From: Erin Chen To: Scott Bradner Cc: deng@cnnic.net.cn ; Elisabeth.Porteneuve@cetp.ipsl.fr ; mclaughlin@pobox.com ; ajm@icann.org ; alanysho@hkdnr.net.hk ; christine.tsang@hkdnr.net.hk ; fred@cisco.com ; harald@Alvestrand.no ; hlqian@cnnic.net.cn ; hoho@iis.sinica.edu.tw ; htk@eecs.harvard.edu ; huangk@alum.sinica.edu ; iab@isi.edu ; idn@ops.ietf.org ; iesg@ietf.org ; jasonho@umac.mo ; jet-member@nic.ad.jp ; jseng@pobox.org.sg ; klensin@jck.com ; lee@whale.cnnic.net.cn ; lynn@icann.org ; mao@cnnic.net.cn ; Marc.Blanchet@viagenie.qc.ca ; mkatoh@mkatoh.net ; mouhamet@next.sn ; narten@us.ibm.com ; nordmark@eng.sun.com ; paf@cisco.com ; phoffman@imc.org ; qhhu@public.bta.net.cn ; sharil@cmc.gov.my ; shkyong@kgsm.kaist.ac.kr ; snw@twnic.net.tw Sent: Monday, February 04, 2002 6:41 PM Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Dear Scott, Before I describe how often are Chinese Names written using a mixture of TC & SC, I explain how the user behavior and the current Input MethodEnvironment of applicaiton which user would face to.1. In the user behavior of written Chinese in ones daily life, it is VERY often of using mixture of TC & SC. I say VERY often here because it is the user written custom. It is difficult to have a statistics to describe how often.2. In the current Input Method Environment of applicaiton, user would face to a IME of could type mixture TC & SC very easily. And because of the custom of using mixture TC & SC, the boundary of TC & SC is becoming indistinct. It is also difficult to distinguish them by user.Although it is difficult to give a general statics. But I can offer somestatics of TWNIC idn.tw testbed. In our testbed there are regist erd 27,665 idn.tw Chinese domain name now. In TWNIC idn.tw testbed, we have make a experiment on a TC & SC set(U+81FA, U+53F0). May be our experimental statics can used as explainhow often. In the experiment we allow registrants to choose one of the(U+81FA, U+53F0) if they need in their Chinese domain name. In our statics, there are 2,311 Chinese domain name choose TC U+81FA and 3,938 choose SC U+53F0In A Complete Set of Simplified Chinese Characters, there are well defined more then 2,000 set of TC & SC which are frequently used in Chinese daily live. Erin Chen Scott Bradner wrote: Assume Chinese name of 10 glyphs. Each one may take 2 versions,TC or SC. how often are Chinese names written using a mixture of TC & SC?Scott From owner-idn@ops.ietf.org Mon Feb 4 08:05: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 IAA21028 for ; Mon, 4 Feb 2002 08:05:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xihk-000G3n-00 for idn-data@psg.com; Mon, 04 Feb 2002 04:58:40 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.33 #1) id 16Xihj-000G3b-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 04:58:39 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 4DAA5FFC2D for ; Mon, 4 Feb 2002 20:57:53 +0800 (SGT) Message-ID: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] Fw: Cyrillics - Latin Date: Mon, 4 Feb 2002 20:58:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" 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.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit fyi ----- Original Message ----- From: "Sergey Charikov" To: ; Sent: Monday, February 04, 2002 4:34 PM Subject: Cyrillics - Latin > Do believe there's absolutely no any confusion of Latin vs Cyrillics for > Russian community. > > We can see many familiar words in another language characters combinations, > especially if there are similar drawing characters. > > The matter is when Russians see COBET (printed) they see "Soviet" and no > more > And they print on a business card - COBET for website with cyrillics content > (for russian and cyrillics markets) > but they take SOVIET usually for webpages on english. > We should understand the cyrillics domains required for cyrillics folks > only. > > A PY (Paraguay) case is a funny thing only. This says about rushing to use > the native language even in such a way. > > Best Regards, > Serguei Charikov > Chair of Russian Language WG of MINC > www.minc.org/WG/russian > > > > > If I may add a note on Latin-Cyrillic confusion. Quoted > > from an explanation I have been providing to another group. > > > > An aside note - I learnt from Russian colleagues that some > > Russian favor to register domain names under .PY (ccTLD for Paraguay) > > rather that .RU (ccTLD for Russia). The reason is that "PY" > > is the beginning of the word "Russia" in Cyrillic - PYCCU[R]. > > The last caracter is Cyrillic "ya", see below, any other is identical > > printing in Latin and Cyrillic, different code points in Unicode, > > identical code point in "LDH". > > > > Best regards, > > Elisabeth Porteneuve > > -- > > > > Let have a glimpse on both end-user and intellectual property > > perspectives with an example. > > > > The word "COBET" reads as it is if one assumes it is Latin > > alphabet, but spells "soviet" if one assumes it is Cyrillic. > > The Unicode code point representation for Cyrillic "C", 0x0421, > > is different from code point representation for Latin "C", 0x0043, > > but they are identical on a printed paper, business cards > > or a screen. Taking into account the above, a usage of Unicode > > code points subsequently makes it impossible to communicate > > with anybody without knowing which language is _printed_, or, > > even worst, which letter or sign is printed in which language. > > > > In the famous TOYS[R]US the R in brackets is a Cyrillic > > code point 0x042f spelled "ya", which also happen to be the > > letter R seen as in mirror, spelled "are". With the exception > > of that letter [R], any other one in TOYS[R]US may be read > > either as Latin or as Cyrillic code point, different spellings, > > different code points, identical printing on paper or screen. > > In an example of a word of 6 code points, with the same > > printing but 2 different contents there is 2**6 = 64 possible > > combinations It is the number of times a 6 letters word > > should be registered to preserve its whole intellectual > > property rights in 2 alphabets, Latin and Cyrillic. > > It is also the maximal number of tries an end-user should > > made to get to a website, if she or he got only a printed > > information. > > I have no competencies to expand this example to other > > alphabets or code points. Hovever, as far as I understand, > > the problem of Chinese code points have some similarity. > > > > -- > > > > > > > From owner-idn@ops.ietf.org Mon Feb 4 08:46: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 IAA21986 for ; Mon, 4 Feb 2002 08:46:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XjIq-000HmK-00 for idn-data@psg.com; Mon, 04 Feb 2002 05:37:00 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.33 #1) id 16XjIo-000HmE-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 05:36:59 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.22 #1) id 16XjHO-000Dul-00; Mon, 04 Feb 2002 13:35:30 +0000 Date: Mon, 04 Feb 2002 08:35:28 -0500 From: John C Klensin To: Erin Chen , Scott Bradner cc: deng@cnnic.net.cn, Elisabeth.Porteneuve@cetp.ipsl.fr, mclaughlin@pobox.com, ajm@icann.org, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@Alvestrand.no, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, htk@eecs.harvard.edu, huangk@alum.sinica.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo, jet-member@nic.ad.jp, jseng@pobox.org.sg, lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn, Marc.Blanchet@viagenie.qc.ca, mkatoh@mkatoh.net, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, snw@twnic.net.tw Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Message-ID: <74382161.1012811728@localhost> In-Reply-To: <3C5E6549.50309@twnic.net.tw> References: <3C5E6549.50309@twnic.net.tw> X-Mailer: Mulberry/2.1.2 (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 Scott (and others), Let me see if I can make an analogy that explains the way I understand this problem. Erin (and others), If I have this wrong, please correct me --I still have a great deal to learn. If I do not, please think about the examples and cases given, as they may help to explain why many of the users of alphabetic languages have been reluctant to put TC<->SC mapping into nameprep or some other IDNA step. --------- As you know, there have been several attempts to "reform" English spelling in the last couple of centuries. The intent has been to remove the silent characters, reduce idiosyncracies due to the different language of origin of different words, to get the spellings into a purely phonetic form or some combination of them. Few of these have gone anywhere, but suppose that a system that rationalized only the thousand most frequently used words had been adopted in the US and was in moderately wide use, and that the change had been made within the lifetime of many, or most, of English-users in the US. Now, what we would end up with is an odd set of combinations. Many words within that thousand would not be changed (how could you simplify "a" or "is" ?). Others would exist in post-change form in ordinary writing, but in pre-change form in, e.g., names and trademarks of companies that had existed and been in wide use pre-change (e.g., I can't imagine a well-know breakfast food firm being happy trying to change all of its corporate and advertising materials to "Kelogz") and in older texts. The change would be slower, or would not be adopted at all, in other English-speaking countries, with enclaves of English speakers in non-English-speaking countries making the change most slowly of all. But all users of English would need to get used to seeing, or puzzling out, the variants or they would discover that their ability to read the language --as written-- would deteriorate over time. Would these things get mixed? Of course they would: To use an example I have used before in different form, consider the well-known firm toz-(Cyrillic Ya)-us and its likely insistence that, somehow, toys-r-us toys-(Cyrillic Ya)-us toz-r-us and maybe even toysrus and that set of four additional variations. Now, that is a case in which there are _only_ two words that have variations and only two cases for each word. But suppose, as would be reasonable once one started down this slippery slope, one also expected British and American spellings to match: after all, the American spellings are just simplifications from an earlier time. And assume that many names were more complex compounds than just having three components. So now there are three variations for many words (raising the multiplier for multiple-word phrases) and phrases with more words (creating a larger multiplier). And all of that assumes that the company doesn't get it into its head to want toys.r.us and its variants, and that a "toz" TLD isn't created in which they would, presumably, want to be "us.r.toz". This is a different case, in that no one would expect (I hope) "us.r.toz" to match "toys-(Cyrillic Ya)-us", but consider the implications to the administrative hierarchy. And, of course, the new spelling system, unless it is much more radical than the examples I have given above, introduces some new homographs and other ambiguities. E.g., does the simplified "toz" match the traditional "toys", or "toes", or maybe even "togs", or the made-up traditional word "toz"? Or perhaps several of them? Does the present tense of "to read" get mapped into "reed" while the past tense gets mapped into "red"? And, if so, what happens to the plant and the color (colour? colur? :-( ). Now, if you treat each "word" or "spelling variation" as if it were a single character, you probably have a first-order approximation to the Chinese situation. And, to a greater or lesser extent, the following statements are all true: (i) Modulo that ASCII case-matching rule, the DNS matches on code points, not on some abstraction of what a "character" is about, so this discussion is irrelevant. (ii) Things that people (end-users, not just computer geeks) see as the same ought to be treated as the same, or we will have vast confusion. (iii) Since, in Chinese, the things we see as "words" in English are really single characters, one ought to be able to do the extended mapping and matching things we now do for "case" in ASCII, and for case and other simplifications that are proposed for Nameprep, for these simplifications/variations also... even if it clearly is not compatible with the DNS to do them for English word-spelling variations. (iv) If we need to do this for Chinese, then "simplifications" that have been introduced through the years in "Latin" alphabets ought to match as well. E.g., "IVLIVS" ought to match "julius" right? Obviously (I hope) these principles are inconsistent. And many people are going to be upset with any decision that is made. In particular, if simplification-matching is not going to be permitted for Chinese, then it is possible that some of the mappings that are now made in Nameprep should be eliminated because they are a bit too close to that (or to (iv) above) to be comfortable. john --On Monday, 04 February, 2002 18:41 +0800 Erin Chen wrote: > Dear Scott, > > Before I describe how often are Chinese Names written using a > mixture of TC & SC, I explainhow theuser behavior and the > current Input Method Environment ofapplicaiton which user > would face to. > > 1. In the user behavior of writtenChinese in ones daily > life,it is VERY often of using mixture of TC & SC. I say >... From owner-idn@ops.ietf.org Mon Feb 4 09:32: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 JAA23432 for ; Mon, 4 Feb 2002 09:32:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xk3U-000Jvb-00 for idn-data@psg.com; Mon, 04 Feb 2002 06:25:12 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.33 #1) id 16Xk3T-000JvV-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 06:25:11 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.22 #1) id 16Xk3Q-000E0F-00; Mon, 04 Feb 2002 14:25:08 +0000 Date: Mon, 04 Feb 2002 09:24:50 -0500 From: John C Klensin To: "James Seng/Personal" cc: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr Subject: Re: [idn] Fw: Cyrillics - Latin Message-ID: <77344214.1012814690@localhost> In-Reply-To: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> X-Mailer: Mulberry/2.1.2 (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 James, Same old problem. Mr. Charikov's note assumes that there is sufficient context to know whether to interpret COBET as Cyrillic or Latin characters. In almost any normal context -- a sentence, a conversation, usually even a business card, that is a reasonable assumption. In the DNS, especially in a generic TLD, where a name or name-reference (e.g., a URI) may exist with no context at all, it is often is not. For the DNS, we have the additional problem that, in many societies, we now have years of experience with Latin-character DNS names/ URLs in web and email addresses on business cards that are otherwise exclusively in other scripts. So the _context_ of ivan@foo.COBET.bar.RU might well cause one to predict a Latin-based interpretation for the ambiguous characters, even if the business card is in Cyrillic. We have been down this line of argument many times. It is a problem. We don't have a solution within the DNS. All of the proposed solutions-by-extended-matching lead to absurdities or to overly-severe constraints about how one of the languages involved is used. The alternatives are (i) to accept the problems, move forward, and hope that the consequences are not as severe as many of us (for different reasons, and with different languages or scripts as the focus for our concerns) fear or (ii) to give it up and conclude that there are no reasonable solutions within the DNS that do not cause unacceptable risks of user confusion and identifier ambiguity. And, James and Marc, you can consider that a comment on the Last Calls. john --On Monday, 04 February, 2002 20:58 +0800 "James Seng/Personal" wrote: > fyi > > ----- Original Message ----- > From: "Sergey Charikov" > To: ; > Sent: Monday, February 04, 2002 4:34 > PM > Subject: Cyrillics - Latin > > >> Do believe there's absolutely no any confusion of Latin vs >> Cyrillics > for >> Russian community. >> >> We can see many familiar words in another language characters > combinations, >> especially if there are similar drawing characters. >> >> The matter is when Russians see COBET (printed) they see >> "Soviet" and > no >> more >> And they print on a business card - COBET for website with >> cyrillics > content >> (for russian and cyrillics markets) >> but they take SOVIET usually for webpages on english. >> We should understand the cyrillics domains required for >> cyrillics > folks >> only. >> >> A PY (Paraguay) case is a funny thing only. This says about >> rushing to > use >> the native language even in such a way. >> >> Best Regards, >> Serguei Charikov >> Chair of Russian Language WG of MINC >> www.minc.org/WG/russian >> >> > >> > If I may add a note on Latin-Cyrillic confusion. Quoted >> > from an explanation I have been providing to another group. >> > >> > An aside note - I learnt from Russian colleagues that some >> > Russian favor to register domain names under .PY (ccTLD for > Paraguay) >> > rather that .RU (ccTLD for Russia). The reason is that "PY" >> > is the beginning of the word "Russia" in Cyrillic - >> > PYCCU[R]. The last caracter is Cyrillic "ya", see below, >> > any other is > identical >> > printing in Latin and Cyrillic, different code points in >> > Unicode, identical code point in "LDH". >> > >> > Best regards, >> > Elisabeth Porteneuve >> > -- >> > >> > Let have a glimpse on both end-user and intellectual >> > property perspectives with an example. >> > >> > The word "COBET" reads as it is if one assumes it is >> > Latin alphabet, but spells "soviet" if one assumes it is >> > Cyrillic. The Unicode code point representation for >> > Cyrillic "C", 0x0421, is different from code point >> > representation for Latin "C", > 0x0043, >> > but they are identical on a printed paper, business cards >> > or a screen. Taking into account the above, a usage of >> > Unicode code points subsequently makes it impossible to >> > communicate with anybody without knowing which language >> > is _printed_, or, even worst, which letter or sign is >> > printed in which language. >> > >> > In the famous TOYS[R]US the R in brackets is a Cyrillic >> > code point 0x042f spelled "ya", which also happen to be >> > the letter R seen as in mirror, spelled "are". With the >> > exception of that letter [R], any other one in TOYS[R]US >> > may be read either as Latin or as Cyrillic code point, >> > different spellings, different code points, identical >> > printing on paper or screen. In an example of a word of >> > 6 code points, with the same printing but 2 different >> > contents there is 2**6 = 64 possible combinations It is >> > the number of times a 6 letters word should be >> > registered to preserve its whole intellectual property >> > rights in 2 alphabets, Latin and Cyrillic. It is also >> > the maximal number of tries an end-user should made to >> > get to a website, if she or he got only a printed >> > information. >> > I have no competencies to expand this example to other >> > alphabets or code points. Hovever, as far as I >> > understand, the problem of Chinese code points have some >> > similarity. >> > >> > -- >> > >> > >> > >> > > > > From owner-idn@ops.ietf.org Mon Feb 4 09:51: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 JAA24125 for ; Mon, 4 Feb 2002 09:51:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XkBO-000KL5-00 for idn-data@psg.com; Mon, 04 Feb 2002 06:33:22 -0800 Received: from heron.verisign.com ([216.168.233.95]) by psg.com with esmtp (Exim 3.33 #1) id 16XkBN-000KKx-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 06:33:21 -0800 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 JAA01954 for ; Mon, 4 Feb 2002 09:33:20 -0500 (EST) Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 09:33:03 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B630@vsvapostal3.bkup6> From: "Hollenbeck, Scott" To: "'idn@ops.ietf.org'" Subject: [idn] Stringprep and UAX15 Date: Mon, 4 Feb 2002 09:32:57 -0500 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 Last Tuesday I sent this to the list: http://www.imc.org/idn/mail-archive/msg05544.html The stringprep draft contains this text at the end of section 4: "A profile MUST refer to a specific version of [UAX15]. If a later version of [UAX15] changes the algorithm used for normalization, that later version MUST NOT be used with the same version of the profile." Followed by this unanswered question: "Patrik asks: Is not addition of unassigned codepoints regarded an update of UAX15? This is relevant here." I've yet to see a response to my original query. Assuming that assigning codepoints that were previously unassigned would require an update to Unicode 3.1.0, and UAX15 very clearly lists the normative Unicode version as 3.1.0, perhaps the answer to Patrik's question is "yes" -- UAX15 would need to be updated (though the normalization algorithm itself might not change), but as described in UAX15 backward compatibility would have to be preserved. Would it make sense to add something like this to the end of section 4 (perhaps prior to the "A profile MUST" sentence) to answer Patrik's question: "The composition process described in [UAX15] requires a fixed composition version of Unicode to ensure that strings normalized under one version of Unicode remain normalized under all future versions of Unicode." If I've missed the mark I'll apologize in advance. No matter what, though, Patrik's question needs to be removed from the draft and either text should be added to answer the question or someone should explain why the question is irrelevant. -Scott- From owner-idn@ops.ietf.org Mon Feb 4 11:02: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 LAA26872 for ; Mon, 4 Feb 2002 11:02:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlLL-000NjA-00 for idn-data@psg.com; Mon, 04 Feb 2002 07:47:43 -0800 Received: from rwcrmhc52.attbi.com ([216.148.227.88]) by psg.com with esmtp (Exim 3.33 #1) id 16XlLK-000Nj4-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 07:47:42 -0800 Received: from c1340594a ([12.234.216.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020204154740.NHRM3578.rwcrmhc52.attbi.com@c1340594a>; Mon, 4 Feb 2002 15:47:40 +0000 Message-ID: <005a01c1ad93$974788d0$08d8ea0c@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Erin Chen" , "Scott Bradner" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <200202031600.g13G07n19482@newdev.harvard.edu> <3C5E6549.50309@twnic.net.tw> Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Date: Mon, 4 Feb 2002 07:49:53 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C1AD50.88450C60" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C1AD50.88450C60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The test data, as you describe it, is completely insufficient to draw any conclusions. The purpose of a test would be to determine whether the combinatorics of mixing TC and SC characters were an real issue, not simply whether people choose a particular SC vs. TC character. To do an accurate survey, you would have to be much more rigorous, doing at least the following: - Divide all CJK characters into three classes: TC-only, SC-only, TC-or-SC. Post this list so that it can be scrutinized by others. - Test all names to see which contain at least one character from TC-only and one from SC-only. Post that list so that it can also be scrutinized by others. - Of those, see how many would match under a TC-SC mapping. Publicize both the mapping and the list so that they can also be scrutinized by others. - See what the percentages are: mixed / total and matching / mixed. Note that the accuracy of the test also depends heavily upon the accuracy of the division of characters in the original three classes, and the accuracy of the TC-SC mapping. Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: Erin Chen To: Scott Bradner Cc: deng@cnnic.net.cn ; Elisabeth.Porteneuve@cetp.ipsl.fr ; mclaughlin@pobox.com ; ajm@icann.org ; alanysho@hkdnr.net.hk ; christine.tsang@hkdnr.net.hk ; fred@cisco.com ; harald@Alvestrand.no ; hlqian@cnnic.net.cn ; hoho@iis.sinica.edu.tw ; htk@eecs.harvard.edu ; huangk@alum.sinica.edu ; iab@isi.edu ; idn@ops.ietf.org ; iesg@ietf.org ; jasonho@umac.mo ; jet-member@nic.ad.jp ; jseng@pobox.org.sg ; klensin@jck.com ; lee@whale.cnnic.net.cn ; lynn@icann.org ; mao@cnnic.net.cn ; Marc.Blanchet@viagenie.qc.ca ; mkatoh@mkatoh.net ; mouhamet@next.sn ; narten@us.ibm.com ; nordmark@eng.sun.com ; paf@cisco.com ; phoffman@imc.org ; qhhu@public.bta.net.cn ; sharil@cmc.gov.my ; shkyong@kgsm.kaist.ac.kr ; snw@twnic.net.tw Sent: Monday, February 04, 2002 02:41 Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Dear Scott, Before I describe how often are Chinese Names written using a mixture of TC & SC, I explain how the user behavior and the current Input MethodEnvironment of applicaiton which user would face to.1. In the user behavior of written Chinese in ones daily life, it is VERY often of using mixture of TC & SC. I say VERY often here because it is the user written custom. It is difficult to have a statistics to describe how often.2. In the current Input Method Environment of applicaiton, user would face to a IME of could type mixture TC & SC very easily. And because of the custom of using mixture TC & SC, the boundary of TC & SC is becoming indistinct. It is also difficult to distinguish them by user.Although it is difficult to give a general statics. But I can offer somestatics of TWNIC idn.tw testbed. In our testbed there are regist erd 27,665 idn.tw Chinese domain name now. In TWNIC idn.tw testbed, we have make a experiment on a TC & SC set(U+81FA, U+53F0). May be our experimental statics can used as explainhow often. In the experiment we allow registrants to choose one of the(U+81FA, U+53F0) if they need in their Chinese domain name. In our statics, there are 2,311 Chinese domain name choose TC U+81FA and 3,938 choose SC U+53F0In A Complete Set of Simplified Chinese Characters, there are well defined more then 2,000 set of TC & SC which are frequently used in Chinese daily live. Erin Chen Scott Bradner wrote: Assume Chinese name of 10 glyphs. Each one may take 2 versions,TC or SC. how often are Chinese names written using a mixture of TC & SC?Scott ------=_NextPart_000_0056_01C1AD50.88450C60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
The test data, as you describe it, is = completely=20 insufficient to draw any conclusions. The purpose of a test would be to=20 determine whether the combinatorics of mixing TC and SC characters were = an real=20 issue, not simply whether people choose a particular SC vs. TC=20 character.
 
To do an accurate survey, you = would have to be=20 much more rigorous, doing at least the following:
 
- Divide all CJK characters into three = classes:=20 TC-only, SC-only, TC-or-SC.
Post this list so that it can be = scrutinized by=20 others.
 
- Test all names to see which contain = at least one=20 character from TC-only and one from SC-only.
Post that list so that it can also be = scrutinized=20 by others.
 
- Of those, see how many would match = under a TC-SC=20 mapping.
Publicize both the mapping and the list = so that=20 they can also be scrutinized by others.
 
- See what the percentages are: mixed / = total and=20 matching / mixed.
 
Note that the accuracy of the test also = depends=20 heavily upon the accuracy of the division of characters in the original = three=20 classes, and the accuracy of the TC-SC mapping.
 
Mark
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
=CE=A0=CF=8C=CE=BB=CE=BB=E2=80=99 = =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =E1=BC=94=CF=81=CE=B3=CE=B1, =CE=BA=CE=B1=CE=BA=E1=BF=B6=CF=82 = =CE=B4=E2=80=99 =E1=BC=A0=CF=80=CE=AF=CF=83=CF=84=CE=B1=CF=84=CE=BF = =CF=80=CE=AC=CE=BD=CF=84=CE=B1 =E2=80=94 = =E1=BD=89=CE=BC=CE=AE=CF=81=CE=BF=CF=85 = =CE=9C=CE=B1=CF=81=CE=B3=CE=AF=CF=84=E1=BF=83
[For=20 transliteration, see http://oss.software.i= bm.com/cgi-bin/icu/tr]
 
----- Original Message -----
From:=20 Erin = Chen=20
Cc: deng@cnnic.net.cn ; Elisabeth.Porteneuve@ce= tp.ipsl.fr=20 ; mclaughlin@pobox.com ; ajm@icann.org = ; alanysho@hkdnr.net.hk ; christine.tsang@hkdnr.net.hk= ;=20 fred@cisco.com ; harald@Alvestrand.no ; hlqian@cnnic.net.cn ; hoho@iis.sinica.edu.tw ; htk@eecs.harvard.edu ; huangk@alum.sinica.edu ; iab@isi.edu ; idn@ops.ietf.org ;=20 iesg@ietf.org ; jasonho@umac.mo ; jet-member@nic.ad.jp ; jseng@pobox.org.sg ; klensin@jck.com ; lee@whale.cnnic.net.cn ; lynn@icann.org ; mao@cnnic.net.cn ;=20 Marc.Blanchet@viagenie.qc.ca= ;=20 mkatoh@mkatoh.net ; mouhamet@next.sn ;=20 narten@us.ibm.com ; nordmark@eng.sun.com ; paf@cisco.com = ; phoffman@imc.org ;=20 qhhu@public.bta.net.cn ; sharil@cmc.gov.my=20 ; shkyong@kgsm.kaist.ac.kr = ; snw@twnic.net.tw=20
Sent: Monday, February 04, 2002 = 02:41
Subject: Re: [idn] Re: Chinese = Domain=20 Name Consortium (CDNC) Declaration

Dear Scott, 
Before I describe how often =
are Chinese Names written using a mixture of 
TC & SC, I =
explain how the user behavior and the current Input =
Method
Environment of applicaiton which user would face =
to.

1. In the user behavior of written Chinese in ones daily =
life, it is 
   VERY often of using mixture of TC & SC. I =
say VERY often here
   because it is the user written custom. It =
is difficult to have a 
   statistics to describe how =
often.
2. In the current Input Method Environment =
of applicaiton, user would
   face to a IME of could type =
mixture TC & SC very easily. And because
   of the custom of =
using mixture TC & SC, the boundary of TC & SC is 
   =
becoming indistinct. It is also difficult to distinguish them by =
user.

Although it is difficult to give a general statics. But I =
can offer some
statics of TWNIC idn.tw testbed. In our testbed =
there are regist
erd 
27,665 idn.tw Chinese domain name now. 

In TWNIC =
idn.tw testbed, we have make a experiment on a TC & SC =
set
(U+81FA, U+53F0). May be our experimental statics can used as =
explain
how often. In the experiment we allow registrants to choose =
one of the
(U+81FA, U+53F0) if they need in their Chinese domain =
name. In our 
statics, there are 2,311 Chinese domain =
name choose TC U+81FA and 
3,938 choose SC U+53F0

In A =
Complete Set of Simplified Chinese Characters, there are well =

defined more then 2,000 set of TC & SC which are frequently used =
in 
Chinese daily live. 

Erin Chen
Scott=20 Bradner wrote:
Assume =
Chinese name of 10 glyphs. Each one may take 2 versions,
TC or =
SC.

how often are =
Chinese names written using a mixture of TC & =
SC?


Scott




<= /BODY> ------=_NextPart_000_0056_01C1AD50.88450C60-- From owner-idn@ops.ietf.org Mon Feb 4 11:11: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 LAA27136 for ; Mon, 4 Feb 2002 11:11:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlRJ-000Nz7-00 for idn-data@psg.com; Mon, 04 Feb 2002 07:53:53 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16XlRI-000Nz0-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 07:53:52 -0800 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 HAA19637; Mon, 4 Feb 2002 07:52:59 -0800 Message-Id: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 07:40:52 -0800 To: "Steven M. Bellovin" From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo In-Reply-To: <20020204023529.79C5B7B4B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Steve, At 09:35 PM 2/3/2002 -0500, Steven M. Bellovin wrote: >There'a a good discussion of the security risks of the code point >problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140 homographic attacks are not new with the IDN effort. for example, MICROS0FT.COM was done. For that matter, choice of different top-level domains permits a degree of homographic attack. Try looking at dnso.com, rather than dnso.org. (No, this approach does not qualify precisely as homographic, but it takes advantage of a small difference from the real name, hoping that users will not notice. And it does work.) Hence, the IDN work does not introduce a new risk. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Feb 4 11:14: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 LAA27233 for ; Mon, 4 Feb 2002 11:14:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlWs-000OJp-00 for idn-data@psg.com; Mon, 04 Feb 2002 07:59:38 -0800 Received: from rwcrmhc54.attbi.com ([216.148.227.87]) by psg.com with esmtp (Exim 3.33 #1) id 16XlWs-000OJj-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 07:59:38 -0800 Received: from c1340594a ([12.234.216.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020204155937.JJKP7443.rwcrmhc54.attbi.com@c1340594a>; Mon, 4 Feb 2002 15:59:37 +0000 Message-ID: <016e01c1ad95$427a53d0$08d8ea0c@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "John C Klensin" , "James Seng/Personal" Cc: , References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <77344214.1012814690@localhost> Subject: Re: [idn] Fw: Cyrillics - Latin Date: Mon, 4 Feb 2002 08:01:51 -0800 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 John that there is no solution in DNS. I would go further in that I don't think a solution is possible in DNS. On the other hand, I think it would be quite useful--as I suggested some time ago--to add some text that strongly recommended that browsers and similar programs that display URLs indicate with some sort of visual mechanism where they contains mixed scripts, e.g. highlight those characters not in the script of the majority of the characters (with a different color or background). Mark ————— Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr] http://www.macchiato.com ----- Original Message ----- From: "John C Klensin" To: "James Seng/Personal" Cc: ; Sent: Monday, February 04, 2002 06:24 Subject: Re: [idn] Fw: Cyrillics - Latin > James, > > Same old problem. Mr. Charikov's note assumes that there is > sufficient context to know whether to interpret COBET as > Cyrillic or Latin characters. In almost any normal context -- a > sentence, a conversation, usually even a business card, that is > a reasonable assumption. In the DNS, especially in a generic > TLD, where a name or name-reference (e.g., a URI) may exist with > no context at all, it is often is not. For the DNS, we have the > additional problem that, in many societies, we now have years of > experience with Latin-character DNS names/ URLs in web and email > addresses on business cards that are otherwise exclusively in > other scripts. So the _context_ of ivan@foo.COBET.bar.RU might > well cause one to predict a Latin-based interpretation for the > ambiguous characters, even if the business card is in Cyrillic. > > We have been down this line of argument many times. It is a > problem. We don't have a solution within the DNS. All of the > proposed solutions-by-extended-matching lead to absurdities or > to overly-severe constraints about how one of the languages > involved is used. The alternatives are > > (i) to accept the problems, move forward, and hope that the > consequences are not as severe as many of us (for different > reasons, and with different languages or scripts as the focus > for our concerns) fear or > > (ii) to give it up and conclude that there are no reasonable > solutions within the DNS that do not cause unacceptable risks of > user confusion and identifier ambiguity. > > And, James and Marc, you can consider that a comment on the Last > Calls. > > john > > > --On Monday, 04 February, 2002 20:58 +0800 "James Seng/Personal" > wrote: > > > fyi > > > > ----- Original Message ----- > > From: "Sergey Charikov" > > To: ; > > Sent: Monday, February 04, 2002 4:34 > > PM > > Subject: Cyrillics - Latin > > > > > >> Do believe there's absolutely no any confusion of Latin vs > >> Cyrillics > > for > >> Russian community. > >> > >> We can see many familiar words in another language characters > > combinations, > >> especially if there are similar drawing characters. > >> > >> The matter is when Russians see COBET (printed) they see > >> "Soviet" and > > no > >> more > >> And they print on a business card - COBET for website with > >> cyrillics > > content > >> (for russian and cyrillics markets) > >> but they take SOVIET usually for webpages on english. > >> We should understand the cyrillics domains required for > >> cyrillics > > folks > >> only. > >> > >> A PY (Paraguay) case is a funny thing only. This says about > >> rushing to > > use > >> the native language even in such a way. > >> > >> Best Regards, > >> Serguei Charikov > >> Chair of Russian Language WG of MINC > >> www.minc.org/WG/russian > >> > >> > > >> > If I may add a note on Latin-Cyrillic confusion. Quoted > >> > from an explanation I have been providing to another group. > >> > > >> > An aside note - I learnt from Russian colleagues that some > >> > Russian favor to register domain names under .PY (ccTLD for > > Paraguay) > >> > rather that .RU (ccTLD for Russia). The reason is that "PY" > >> > is the beginning of the word "Russia" in Cyrillic - > >> > PYCCU[R]. The last caracter is Cyrillic "ya", see below, > >> > any other is > > identical > >> > printing in Latin and Cyrillic, different code points in > >> > Unicode, identical code point in "LDH". > >> > > >> > Best regards, > >> > Elisabeth Porteneuve > >> > -- > >> > > >> > Let have a glimpse on both end-user and intellectual > >> > property perspectives with an example. > >> > > >> > The word "COBET" reads as it is if one assumes it is > >> > Latin alphabet, but spells "soviet" if one assumes it is > >> > Cyrillic. The Unicode code point representation for > >> > Cyrillic "C", 0x0421, is different from code point > >> > representation for Latin "C", > > 0x0043, > >> > but they are identical on a printed paper, business cards > >> > or a screen. Taking into account the above, a usage of > >> > Unicode code points subsequently makes it impossible to > >> > communicate with anybody without knowing which language > >> > is _printed_, or, even worst, which letter or sign is > >> > printed in which language. > >> > > >> > In the famous TOYS[R]US the R in brackets is a Cyrillic > >> > code point 0x042f spelled "ya", which also happen to be > >> > the letter R seen as in mirror, spelled "are". With the > >> > exception of that letter [R], any other one in TOYS[R]US > >> > may be read either as Latin or as Cyrillic code point, > >> > different spellings, different code points, identical > >> > printing on paper or screen. In an example of a word of > >> > 6 code points, with the same printing but 2 different > >> > contents there is 2**6 = 64 possible combinations It is > >> > the number of times a 6 letters word should be > >> > registered to preserve its whole intellectual property > >> > rights in 2 alphabets, Latin and Cyrillic. It is also > >> > the maximal number of tries an end-user should made to > >> > get to a website, if she or he got only a printed > >> > information. > >> > I have no competencies to expand this example to other > >> > alphabets or code points. Hovever, as far as I > >> > understand, the problem of Chinese code points have some > >> > similarity. > >> > > >> > -- > >> > > >> > > >> > > >> > > > > > > > > > > > > From owner-idn@ops.ietf.org Mon Feb 4 11:17: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 LAA27371 for ; Mon, 4 Feb 2002 11:17:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlZw-000ORu-00 for idn-data@psg.com; Mon, 04 Feb 2002 08:02:48 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.33 #1) id 16XlZv-000ORn-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 08:02:47 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.22 #1) id 16XlYi-000EBi-00; Mon, 04 Feb 2002 16:01:32 +0000 Date: Mon, 04 Feb 2002 11:01:15 -0500 From: John C Klensin To: Dave Crocker , "Steven M. Bellovin" cc: Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Message-ID: <83129960.1012820475@localhost> In-Reply-To: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> X-Mailer: Mulberry/2.1.2 (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 Dave, I agree that there is no new risk here. The question is whether or not it is desirable to expand that risk, perhaps into populations that are less sensitive to it because they would, naturally, be more trusting of texts that appear to be written in their own languages (after not having seen those before). And the answer to that question, I believe, must involve weighing the tradeoffs between the value of the expanded name space and the costs of the expanded risk. Believing that question/ tradeoff is easy or obvious, is, I believe, naive, regardless of the conclusion on reaches about the question itself. And I would hope that relevant documents coming out of the WG would explicitly alert people to these risks. john --On Monday, 04 February, 2002 07:40 -0800 Dave Crocker wrote: > Steve, > > At 09:35 PM 2/3/2002 -0500, Steven M. Bellovin wrote: >> There'a a good discussion of the security risks of the code >> point problem at >> http://www.csl.sri.com/users/neumann/insiderisks.html#140 > > homographic attacks are not new with the IDN effort. > > for example, MICROS0FT.COM was done. > > For that matter, choice of different top-level domains permits > a degree of homographic attack. Try looking at dnso.com, > rather than dnso.org. (No, this approach does not qualify > precisely as homographic, but it takes advantage of a small > difference from the real name, hoping that users will not > notice. And it does work.) > > Hence, the IDN work does not introduce a new risk. > > d/ From owner-idn@ops.ietf.org Mon Feb 4 11:24: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 LAA27561 for ; Mon, 4 Feb 2002 11:24:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xlgo-000Onb-00 for idn-data@psg.com; Mon, 04 Feb 2002 08:09:54 -0800 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.33 #1) id 16Xlgn-000OnV-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 08:09:53 -0800 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.22 #1) id 16Xlgl-000ECz-00; Mon, 04 Feb 2002 16:09:51 +0000 Date: Mon, 04 Feb 2002 11:09:34 -0500 From: John C Klensin To: Mark Davis cc: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr Subject: Re: [idn] Fw: Cyrillics - Latin Message-ID: <83629194.1012820974@localhost> In-Reply-To: <016e01c1ad95$427a53d0$08d8ea0c@c1340594a> References: <016e01c1ad95$427a53d0$08d8ea0c@c1340594a> X-Mailer: Mulberry/2.1.2 (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, 04 February, 2002 08:01 -0800 Mark Davis wrote: > I agree with John that there is no solution in DNS. I would go > further in that I don't think a solution is possible in DNS. "Not possible in DNS" is what I meant to say, so I think we agree. > On the other hand, I think it would be quite useful--as I > suggested some time ago--to add some text that strongly > recommended that browsers and similar programs that display > URLs indicate with some sort of visual mechanism where they > contains mixed scripts, e.g. highlight those characters not in > the script of the majority of the characters (with a different > color or background). I believe that it would be a significant service to the community --I would suggest that it is nearly necessary-- to write strong "security considerations" sections for these documents, or separate documents, that explicitly identify the character and range of as many of these problems as are well-understood. I think that incorporating suggestions like Mark's into such explanations would be very helpful. john From owner-idn@ops.ietf.org Mon Feb 4 11:38: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 LAA28164 for ; Mon, 4 Feb 2002 11:38:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlyN-000Ple-00 for idn-data@psg.com; Mon, 04 Feb 2002 08:28:03 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16XlyN-000PlQ-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 08:28:03 -0800 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 IAA21221; Mon, 4 Feb 2002 08:28:02 -0800 Message-Id: <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 08:18:05 -0800 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] Fw: Cyrillics - Latin Cc: Elisabeth.Porteneuve@cetp.ipsl.fr In-Reply-To: <77344214.1012814690@localhost> References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Folks, >a reasonable assumption. In the DNS, especially in a generic >TLD, where a name or name-reference (e.g., a URI) may exist with >no context at all, it is often is not. For the DNS, we have the >additional problem that, in many societies, we now have years of >experience with Latin-character DNS names/ URLs in web and email nova.com Is that a) a latin-related reference to an astronomical activity b) an american reference to a car c) a spanish reference to something that is stationary (or does not work properly) d) something else (I particularly like that the actual site contains a pointer to other uses of the name: .) In other words, we already have opportunities for confusion in domain names. We deal with them adequately. Domain names are character strings, they are not language. All of this debate pertains to very important issues about language usage. It is outside the scope of the working group. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Feb 4 11:44: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 LAA28400 for ; Mon, 4 Feb 2002 11:44:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xlzo-000Ppn-00 for idn-data@psg.com; Mon, 04 Feb 2002 08:29:32 -0800 From: "Steven M. Bellovin" To: Dave Crocker Cc: Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Feb 2002 11:25:27 -0500 Message-Id: <20020204162527.2411B7B4B@berkshire.research.att.com> Sender: owner-idn@ops.ietf.org Precedence: bulk In message <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>, Dave Crocker writes: >Steve, > >At 09:35 PM 2/3/2002 -0500, Steven M. Bellovin wrote: >>There'a a good discussion of the security risks of the code point >>problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140 > >homographic attacks are not new with the IDN effort. > >for example, MICROS0FT.COM was done. > >For that matter, choice of different top-level domains permits a degree >of homographic attack. Try looking at dnso.com, rather than dnso.org. >(No, this approach does not qualify precisely as homographic, but it >takes advantage of a small difference from the real name, hoping that >users will not notice. And it does work.) I know -- see slide 4 of http://www.research.att.com/~smb/talks/www.ps (or .pdf), from 1996. > >Hence, the IDN work does not introduce a new risk. > It amplifies it, however. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-idn@ops.ietf.org Mon Feb 4 11:47: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 LAA28478 for ; Mon, 4 Feb 2002 11:47:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlzW-000Pp9-00 for idn-data@psg.com; Mon, 04 Feb 2002 08:29:14 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16XlzV-000Pp1-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 08:29:13 -0800 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 IAA21208; Mon, 4 Feb 2002 08:27:56 -0800 Message-Id: <5.1.0.14.2.20020204080919.035a5b68@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 08:13:48 -0800 To: John C Klensin From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: "Steven M. Bellovin" , Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo In-Reply-To: <83129960.1012820475@localhost> References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:01 AM 2/4/2002 -0500, John C Klensin wrote: > The question is whether >or not it is desirable to expand that risk, perhaps into >populations that are less sensitive to it because they would, >naturally, be more trusting of texts that appear to be written >in their own languages (after not having seen those before). The questions are really whether a) we are going to expand the scope of the working group beyond what is required to solve the actual requirement of the working group, and b) whether the IETF is now going to claim parental concerns for people's behaviors, protecting them from their deficiencies -- while remembering that we are exceeding poor at that task. >And the answer to that question, I believe, must involve >weighing the tradeoffs between the value of the expanded name >space and the costs of the expanded risk. Claims about the costs are based on behavioral assumptions that have no empirical basis. Existence proofs, yes. Proof of widespread danger, no. >And I would hope that relevant documents coming out of the WG >would explicitly alert people to these risks. Adding language about implications of errors is typically a Good Thing, as long as a) the language is readily produced, and b) there is not so much of it that it gets in the way of the technical specification. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Feb 4 11:48: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 LAA28542 for ; Mon, 4 Feb 2002 11:48:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xm6Q-0000H6-00 for idn-data@psg.com; Mon, 04 Feb 2002 08:36:22 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16Xm6Q-0000Gw-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 08:36:22 -0800 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 IAA21605; Mon, 4 Feb 2002 08:36:19 -0800 Message-Id: <5.1.0.14.2.20020204075953.02aca598@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 08:01:41 -0800 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Cc: "Erin Chen" , "Scott Bradner" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , In-Reply-To: <03e601c1ad7a$5dd2b570$0d01000a@jamessonyvaio> References: <200202031600.g13G07n19482@newdev.harvard.edu> <3C5E6549.50309@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk >There have been many attempts to solve the "TC/SC problems", and in >fact, some draft have been admitted to the group. Unfortunately, none of >them have managed to stand up to the scuruity of the working group. Folks, For the moment, let us ignore the fact that this issue is outside the scope of this working group and let us ignore the scrutiny of the IDN working group. Let us consider the scrutiny of end-users. Which solutions to TC/SC have gained wide acceptance in the rest of the world? That is, please point us to a specification of a solution that has already gained wide acceptance in the global community using TC and SC. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Feb 4 12:31: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 MAA00464 for ; Mon, 4 Feb 2002 12:31:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xmg8-00024J-00 for idn-data@psg.com; Mon, 04 Feb 2002 09:13:16 -0800 Received: from imo-m01.mx.aol.com ([64.12.136.4]) by psg.com with esmtp (Exim 3.33 #1) id 16Xmg7-00024C-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 09:13:15 -0800 Received: from DougEwell2@cs.com by imo-m01.mx.aol.com (mail_out_v31_r1.26.) id i.114.be36228 (4563); Mon, 4 Feb 2002 12:13:06 -0500 (EST) From: DougEwell2@cs.com Message-ID: <114.be36228.29901b22@cs.com> Date: Mon, 4 Feb 2002 12:13:06 EST Subject: Re: [idn] Fw: Cyrillics - Latin To: idn@ops.ietf.org CC: dhc@dcrocker.net, Elisabeth.Porteneuve@cetp.ipsl.fr MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: CompuServe 2000 32-bit sub 113 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 2002-02-04 8:40:29 Pacific Standard Time, dhc@dcrocker.net writes: > Domain names are character strings, they are not language. All of this > debate pertains to very important issues about language usage. It is > outside the scope of the working group. Some time ago I brought up the example of three of my favorite search engines: - google.com - altavista.com - teoma.com I challenged the list to identify -- unambiguously, to the point where it could be determined by software -- the language(s) to which the words "google," "altavista" (or for that matter "alta vista"), and "teoma" belong. Not surprisingly, nobody responded. For that matter, to what language do the words "idn," "ops," and "ietf" belong? Don't tell me they are abbreviations -- I know that. My point is that Dave is 100% correct; domain names are strings of characters. If they happen to spell one or more words in a natural language, so much the better, but that is not primarily what they are. -Doug Ewell Fullerton, California (address will soon change to dewell@adelphia.net) From owner-idn@ops.ietf.org Mon Feb 4 12:31: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 MAA00483 for ; Mon, 4 Feb 2002 12:31:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xmeb-00020h-00 for idn-data@psg.com; Mon, 04 Feb 2002 09:11:41 -0800 Received: from imo-m04.mx.aol.com ([64.12.136.7]) by psg.com with esmtp (Exim 3.33 #1) id 16Xmea-00020b-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 09:11:40 -0800 Received: from DougEwell2@cs.com by imo-m04.mx.aol.com (mail_out_v31_r1.26.) id i.de.21d123b9 (4563); Mon, 4 Feb 2002 12:11:35 -0500 (EST) From: DougEwell2@cs.com Message-ID: Date: Mon, 4 Feb 2002 12:11:35 EST Subject: Re: [idn] Fw: Cyrillics - Latin To: idn@ops.ietf.org CC: dhc@dcrocker.net, Elisabeth.Porteneuve@cetp.ipsl.fr MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: CompuServe 2000 32-bit sub 113 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 2002-02-04 8:40:29 Pacific Standard Time, dhc@dcrocker.net writes: > Domain names are character strings, they are not language. All of this > debate pertains to very important issues about language usage. It is > outside the scope of the working group. Some time ago I brought up the example of three of my favorite search engines: - google.com - altavista.com - teoma.com I challenged the list to identify -- unambiguously, to the point where it could be determined by software -- the language(s) to which the words "google," "altavista" (or for that matter "alta vista"), and "teoma" belong. Not surprisingly, nobody responded. For that matter, to what language do the words "idn," "ops," and "ietf" belong? Don't tell me they are abbreviations -- I know that. My point is that Dave is 100% correct; domain names are strings of characters. If they happen to spell one or more words in a natural language, so much the better, but that is not primarily what they are. -Doug Ewell Fullerton, California (address will soon change to dewell@adelphia.net) From owner-idn@ops.ietf.org Mon Feb 4 12:36: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 MAA00780 for ; Mon, 4 Feb 2002 12:36:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xmrr-0002lY-00 for idn-data@psg.com; Mon, 04 Feb 2002 09:25:23 -0800 Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu) by psg.com with smtp (Exim 3.33 #1) id 16Xmrp-0002lN-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 09:25:21 -0800 Received: (qmail 11460 invoked by uid 1001); 4 Feb 2002 17:24:14 -0000 Date: 4 Feb 2002 17:24:14 -0000 Message-ID: <20020204172414.13472.qmail@cr.yp.to> Mail-Followup-To: dhc@dcrocker.net, smb@research.att.com, Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: Dave Crocker , "Steven M. Bellovin" , Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration References: <20020204023529.79C5B7B4B@berkshire.research.att.com> <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Dave Crocker writes: > for example, MICROS0FT.COM was done. I can see the difference between O and 0, even without a slash through the 0; the O is more square. I bet you can see the difference too. In contrast, a properly printed uppercase B is identical to a properly printed uppercase Beta. A font designer would have to be illiterate to distinguish them. Some people say that the B-B problem is inherent in internationalized domain names. That's simply not true. We can * declare that uppercase letters are obsolete, although software will still have to accept uppercase ASCII for compatibility, and * allow selected characters that don't cause visual confusion, such as lowercase beta. Yes, people will be prohibited from using other characters. Yes, we will have to be very careful. Yes, we will have to review each character individually, paying attention to what we're actually doing. This is the price of doing the job right. A similarly careful approach will also let us move directly to UTF-8 instead of this special-purpose-character-set insanity. Yes, sendmail corrupts bytes 128 through 159, but it doesn't corrupt lowercase beta. ---Dan From owner-idn@ops.ietf.org Mon Feb 4 16:27: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 QAA06297 for ; Mon, 4 Feb 2002 16:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XqPi-000B7j-00 for idn-data@psg.com; Mon, 04 Feb 2002 13:12:34 -0800 Received: from [211.218.145.193] (helo=postel2) by psg.com with esmtp (Exim 3.33 #1) id 16XqPg-000B7W-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 13:12:33 -0800 Received: (from root@localhost) by postel2.postel.co.kr (8.11.0/8.11.0) id g14LCGf14127 for idn@ops.ietf.org; Tue, 5 Feb 2002 06:12:16 +0900 To: idn@ops.ietf.org, "Dave Crocker" Cc: Elisabeth.Porteneuve@cetp.ipsl.fr Received: Postel SMTP Relay v1.0 Received: from MASTER ([210.217.27.236]) by postel2 (8.11.0/8.11.0) with SMTP id g14LCB614121; Tue, 5 Feb 2002 06:12:11 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 Message-Id: <0abf01c1adc0$925f4dd0$ec1bd9d2@temp> 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: Tue, 5 Feb 2002 06:11:53 +0900 X-Msmail-Priority: Normal Subject: Re: [idn] Fw: Cyrillics - Latin References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjEwcHQnPgoK LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAKRnJvbSYjNTg7ICJEYXZl IENyb2NrZXIiIDxkaGNAZGNyb2NrZXIubmV0Pgo+IAo+IERvbWFpbiBuYW1l cyBhcmUgY2hhcmFjdGVyIHN0cmluZ3MsIHRoZXkgYXJlIG5vdCBsYW5ndWFn ZS4gIAoKRG9tYWluIG5hbWVzIGFyZSBub3QgcHVyZSBjaGFyYWN0ZXIgc3Ry aW5ncy4gClJhdGhlciwgRG9tYWluIG5hbWVzIGFyZSBhIHN1YnNldCBvZiBl bnRpcmUgY2hhcmFjdGVyIHN0cmluZ3MgIAoqd2l0aCBpbXBvc2VkIHJ1bGVz IGFuZCBjb25zdHJhaW50cyBhbmQgcmVxdWlyZW1lbnRzKgp0byBzZXJ2ZSBh cyBpZGVudGlmaWVycyB0byAqbmFtZSogdW5pcXVlbHkgYW5kIHVuYW1iaWdv dXNseSAgIApkb21haW5zIGluIHRoZSBETlMgICAgZm9yIGludGVybmF0aW9u YWwgdXNlciBjb21tdW5pdGllcy4KCllvdXIgY2xhaW0gc2VlbXMgdG8gYmUg aW5zaXN0aW5nIHRoYXQgSUROIGlzIGZvciAqbWFjaGluZXMqLCBub3QgZm9y IGh1bWFuIGJlaW5ncy4KbWFjaGluZXMgZG9uJ3QgY29tcGxhaW4gYWJvdXQg dGhlIGFtYmlndWl0eSBiZXR3ZWVuIDxBPi5jb20gYW5kIDxDeXJpbGxpYyBB Pi5jb20uIAoKTW9yb3ZlciwgdGhlIHByb2JsZW0gb2YgSUROIGl0c2VsZiBt YXkgYmVjb21lIG91dC1vZi1zY29wZSBvZiB0aGlzIFdHIGJ5IGludHJvZHVj aW5nIHRoZSAKb3V0LW9mLXNjb3BlICpwb2xpY3kqIHJ1bGVzLiAKCkFueSBz b3VuZCBhZGRyZXNzIHN5c3RlbSBvciBpZGVudGlmaWVyIHN5c3RlbXMgc2hv dWxkIGJlIHNlbGYtY29udGFpbmVkIGFuZApzZWxmLWNvbXBsZXRlLiAgRGVh ZGx5IG5lZWRzIGZvciBwZXItem9uZSBiYXNpcyBjb21wZW5zYXRpbmcgc29s dXRpb25zIGxpa2UKcG9saWN5LWJhc2VkIG11bHRpcGxlIHJlZ2lzdHJhdGlv bnMgcHJvdmUgYW5kIGFkbWl0IHRoYXQgSUROIG11c3Qgbm90IGJlIHB1cmUg c3RyaW5ncy4KVGhlICJwb2xpY3kiIGNhbm5vdCBiZSBhcHBsaWVkIG9yIGNv ZGVkIG9yIGVuZm9yY2VkIGZ1cnRoZXIgaW50byBudW1lcm91cyBpbmRlcGVu ZGFudCBhcHBsaWNhdGlvbnMsIApidXQgb25seSBpbnRvIHBlciB6b25lICBh dXRob3JhdGF0aXZlIHNlcnZlcnMuIApTdWNoIGluY29uc2lzdGVuY3kgZHVl IHRvIHR3by1sYXllcmVkIChzdHJpbmdwcmVwIGFuZCB0aGVuIHBvbGljeSkg cnVsZXMgd2lsbCBjYXVzZSAKY29uZnVzaW9ucyBhbmQgdHJvdWJsZXMuCgpU aGlzIFdHIGlzIG5vdCBxdWFsaWZpZWQgdG8gZGlzY3VzcyB0aGUgc3VjY2Vz cyBvZiBzdWNoICJwb2xpY3kiLCBhbmQgaXRzIGRpc2N1c3Npb24gaXMKc3Vy ZWx5IG91dCBvZiBzY29wZSBvZiB0aGlzIFdHLiBJZiBjdXJyZW50IElETiBz b2x1dGlvbnMgcmVseSBvbiBzdWNoIApvdXQtb2Ytc2NvcGUgYW5kIHN0aWxs LXVucmVzb2x2ZWQgYW5kIG5vdC1leGlzdGluZyBhbmQgbm90LXZlcmlmaWVk ICJwb2xpY3kiLApob3cgY2FuIHdlIGRlY2xhcmUgdGhpcyBJRE4gc29sdXRp b24gaXMgb2theSBhbmQganVzdGlmeSBsYXN0IGNhbGxzIGZvciBpdD8KCgoK U29vYm9rIExlZQoKCgoKCgo8L1BSRT4KPGltZyBzcmM9aHR0cDovL3Bvc3Rl bDIucG9zdGVsLmNvLmtyL3JlYWQvMTAxMjg1NzExMy05ODA1OWRkMDlmMmZm ZTZkYzQyNWQ1NDExYzAyYzYyOC40MWU1ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMu aWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT48 aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZHEvMTAx Mjg1NzExMy05ODA1OWRkMDlmMmZmZTZkYzQyNWQ1NDExYzAyYzYyOC40MWU1 ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMuaWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwu dG8vaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0x IGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K From owner-idn@ops.ietf.org Mon Feb 4 16:48: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 QAA06629 for ; Mon, 4 Feb 2002 16:48:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XqjY-000BUi-00 for idn-data@psg.com; Mon, 04 Feb 2002 13:33:04 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16XqjX-000BUc-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 13:33:03 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14LWo312831; Mon, 4 Feb 2002 13:32:50 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <83129960.1012820475@localhost> References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> <83129960.1012820475@localhost> Date: Mon, 4 Feb 2002 13:32:43 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk The message from CDNC says that the Traditional-Simplified problem for Chinese users cannot be solved by registration policy. This is not true, and many of the CDNC members who have come to IETF meetings know that. Of course, CDNC members would like to maximize their financial gain in registration, but the concern of the IETF is always towards helping users. There is a huge different between "cannot be solved" and "it will cost a small number of organizations a lot of money". Solving the Traditional-Simplified problem in the IDN protocol would have given more uniform results for users. The intense discussions over the past 18 months have shown that not only is it unlikely that there will ever be an IETF-based solution, and it has also become clear that a registration-based solution will likely give Chinese users more sensible naming that anything than the IETF could standardize. For example, in the IDN WG, the proposals from CDNC members only addressed part of the Traditional-Simplified problem (the 1:1 mapping), while the registration solution can address all of the problem in a manner that will help Chinese users. Due to the efforts of some CDNC members, the IETF is now well aware of the "2^n" variant problem that is unique to the use of Han characters in the Chinese language. Fortunately, using registration guidelines will solve the problem. The only people seriously affected by the size of DNS zones created by the "2^n" problem will be very large, flat zones such as those managed by CDNC members, but they are able to compensate for the size of zones with no changes to the DNS protocols. Of course, the character variant problem exists in many different languages, not just in Chinese. Because of this, each registry or zone that includes IDN names needs to make decisions about name equivalence (and therefore multiple registrations) before they enter any IDN names into their zone. Based on this input during Working Group last call from the CDNC, it seems clear that we need to explain these points more in the IDNA document. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Feb 4 16:50: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 QAA06662 for ; Mon, 4 Feb 2002 16:50:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xqnh-000Bad-00 for idn-data@psg.com; Mon, 04 Feb 2002 13:37:21 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.33 #1) id 16Xqng-000BaW-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 13:37:20 -0800 Received: from MASTER ([210.217.27.236]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g14LbER27287; Tue, 5 Feb 2002 06:37:14 +0900 Message-ID: <0ad701c1adc4$12ead660$ec1bd9d2@temp> From: "Soobok Lee" To: , "Paul Hoffman / IMC" References: <7FC3066C236FD511BC5900508BAC86FE9195EB@trestles.internal.realnames.com> <022401c1ab85$d72c0170$ec1bd9d2@temp> Subject: Re: [idn] stringprep comment 1 Date: Tue, 5 Feb 2002 06:36:58 +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: Saturday, February 02, 2002 12:06 PM Subject: Re: [idn] stringprep comment 1 > At 10:06 AM +0900 2/2/02, Soobok Lee wrote: > >There are many applications that don't give back immediate negative > >answers to end users , regarded as implicitly positive answer. > >The end users may believe their transactions > >were successful and leave their PC and go vacation! :-) > > So, how is this different than today's DNS? > > You keep bringing up vague comparisons with no concrete examples. It > sounds like you really believe what you are saying, but the rest of > us cannot figure out if what you are saying has any merit to it > unless you get much more specific. You may have missed my specific examples listed in my previous postings. Still, i think the categorization of applications IDN behaviours into 2 types is from oversimplification. Many applications defer its validation of native IDN labels against authoritative stored strings toward later time, and make later failures silently and that gives no immediate feedback to users. Think about uppercased new-script IDN email addresses submitted for job applications forms. What if job applications server is using old nameprep and defer its ACE encoding until the employer will try to reply them with acceptance notices after finishing reviews, while the applicants are using new nameprep and confident in the success of their uppercased native labels, waiting for never-coming acceptance emails from the employer. Soobok Lee > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Feb 4 17:00: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 RAA06780 for ; Mon, 4 Feb 2002 17:00:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XqwM-000Box-00 for idn-data@psg.com; Mon, 04 Feb 2002 13:46:18 -0800 Received: from [211.218.145.194] (helo=postel3.postel.co.kr) by psg.com with esmtp (Exim 3.33 #1) id 16XqwL-000Boq-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 13:46:17 -0800 Received: from MASTER ([210.217.27.236]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g14LkBR27365; Tue, 5 Feb 2002 06:46:12 +0900 Message-ID: <0ae701c1adc5$5372f590$ec1bd9d2@temp> From: "Soobok Lee" To: , "Dave Crocker" Cc: References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> Subject: Re: [idn] Fw: Cyrillics - Latin Date: Tue, 5 Feb 2002 06:45:55 +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 (sorry for my previous posting in bad html settings, i repost this in pure text) ----- Original Message ----- From: "Dave Crocker" > > Domain names are character strings, they are not language. > Domain names are not pure character strings. Rather, Domain names are a subset of entire character strings *with imposed rules and constraints and requirements* to serve as identifiers to *name* uniquely and unambigously domains in the DNS for international user communities. Your claim seems to be insisting that IDN is for *machines*, not for human beings. machines don't complain about the ambiguity between .com and .com. Moreover, the problem of IDN itself may become out-of-scope of this WG by introducing the out-of-scope *policy* rules. Any sound address systems or identifier systems should be self-contained and self-complete. Deadly needs for per-zone basis compensating solutions like policy-based multiple registrations prove and admit that IDN must not be pure strings. The "policy" cannot be applied or coded or enforced further into numerous independant applications, but only into per zone authoritative servers. Such inconsistency due to two-layered (stringprep and then policy) rules will cause confusions and troubles. This WG is not qualified to discuss the success of such "policy", and its discussion is surely out of scope of this WG. If current IDN solutions rely on such out-of-scope and still-unresolved and not-existing and not-verified "policy", how can we declare this IDN solution is okay and justify last calls for it? Soobok Lee From owner-idn@ops.ietf.org Mon Feb 4 17:08: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 RAA06889 for ; Mon, 4 Feb 2002 17:08:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XrBM-000C9m-00 for idn-data@psg.com; Mon, 04 Feb 2002 14:01:48 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.33 #1) id 16XrBL-000C9g-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 14:01:47 -0800 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 OAA03287; Mon, 4 Feb 2002 14:01:40 -0800 Message-Id: <5.1.0.14.2.20020204135906.01c3cb78@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 14:00:55 -0800 To: Paul Hoffman / IMC From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo In-Reply-To: References: <83129960.1012820475@localhost> <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> <83129960.1012820475@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01:32 PM 2/4/2002 -0800, Paul Hoffman / IMC wrote: >Of course, the character variant problem exists in many different >languages, not just in Chinese. Because of this, each registry or zone >that includes IDN names needs to make decisions about name equivalence >(and therefore multiple registrations) before they enter any IDN names >into their zone. Based on this input during Working Group last call from >the CDNC, it seems clear that we need to explain these points more in the >IDNA document. This approach has some major benefits. 1. It acknowledges the basic issue. 2. It moves the handling of the issue to a venue better able to resolve it. 3. It avoid major complexities being added to the IDN/DNS protocol. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Feb 4 19:40: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 TAA09275 for ; Mon, 4 Feb 2002 19:40:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XtJZ-000EmY-00 for idn-data@psg.com; Mon, 04 Feb 2002 16:18:25 -0800 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by psg.com with esmtp (Exim 3.33 #1) id 16XtJX-000EmS-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 16:18:24 -0800 Received: from m1.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0201-Fujitsu Gateway) id JAA09437 for ; Tue, 5 Feb 2002 09:18:14 +0900 (JST) (envelope-from seki@jp.fujitsu.com) Received: from poi.sysrap.cs.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0112-Fujitsu Domain Master) id JAA20481 for ; Tue, 5 Feb 2002 09:18:14 +0900 (JST) (envelope-from seki@jp.fujitsu.com) Received: from roan (dhcp107.sysrap.cs.fujitsu.co.jp [10.35.109.107]) by poi.sysrap.cs.fujitsu.co.jp (Postfix) with SMTP id 71E561EC3 for ; Tue, 5 Feb 2002 09:18:13 +0900 (JST) Message-ID: <00fb01c1adda$ae524eb0$6b6d230a@sysrap.cs.fujitsu.co.jp> From: "Masahiro Sekiguchi" To: References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> Subject: Re: [idn] Fw: Cyrillics - Latin Date: Tue, 5 Feb 2002 09:18:47 +0900 Organization: Fujitsu Limited 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 > Domain names are character strings, they are not language. All of this > debate pertains to very important issues about language usage. It is > outside the scope of the working group. Sounds reasonable. Then, what we need to make clear is the answer to a question: Why is uppercase/lowercase issue that is unique to a particular group of scripts covered in this group? Or, in other words, Are there any reason we can't remove case mapping from our spec? (Other than something like "because it is a natural English convention..." :-) Once some persuasive statements are included in our draft, most of complains (if not all) about lack of some language- dependent processing from our spec will disappear. From owner-idn@ops.ietf.org Mon Feb 4 20:01: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 UAA09469 for ; Mon, 4 Feb 2002 20:01:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xtqi-000FSL-00 for idn-data@psg.com; Mon, 04 Feb 2002 16:52:40 -0800 Received: from smtp23.singnet.com.sg ([165.21.101.203]) by psg.com with esmtp (Exim 3.33 #1) id 16Xtqg-000FSF-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 16:52:39 -0800 Received: from jamescompaq (bb-203-125-132-44.singnet.com.sg [203.125.132.44]) by smtp23.singnet.com.sg (8.12.2/8.12.2) with SMTP id g150qZiI021028; Tue, 5 Feb 2002 08:52:35 +0800 Message-ID: <00ba01c1addd$a6406420$0701000a@jamescompaq> From: "James Seng/Personal" To: "Masahiro Sekiguchi" , References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> <00fb01c1adda$ae524eb0$6b6d230a@sysrap.cs.fujitsu.co.jp> Subject: Re: [idn] Fw: Cyrillics - Latin Date: Tue, 5 Feb 2002 08:40:02 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just one clarification, but one I feel quite important: The inclusion of case mapping is not because it is "English convention". The case mapping data of Nameprep comes from the definition of Unicode Technical Report #21 Case Mapping which includes mapping for scripts that is bicameral, ie scripts that have well-defined upper & lower case. (Note: we still talking about scripts, not languages) It is definately appropriate to question the inclusion or exclusion of UTR#21. The choice open to the group include: 1. Choose to include UTR#21 in IDN; or 2. Choose excluse UTR#21 from IDN But it is out-of-scope for the IDN to change/modify/bypass/adopt-and-extend UTR#21. These are better done in the UTC. -James Seng > Or, in other words, > > Are there any reason we can't remove case mapping from > our spec? (Other than something like "because it is a > natural English convention..." :-) > > Once some persuasive statements are included in our draft, > most of complains (if not all) about lack of some language- > dependent processing from our spec will disappear. > > > > > From owner-idn@ops.ietf.org Mon Feb 4 20:01: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 UAA09482 for ; Mon, 4 Feb 2002 20:01:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XtsX-000FU8-00 for idn-data@psg.com; Mon, 04 Feb 2002 16:54:33 -0800 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.33 #1) id 16XtsW-000FTs-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 16:54:32 -0800 Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GR1BWL00.GI4; Tue, 5 Feb 2002 08:55:33 +0800 Message-ID: <002e01c1adde$96fc32e0$4407e29f@deng> From: "xiang deng" To: "John C Klensin" , "Erin Chen" , "Scott Bradner" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , References: <3C5E6549.50309@twnic.net.tw> <74382161.1012811728@localhost> Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC)Declaration Date: Tue, 5 Feb 2002 08:46:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA09482 Dear John: Let me do comparision and make this issue more clearly. There are a thousand reasons to agree/object a argument, but fact is fact. --------------examples ---------------|string/character|sound|glyph-|meaning|usage|cannotation|extention toz-------------togs-toys-toes---------|string(word)----|same-|------|same---|same-|same-------|same color-----------colour colur-----------|string(word)----|same-|------|same---|same-|same-------|same --|string(word)----|same-|------|same---|same-|same-------|same -------------------|character-------|same-|unlike|same---|same-|same-------|same A---------------a----------------------|character-------|same-|unlike|same---|same-|same-------|same Best Regards Deng xiang ----- Original Message ----- From: "John C Klensin" > And, of course, the new spelling system, unless it is much more > radical than the examples I have given above, introduces some > new homographs and other ambiguities. E.g., does the simplified > "toz" match the traditional "toys", or "toes", or maybe even > "togs", or the made-up traditional word "toz"? Or perhaps > several of them? Does the present tense of "to read" get mapped > into "reed" while the past tense gets mapped into "red"? And, > if so, what happens to the plant and the color (colour? colur? > :-( ). > > Now, if you treat each "word" or "spelling variation" as if it > were a single character, you probably have a first-order > approximation to the Chinese situation. And, to a greater or > lesser extent, the following statements are all true: > (iii) Since, in Chinese, the things we see as "words" in > English are really single characters, one ought to be > able to do the extended mapping and matching things we > now do for "case" in ASCII, and for case and other > simplifications that are proposed for Nameprep, for > these simplifications/variations also... even if it > clearly is not compatible with the DNS to do them for > English word-spelling variations. > From owner-idn@ops.ietf.org Mon Feb 4 20:47: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 UAA09860 for ; Mon, 4 Feb 2002 20:47:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xub0-000GSE-00 for idn-data@psg.com; Mon, 04 Feb 2002 17:40:30 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Xub0-000GS8-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 17:40:30 -0800 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g151eO319463; Mon, 4 Feb 2002 17:40:24 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <00fb01c1adda$ae524eb0$6b6d230a@sysrap.cs.fujitsu.co.jp> References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> <00fb01c1adda$ae524eb0$6b6d230a@sysrap.cs.fujitsu.co.jp> Date: Mon, 4 Feb 2002 17:13:35 -0800 To: "Masahiro Sekiguchi" , From: Paul Hoffman / IMC Subject: Re: [idn] Fw: Cyrillics - Latin Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 9:18 AM +0900 2/5/02, Masahiro Sekiguchi wrote: >Then, what we need to make clear is the answer to a question: > > Why is uppercase/lowercase issue that is unique to a > particular group of scripts covered in this group? Very good point. I think we did have that justification in the distant past, but it was lost along the way. We will add it after the WG last call. The reason is that the current DNS has case-insensitive matching for current names; if we did not do that for the additional characters being added, you would get great user confusion. For example, "Abc" matches "abc", but "bc" would not match "bc". >Or, in other words, > > Are there any reason we can't remove case mapping from > our spec? (Other than something like "because it is a > natural English convention..." :-) Yes, there is a good reason: removing the table would introduce confusion. >Once some persuasive statements are included in our draft, >most of complains (if not all) about lack of some language- >dependent processing from our spec will disappear. We only wish. :-) Note that the case conversion is not "language-dependent" or even "script-dependent": it was added for all scripts (which are used in many languages) that have standardized case conversions. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Feb 4 21:36: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 VAA11302 for ; Mon, 4 Feb 2002 21:36:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XvGu-000HNh-00 for idn-data@psg.com; Mon, 04 Feb 2002 18:23:48 -0800 Received: from friendly.realnames.com ([63.251.238.102]) by psg.com with smtp (Exim 3.33 #1) id 16XvGt-000HNV-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 18:23:47 -0800 Received: (qmail 1963 invoked by uid 104); 5 Feb 2002 02:23:46 -0000 Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.819186 secs); 05 Feb 2002 02:23:46 -0000 Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; 5 Feb 2002 02:23:45 -0000 Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1450]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <244718@heaven.internal.realnames.com> for ; Mon, 4 Feb 2002 6:18:43 PM -0800 smtpmailfrom Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 18:22:50 -0800 Message-ID: <7FC3066C236FD511BC5900508BAC86FE91961E@trestles.internal.realnames.com> From: Yves Arrouye To: "'Paul Hoffman / IMC'" , Masahiro Sekiguchi , idn@ops.ietf.org Subject: RE: [idn] Fw: Cyrillics - Latin Date: Mon, 4 Feb 2002 18:20:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idn@ops.ietf.org Precedence: bulk > Very good point. I think we did have that justification in the > distant past, but it was lost along the way. We will add it after the > WG last call. The reason is that the current DNS has case-insensitive > matching for current names; if we did not do that for the additional > characters being added, you would get great user confusion. For > example, "Abc" matches "abc", but "bc" would > not match "bc". > > >Or, in other words, > > > > Are there any reason we can't remove case mapping from > > our spec? (Other than something like "because it is a > > natural English convention..." :-) > > Yes, there is a good reason: removing the table would introduce confusion. But we already know that there may be some confusion at some point, as you acknowledge a couple days ago, if some later revision of Unicode introduces new characters with case distinctions (guaranteed for 3.2 IIRC). So this really needs to be pointed out, so that people realize that it may break at any time depending on the applications they use. (The optimistic in me thinks that applications will strive to offer timely updates in order to offer a better user experience w/o the confusion.) YA From owner-idn@ops.ietf.org Mon Feb 4 21:54: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 VAA11468 for ; Mon, 4 Feb 2002 21:54:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xvem-000Hwg-00 for idn-data@psg.com; Mon, 04 Feb 2002 18:48:28 -0800 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.33 #1) id 16Xvek-000Hwa-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 18:48:27 -0800 Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GR1H6L00.EFS; Tue, 5 Feb 2002 10:49:33 +0800 Message-ID: <009f01c1adee$84231d40$4407e29f@deng> From: "xiang deng" To: , "Paul Hoffman / IMC" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1><83129960.1012820475@localhost> Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Date: Tue, 5 Feb 2002 10:40:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA11468 ----- Original Message ----- From: "Paul Hoffman / IMC" > The message from CDNC says that the Traditional-Simplified problem > for Chinese users cannot be solved by registration policy. This is > not true, and many of the CDNC members who have come to IETF meetings > know that. Of course, CDNC members would like to maximize their > financial gain in registration, but the concern of the IETF is always > towards helping users. There is a huge different between "cannot be > solved" and "it will cost a small number of organizations a lot of > money". If you want talk about financial problem, let me correct it: TC/SC solution(or registration solution ) will save user's money and cost registrar's money DON'T do TC/SC will cost user's money and make money for registrar. So what your comment is distorting fact. And, Please give me a successiveful example of such registration solution. > Due to the efforts of some CDNC members, the IETF is now well aware > of the "2^n" variant problem that is unique to the use of Han > characters in the Chinese language. Fortunately, using registration > guidelines will solve the problem. Who will follow this registration guideline? All administrators? Regards. Deng xiang From owner-idn@ops.ietf.org Mon Feb 4 22:03: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 WAA11589 for ; Mon, 4 Feb 2002 22:03:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XvkT-000I4i-00 for idn-data@psg.com; Mon, 04 Feb 2002 18:54:21 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.33 #1) id 16XvkS-000I4a-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 18:54:20 -0800 Received: (qmail 13973 invoked by uid 1001); 5 Feb 2002 02:53:18 -0000 Date: 5 Feb 2002 02:53:18 -0000 Message-ID: <20020205025318.7465.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Fw: Cyrillics - Latin References: <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <043b01c1ad7b$a815ace0$0d01000a@jamessonyvaio> <5.1.0.14.2.20020204081434.035a5cb0@127.0.0.1> <00fb01c1adda$ae524eb0$6b6d230a@sysrap.cs.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC writes: [ if domain names become case-sensitive ] > you would get great user confusion URLs are already case-sensitive. Do you claim that users are confused by this---so confused, in fact, to justify the costs of making all URLs case-insensitive? Where are the studies supporting your claims? The careful approach is to start with (1) case-sensitive IDNs in which (2) uppercase letters are prohibited. If it turns out that users really need case insensitivity, we can add it later, because of #2. Otherwise, we'll avoid huge implementation and deployment costs, because of #1. ---Dan From owner-idn@ops.ietf.org Mon Feb 4 22:08: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 WAA11634 for ; Mon, 4 Feb 2002 22:08:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xvsv-000IJL-00 for idn-data@psg.com; Mon, 04 Feb 2002 19:03:05 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.33 #1) id 16Xvsu-000IJE-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 19:03:04 -0800 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id TAA15815 for ; Mon, 4 Feb 2002 19:02:56 -0800 (PST) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id TAA02596 for ; Mon, 4 Feb 2002 19:03:03 -0800 (PST) Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id TAA02581; Mon, 4 Feb 2002 19:03:02 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140]) by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id TAA18911; Mon, 4 Feb 2002 19:02:02 -0800 (PST) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id TAA00991; Mon, 4 Feb 2002 19:03:00 -0800 (PST) Date: Mon, 4 Feb 2002 19:03:00 -0800 (PST) From: Kenneth Whistler Message-Id: <200202050303.TAA00991@birdie.sybase.com> To: yves@realnames.com Subject: RE: [idn] Fw: Cyrillics - Latin Cc: idn@ops.ietf.org X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Yves said: > > > Are there any reason we can't remove case mapping from > > > our spec? (Other than something like "because it is a > > > natural English convention..." :-) > > > > Yes, there is a good reason: removing the table would introduce confusion. > > But we already know that there may be some confusion at some point, as you > acknowledge a couple days ago, if some later revision of Unicode introduces > new characters with case distinctions (guaranteed for 3.2 IIRC). This is true, but at this point the characters with case distinctions introduced are truly rare (an archaic Greek koppa not used in modern Greek, four Cyrillic letters used only in Kildin Sami, eight Cyrillic letters used only in Komi in an obsolete orthography no longer in use). And the candidates are getting scarcer and rarer. > So this > really needs to be pointed out, so that people realize that it may break at > any time depending on the applications they use. (The optimistic in me > thinks that applications will strive to offer timely updates in order to > offer a better user experience w/o the confusion.) I agree. By the way, a propos of the note that originally started this thread, has anyone else actually realized that there really is a http://www.cobet.ru/ And on the title of the home page, this business consultancy group playfully posts "COBET.py", illustrating the cross-script dual pun on "Soviet" and the Paraguayan ccTLD. (They apparently haven't bothered to also create a www.cobet.py in reality.) And going back to points made by John, Mark, and others, one should note that Unicode is not the issue here. *Every* major character encoding used in Russia includes both ASCII and Cyrillic, and the same well-known overlaps of Latin letters and Cyrillic letters occur in all of them, from ISO 8859-5 to Code Page 855 to Windows 1251 to KOI-8 to Mac Cyrillic. Unless Cyrillic were eliminated from domain names altogether (which I doubt the Russians, Ukrainians, Bulgarians, and Serbs would be very happy about), these kinds of visual overlaps will occur. And as Mark said: > I don't think a solution is possible in DNS. --Ken > > YA > > > From owner-idn@ops.ietf.org Mon Feb 4 22: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 WAA13062 for ; Mon, 4 Feb 2002 22:42:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XwO0-000J4X-00 for idn-data@psg.com; Mon, 04 Feb 2002 19:35:12 -0800 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.33 #1) id 16XwNv-000J4Q-00 for idn@ops.ietf.org; Mon, 04 Feb 2002 19:35:07 -0800 Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GR1JCD00.RIX; Tue, 5 Feb 2002 11:36:13 +0800 Message-ID: <00b201c1adf5$0930a420$4407e29f@deng> From: "xiang deng" To: "James Seng/Personal" , "Erin Chen" , "Scott Bradner" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <200202031600.g13G07n19482@newdev.harvard.edu> <3C5E6549.50309@twnic.net.tw> <03e601c1ad7a$5dd2b570$0d01000a@jamessonyvaio> Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration Date: Tue, 5 Feb 2002 11:27:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Big5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA13062 ----- Original Message ----- From: "James Seng/Personal" > The problem of Traditional Chinese & Simplified Chinese cannot be > expressed as a bicameral (upper/lower case) problem. To say it is > similar to "A" and "a" is at best misleading. TC/SC is not a simple 1 to > 1 mapping. > The complexity of TC/SC is not something can be explained in a single > word, but it is described quite well in the following articles: > http://playground.i-dns.net/one/onec_sum.htm > http://www.cjk.org/cjk/c2c/c2cbasis.htm. The whole TC/SC issue include 1:1 1:n 1:(n+1) n:m and so on. I had explained it times and times: 1:1 is accurate mapping from 1 to 1, it is defined in "A Complete set of Simplified and Traditional Chinese character". (2237 pairs) They cover 83.6% of current CDN registered data in our database (500,000 samples) 1:n 1:(n+1) n:m is depended on context, it need compute artificial intelligent technology to solved.(about 230 pairs) we are talking about 1:1. > In addition, the Unicode Technical Consortium have send the following > recommendation to the working group on TC/SC > http://www.imc.org/idn/mail-archive/msg04005.html In my memory, there was a mail in IDN WG maillist, it also said that xxx from Chinese disagree TC/SC in UTC. How does it change so quickly? I'm not challenge Mr.Mark Davis. And I know there is a CJK WG in UTC. UTC is a organization to collect/clean up different glyphs. They are experts of language/script/character. But we are talking about the possibility to solve 1:1 TC/SC issue in CDN. > This is not to say we close our eyes and ears away from the "language" > problem. Once again, lets me remind everyone that every language have > its own problems so it is not just Chinese. Instead, we need a more > complex naming system, one that John have already explained in his mail, > for *all* language problems: > http://www.imc.org/idn/mail-archive/msg05615.html Yes. We should discuss "language" problem in Lay2/Lay3 designed by Mr.John. But how to deal with the problem lied in CDN? It's in domain name system. Do you mean: Because Lay2/Lay3 can solve this problem,then we needn't solve it in CDN? But the problem is still here. Regards. Deng xiang From owner-idn@ops.ietf.org Mon Feb 4 23:49: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 XAA14361 for ; Mon, 4 Feb 2002 23:49:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XxSf-000KgQ-00 for idn-data@psg.com; Mon, 04 Feb 2002 20:44:05 -0800 Date: Tue, 05 Feb 2002 06:29:00 +0800 From: Erin Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Message-Id: To: idn-data@psg.com Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Dave Crocker CC: IESG , IAB , IETF IDN WG , "Vinton G. Cerf" , Masanobu Katoh , John klensin , harald , Fred baker , Stuart Lynn , Paul Haffman , Mohamed Sharil Tarmizi , JET Members , Thomas Narten , Erik Nordmark , Andrew McLaughlin , "H. T. Kung" , Marc Blanchet , James Seng/Personal , Masanobu Katoh , Mouhamet Diop , Patrik F?lstr?m , Qiheng Hu , Sang-Hyon Kyong , Elisabeth Porteneuve , hlqian , mao , Zhang Wen Hui , xiang deng , xiaodong lee , , hoho , Kenny Huang , Chun-Hsin Wu , sstseng , Wen-Sung Chen , Nai-Wen Hsu , yktham , jasonho , alanysho , christine Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1> Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Dear Dave Crocker, Dave Crocker wrote: > At 06:27 PM 2/1/2002 +0800, Erin Chen wrote: > >> But, the architecture of IDN defined in above four documents does not >> solve the traditional and simplified Chinese character variant problem. > > > There are many things the IDN specifications do not do. Rather, the > specifications focus on solving satisfying only the requirement they > are supposed to satisfy. Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of IDN WG and will be dropped. And we has submit a Requirements of Chinese Domain Name draft. > Solution of TC/SC is one example of equivalence among Unicode sets. > Indeed, IDN does not attempt to specify such equivalences. Equivalence > among separate Unicode sets is essentially an open technical topic for > which there are no accepted practises. > > Still, this topic has been discussed, debated and explained > extensively within the IDN working group. I understand the IDN WG has discussed for a long time. But if the Unicode sets is still not well defined as you said. Why IDN refer to a unwell defined Unicode sets? If TC/SC equivalence could not be adopt by IDN, once IDN become standard the serious expected delegation problem will occur. That means the user could not get the consistent resolving by DNS. DNS become untrust. > The purpose of IDN is to permit use of an increased range of > characters in domain name, beyond the current limit of ASCII. It is > not the goal of the working group to invent character set conventions > such as equivalence between different sets. I suggest we have to measure if we omit some requirement such as equivalence between some variants like TC/SC, then what kind of serious problem would be caused. And to review the original goal of IDN you expressed is still proper or not. > It will be wonderful when equivalence between sets is achieved. > However it is not the charter of IDN to solve basic issues of > character set equivalence and it is not reasonable to delay the > utility of the character set enhancement specified by IDN, in the hope > that some day the question of character set equivalence is achieved. We made the CDNC declaration is not intend to hinder the progress of IDN. If the IDN still could not consider or find a proper solution for CDN requirement, we rather the IDN switch off CDN temperarily till the proper solution comes out to prevent the expected serious problem occur. > Contrary to the claim that the working group is moving too quickly, my > own guess is that it has been a major source of delay for the working > group for at least 6 months. Perhaps much longer. > > d/ > ---------- > Dave Crocker > Brandenburg InternetWorking > tel +1.408.246.8253; fax +1.408.273.6464 Erin Chen > From owner-idn@ops.ietf.org Mon Feb 4 23:50: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 XAA14378 for ; Mon, 4 Feb 2002 23:50:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XxRB-000KdE-00 for idn-data@psg.com; Mon, 04 Feb 2002 20:42:33 -0800 Date: Mon, 04 Feb 2002 09:30:46 -0800 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Cc: "Steven M. Bellovin" , Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo In-Reply-To: <20020204172414.13472.qmail@cr.yp.to> References: <20020204023529.79C5B7B4B@berkshire.research.att.com> <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: At 05:24 PM 2/4/2002 +0000, D. J. Bernstein wrote: >Dave Crocker writes: > > for example, MICROS0FT.COM was done. > >I can see the difference between O and 0, even without a slash through >the 0; the O is more square. I bet you can see the difference too. You are relying on a) particular font representation differences on your screen, and b) user perceptual skills that are not always present. In point of fact, this "attack" has been performed, presumably with some success. The fact that it has some technical differences from the current source of worry is a minor point. The real point is that we have moved from technical specification into analysis of human behavior and the IETF is exceedingly bad at this latter activity, particularly with respect to predictions of the future for problems that are not already significant. >In contrast, a properly printed uppercase B is identical to a properly >printed uppercase Beta. Sorry, no. 'B' and 'beta' are quite different. The difference is quite clear on my screen. (or, rather, it is as clear as 0 and O. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-idn@ops.ietf.org Mon Feb 4 23:50: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 XAA14390 for ; Mon, 4 Feb 2002 23:50:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XxTl-000KiK-00 for idn-data@psg.com; Mon, 04 Feb 2002 20:45:13 -0800 From: "Steven M. Bellovin" To: Dave Crocker Cc: Elisabeth Porteneuve , Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw, fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Feb 2002 11:25:27 -0500 Message-Id: <20020204162527.2411B7B4B@berkshire.research.att.com> Sender: owner-idn@ops.ietf.org Precedence: bulk In message <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>, Dave Crocker writes: >Steve, > >At 09:35 PM 2/3/2002 -0500, Steven M. Bellovin wrote: >>There'a a good discussion of the security risks of the code point >>problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140 > >homographic attacks are not new with the IDN effort. > >for example, MICROS0FT.COM was done. > >For that matter, choice of different top-level domains permits a degree of >homographic attack. Try looking at dnso.com, rather than dnso.org. (No, >this approach does not qualify precisely as homographic, but it takes >advantage of a small difference from the real name, hoping that users will >not notice. And it does work.) I know -- see slide 4 of http://www.research.att.com/~smb/talks/www.ps (or .pdf), from 1996. > >Hence, the IDN work does not introduce a new risk. > It amplifies it, however. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-idn@ops.ietf.org Mon Feb 4 23:50: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 XAA14403 for ; Mon, 4 Feb 2002 23:50:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XxUc-000KkS-00 for idn-data@psg.com; Mon, 04 Feb 2002 20:46:06 -0800 From: Erin Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Message-Id: To: idn-data@psg.com Date: Mon, 04 Feb 2002 20:46:06 -0800 Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Dave Crocker CC: IESG , IAB , IETF IDN WG Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1> Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk [Note: header field too long; To & Cc have been snapped - JS] Dear Dave Crocker, Dave Crocker wrote: > At 06:27 PM 2/1/2002 +0800, Erin Chen wrote: > >> But, the architecture of IDN defined in above four documents does not >> solve the traditional and simplified Chinese character variant problem. > > > There are many things the IDN specifications do not do. Rather, the > specifications focus on solving satisfying only the requirement they > are supposed to satisfy. Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of IDN WG and will be dropped. And we has submit a Requirements of Chinese Domain Name draft. > Solution of TC/SC is one example of equivalence among Unicode sets. > Indeed, IDN does not attempt to specify such equivalences. Equivalence > among separate Unicode sets is essentially an open technical topic for > which there are no accepted practises. > > Still, this topic has been discussed, debated and explained > extensively within the IDN working group. I understand the IDN WG has discussed for a long time. But if the Unicode sets is still not well defined as you said. Why IDN refer to a unwell defined Unicode sets? If TC/SC equivalence could not be adopt by IDN, once IDN become standard the serious expected delegation problem will occur. That means the user could not get the consistent resolving by DNS. DNS become untrust. > The purpose of IDN is to permit use of an increased range of > characters in domain name, beyond the current limit of ASCII. It is > not the goal of the working group to invent character set conventions > such as equivalence between different sets. I suggest we have to measure if we omit some requirement such as equivalence between some variants like TC/SC, then what kind of serious problem would be caused. And to review the original goal of IDN you expressed is still proper or not. > It will be wonderful when equivalence between sets is achieved. > However it is not the charter of IDN to solve basic issues of > character set equivalence and it is not reasonable to delay the > utility of the character set enhancement specified by IDN, in the hope > that some day the question of character set equivalence is achieved. We made the CDNC declaration is not intend to hinder the progress of IDN. If the IDN still could not consider or find a proper solution for CDN requirement, we rather the IDN switch off CDN temperarily till the proper solution comes out to prevent the expected serious problem occur. > Contrary to the claim that the working group is moving too quickly, my > own guess is that it has been a major source of delay for the working > group for at least 6 months. Perhaps much longer. > > d/ > ---------- > Dave Crocker > Brandenburg InternetWorking > tel +1.408.246.8253; fax +1.408.273.6464 Erin Chen > From owner-idn@ops.ietf.org Mon Feb 4 23:53: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 XAA14435 for ; Mon, 4 Feb 2002 23:53:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XxWh-000KpW-00 for idn-data@psg.com; Mon, 04 Feb 2002 20:48:15 -0800 From: "Edward Chuang" To: Subject: [idn] Please do not pass an IDN document which you know will cause conflicts and chaos Date: Tue, 5 Feb 2002 08:37:59 +0800 Message-ID: <000601c1addd$5c7454f0$ca126d8c@iis.sinica.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcGt3Vx0wRyoGoKKTC+MGOOCIkMG/g== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA14435 Ive recently come to know that IETF is about to release drafts on IDN standards, and to my regret, I found that the document does not solve problems for Chinese domain names. And this defect in your drafts will result conflicts and chaos for Internet users of Han characters, namely Chinese, Korean and Japanese, and the effect is international because users of these languages are all over the world. It is important to know that while a certain character can have different appearance in Simplified Chinese and Traditional Chinese Character forms even though they are actually same words with the same meaning; at the same time, a certain character which might look exactly the same, but in fact are two different words with different meaning when applied to different languages such as Chinese and Japanese. I believe that IETF bears great responsible in setting standards which will bring order to the Internet world, and any document which might cause disorder, should be carefully reconsidered before release. Therefore, Before IETF can resolve this problem and identify one mechanism which can differentiate these delicate language difference, IETF should not pass the document which would apply Unicode for IDN resolution, because this irresponsible decision is going to cause conflicts and chaos in DN registration policy and DRP worldwide. Edward Chuang edwardc@firebird.org.tw Firebird BBS Project From owner-idn@ops.ietf.org Mon Feb 4 23:53: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 XAA14447 for ; Mon, 4 Feb 2002 23:53:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XxVY-000Km6-00 for idn-data@psg.com; Mon, 04 Feb 2002 20:47:04 -0800 Date: Tue, 05 Feb 2002 06:43:42 +0800 From: Erin Chen MIME-Version: 1.0 To: John C Klensin CC: IESG , IAB , IETF.IDN.WG Message-Id: Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration References: <3C5A6DAE.9040905@twnic.net.tw> <178475239.1012596275@localhost> Content-Type: multipart/alternative; boundary="------------050900070403070603010302" Sender: owner-idn@ops.ietf.org Precedence: bulk --------------050900070403070603010302 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit [Note: header field too long; To & Cc field have been snapped - JS] Dear John, John C Klensin wrote: >Erin, > >Let me follow up Vint's note with some thoughts of my own, >with the understanding that they are mine personally and may >not reflect positions I would feel obligated to take as >technical advisor to the IDN WG or as a member of the IAB; the >WG or the IAB might well disagree with what I'm about to say. > I hope every one would try to rethinking about some contention. >I believe it has been fairly well demonstrated by this point >that there are _many_ problems that the protocols specified in >the IDN WG core documents will not solve. Many of these >problems involve Chinese Domain Names, many others do not. At >the root of most of both types of problems lies a distinction >between "identifiers" -- character strings used in narrow >contexts and to which many restrictive rules can be applied-- >and "user-visible names". The latter must obey the rules of >the languages in which they are constructed and written. If >they do not, confusion and astonishment results. > I agree with you. Some requirement MUST be solved in Layer1 if it is essentially define identifiers. But some requirement SHOULD be solve in upper Layer if it is not essentially define identifiers. >But, while some issues can be addressed with sufficient >ingenuity, the DNS cannot, in general, solve user-visible name >problems within the current design and basic DNS protocols. >Again, this raises especially difficult problems for Chinese >names, but there are problems of one sort or another with most >languages. The solutions for those user-visible name >problems, as we discussed in Minneapolis, lie in non-DNS >mechanisms, protocols, and database, not in the DNS or the IDN >WG's effort to fit some extra characters into the DNS. > It's nice to have chance to discuss with you in SLC(I know you mean SLC). >As we look at the IDN WG's efforts, it is important to >remember, first, that Unicode (ISO 10646) is a tool. It is a >tool that is better suited to some purposes than to others and >it is one that was designed in the context of very complex >tradeoffs. The WG chose to use that tool, largely because, >given _their_ constraints, there were no plausible >alternatives. > I agree with the IDN WG to use the well-defined part of Unicode. But about equivalent TC/SC is unwell-defined in the Unicode and it is also not the goal of Unicode Consortium. How can IDN stilll refer to the unwell-defined parts? >Similarly, we should view the IDN WG's outputs --if, indeed, >IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out to be the >outputs-- to be tools. They are not a perfect tool. It is >easy to find problems they don't solve, and problems with >characters that have equivalent meanings and different >appearances and code points (as in TC<->SC mapping) and >characters that have similar or identical appearances but >belong to different scripts and have different code points (as >in matching characters in Latin, Greek, and Cyrillic scripts) >are high on that list of unsolved problems. But, again, they >are a tool, and, while it quite drastic, I suggest that there >is a registration-based solution if that tool is >inappropriate. > Dear John, I'm afraid only the registgration-based solution still could not overcome. Even if there is a proper and well-defined registration policy(including how to manage the DNS zone file) but lack of corresponding technical solution to do the police, the zone file manager still can decide obey the policy or not. That will still cause inconsistent DNS resolving. As a identifier, the DNS would not be trusted. >The IDN WG also has the constraints, ultimately imposed by the >DNS architecture, that it cannot make a decision that solves a >problem for Greek at the expense of Cyrillic, nor can it make >one that solves a Chinese problem at the expense of making >Japanese or Korean unusable. Perhaps the more subtle matching >and >equivalence problems are sufficient to make the whole notion >unusable, at least for user-visible names. While I suspect >that might be true, the argument has not been convincingly >made. > >This suggests some actions you might consider: > >(i) Your colleagues argued quite persuasively in Minneapolis >that the difficulties imposed by the IDN WG approach on >Chinese-Language Domain names would cause serious consumer >confusion and disruption and could be expected to provide an >unreasonably good opportunity for fraudulent behavior. I >believe that I understand that argument, but many of the >people to whom your statement was addressed probably do not. >I would strongly suggest that you try to produce a document >that explains the problems, in a tutorial style, and at a >level adequate to educate someone with no knowledge of Chinese >and, perhaps no working knowledge of any script other than his >or her own. > Yes, it is important to let others understand the problems. >(ii) If registrations of CDNs are dangerous, prohibit them in >your own ccTLDs and, with the document mentioned above as a >tool, recommend to ICANN and directly to other domain >administrators (top-level and otherwise) that these codes not >be registered. That advice will, I fear inevitably, be >ignored in some places. But, if the explanation of the >consumer risks is clear enough, governments, regulators, and >injured parties will have solid grounds for holding registrars >who promote the use of such names responsible for any problems >they cause. > Once the IDN become a standard without adopt CDN requirements or other script requirements you'v mentioned, the serious problem would have occored. User can not wait during the gap untill the another, later, better,complete solution, such as non-DNS solutions. We have to separate the problem and solution is proper to deal with in DNS level or not. Some requirements are belonging to DNS level must still solved in the DNS level. Some requirements are beloning to non-DNS level should develop non-DNS solutions. As you mentioned above "identifiers" -- character strings used in narrow contexts is belonging to DNS level. Then "user-visible names" is belonging to non-DNS level. As for TC/SC 1 to 1 mapping, fit in with the definition of "identifiers" -- character strings used in narrow contexts. So it MUST solve in DNS level. And move the other rest of complexity TC/SC mapping ( 1 to n, n to 1, n to n , context ) to the upper Layer which is non-DNS solution. >(iii) Please continue to work with me and with others to >develop non-DNS solutions for user-visible names that do meet >your needs by accomodating matching that uses language and >other information in ways that the DNS cannot. > Yes, there are many complexity or user oriented requirements should be developed by non-DNS solutions. But, because it is non-DNS solution, so it could not substitute DNS resolving. Unless, close the DNS resolving and substitute by the non-DNS solution. >thanks and regards, > john > Erin Chen > >--On Friday, 01 February, 2002 18:27 +0800 Erin Chen > wrote: > >>-------------------------------------------------------------- >>----------- Chinese Domain Name Consortium (CDNC) >>Declaration >>-------------------------------------------------------------- >>----------- >> >>Based on current status of Internationalized Domain Name, CDNC >>makes following declaration: >> >>1. Currently, IETF IDN WG begins Last Call for the WG core >>documents (IDNA, NAMEPREP, STRINGPREP, and PUNYCODE). >> >>But, the architecture of IDN defined in above four documents >>does not solve the traditional and simplified Chinese >>character variant problem. That will cause serious delegation >>problem in the application of Chinese Domain Name. This >>technical flaw can't be compensated by registration policy; >>it'll prevent Chinese Domain Name from being used widely. All >>the future Internet applications based on Chinese Domain Name >>hierarchy will fail and ultimately Chinese Domain Name >>technology will result in failure. >> >>2. Under the commercial and social pressure, IETF IDN WG >>issues Last Call hastily without presenting a proper Chinese >>Domain Name technical solution. It will be detrimental to the >>ethnic-Chinese Internet community. >> >>3. IETF IDN WG does not solve Chinese Domain Name technical >>problem, but it is IETF IDN WG's responsibility to sincerely >>consider the consequences from adopting these drafts. Under >>the current condition, if IETF approves these IDN drafts, >>registrars will open Chinese Domain Name registration without >>considering the requirement of Chinese Domain Name and >>Chinese Domain Name will fall into confusion. This will damage >>Chinese Internet community seriously. >> >>4. IDN would be flawed by not adopting CDN requirements. >> >>Chinese Domain Name Consortium >>CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC >>Co-chair of CDNC: Qian Hualin, Professor >>Co-chair of CDNC: Shian-Shyong Tseng, Professor >>2002.2.1 >>-------------------------------------------------------------- >>------------- >> >> >> >> >> >> >> >> > --------------050900070403070603010302 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: 7bit Dear John,

John C Klensin wrote:
Erin,

Let me follow up Vint's note with some
thoughts of my own,
with the understanding that they are mine
personally and may
not reflect positions I would feel obligated to
take as
technical advisor to the IDN WG or as a member of the IAB;
the
WG or the IAB might well disagree with what I'm about to
say.
I hope every one would try to rethinking about some contention.
I believe it has been fairly well demonstrated by this
point
that there are _many_ problems that the protocols specified
in
the IDN WG core documents will not solve.  Many of
these
problems involve Chinese Domain Names, many others do not.
At
the root of most of both types of problems lies a
distinction
between "identifiers" -- character strings used in
narrow
contexts and to which many restrictive rules can be
applied--
and "user-visible names".  The latter must obey the rules
of
the languages in which they are constructed and written.
If
they do not, confusion and astonishment results.
I agree with you. Some requirement MUST be solved in Layer1 if it is essentially define
identifiers. But some requirement SHOULD be solve in upper Layer if it is not essentially
define identifiers.
But, while some issues can be addressed with
sufficient
ingenuity, the DNS cannot, in general, solve user-visible
name
problems within the current design and basic DNS
protocols.
Again, this raises especially difficult problems for
Chinese
names, but there are problems of one sort or another with
most
languages.  The solutions for those user-visible
name
problems, as we discussed in Minneapolis, lie in
non-DNS
mechanisms, protocols, and database, not in the DNS or the
IDN
WG's effort to fit some extra characters into the DNS.
It's nice to have chance to discuss with you in SLC(I know you mean SLC). 
As we look at the IDN WG's efforts, it is important
to
remember, first, that Unicode (ISO 10646) is a tool.  It is
a
tool that is better suited to some purposes than to others
and
it is one that was designed in the context of very
complex
tradeoffs.   The WG chose to use that tool, largely
because,
given _their_ constraints, there were no
plausible
alternatives.
I agree with the IDN WG to use the well-defined part of Unicode. But about equivalent TC/SC
is unwell-defined in the Unicode and it is also not the goal of Unicode Consortium.

How can IDN stilll refer to the unwell-defined  parts?
Similarly, we should view the IDN WG's
outputs --if, indeed,
IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out
to be the
outputs-- to be tools.  They are not a perfect tool.  It
is
easy to find problems they don't solve, and problems
with
characters that have equivalent meanings and
different
appearances and code points (as in TC<->SC mapping)
and
characters that have similar or identical appearances
but
belong to different scripts and have different code points
(as
in matching characters in Latin, Greek, and Cyrillic
scripts)
are high on that list of unsolved problems.  But, again,
they
are a tool, and, while it quite drastic, I suggest that
there
is a registration-based solution if that tool
is
inappropriate.
Dear John, I'm afraid only the registgration-based solution still could not overcome.
Even if there is a proper and well-defined registration policy(including how to manage
the DNS zone file) but lack of corresponding technical solution to do the police, the zone file
manager still can decide obey the policy or not. That will still cause inconsistent DNS resolving.
As a identifier, the DNS would not be trusted.

          

            
The IDN WG also has the constraints, ultimately
imposed by the
DNS architecture, that it cannot make a decision that
solves a
problem for Greek at the expense of Cyrillic, nor can it
make
one that solves a Chinese problem at the expense of
making
Japanese or Korean unusable.  Perhaps the more subtle
matching
and
equivalence problems are sufficient to make the whole
notion
unusable, at least for user-visible names.  While I
suspect
that might be true, the argument has not been
convincingly
made.

This suggests some actions you might
consider:

(i) Your colleagues argued quite persuasively in
Minneapolis
that the difficulties imposed by the IDN WG approach
on
Chinese-Language Domain names would cause serious
consumer
confusion and disruption and could be expected to provide
an
unreasonably good opportunity for fraudulent behavior.
I
believe that I understand that argument, but many of the
people
 to whom your statement was addressed probably do not.
I would
strongly suggest that you try to produce a document
that explains the
problems, in a tutorial style, and at a
level adequate to educate
someone with no knowledge of Chinese
and, perhaps no working
knowledge of any script other than his
or her own.

            

Yes, it is important to let others understand the problems. 

            

              
(ii) If registrations of CDNs are dangerous,
prohibit them in
your own ccTLDs and, with the document mentioned
above as a
tool, recommend to ICANN and directly to other
domain
administrators (top-level and otherwise) that these codes
not
be registered.  That advice will, I fear inevitably,
be
ignored in some places.  But, if the explanation of
the
consumer risks is clear enough, governments, regulators,
and
injured parties will have solid grounds for holding
registrars
who promote the use of such names responsible for any
problems
they cause.

              

Once the IDN become a standard without adopt CDN requirements or other
script
requirements

you'v mentioned, the serious problem would have occored. User can not
wait
during the gap 

untill the another, later, better,complete solution, such as non-DNS
solutions.

              

We have to separate  the problem and solution is proper to deal
with in DNS
level or not. Some

requirements are belonging to DNS level must still solved in the DNS
level.
Some requirements

are beloning to non-DNS level should develop non-DNS solutions.

              

As you mentioned above "identifiers" -- character strings used in narrow
contexts  is belonging

to DNS level. Then "user-visible names" is belonging to non-DNS
level.

              

As for TC/SC 1 to 1 mapping, fit in with the definition of
 "identifiers"
-- character strings used in

 narrow contexts. So it MUST solve in DNS level.

              

And move the other rest of complexity TC/SC mapping ( 1 to n, n to 1, n
to
n , context ) to the

upper Layer which is non-DNS solution.

              

              

                
(iii) Please continue to work with me and
with others to
develop non-DNS solutions for user-visible names that
do meet
your needs by accomodating matching that uses language
and
other information in ways that the DNS cannot.

                

Yes,  there are many complexity or user oriented requirements
should be developed
by 

non-DNS solutions. But, because it is non-DNS solution, so it
could  not
substitute DNS

resolving. Unless, close the DNS resolving and substitute by the non-DNS
solution.

                

                  
thanks and regards,
     john

                  

                  

Erin Chen

                  

                    

--On Friday, 01 February, 2002
18:27 +0800 Erin Chen
<erin@twnic.net.tw>
wrote:


                    

                      
-------------------------------------------------------------------------         Chinese Domain Name Consortium
(CDNC)
Declaration

--------------------------------------------------------------
--
---------

Based on current status of Internationalized Domain
Name, CDNC
makes  following declaration:

1. Currently, IETF
IDN WG begins Last Call for the WG core
documents (IDNA, NAMEPREP,
STRINGPREP, and PUNYCODE).

But, the architecture of IDN defined
in above four documents
does not solve the traditional and simplified
Chinese
character variant problem. That will cause serious
delegation
problem in the application of  Chinese Domain Name.
This
technical flaw can't be compensated by  registration
policy;
it'll prevent Chinese Domain Name from being used widely.
All
the future Internet applications based on Chinese Domain
Name
hierarchy will fail and ultimately Chinese Domain Name
t
echnology will result in failure.

2. Under the commercial and
social pressure, IETF IDN WG
issues Last  Call hastily without
presenting a proper Chinese
Domain Name technical solution. It will
be detrimental to the
ethnic-Chinese Internet community.

3.
IETF IDN WG does not solve Chinese Domain Name technical
problem,
but it is IETF IDN WG's responsibility to sincerely
consider the
consequences from adopting these drafts. Under
the current condition,
if IETF approves these IDN drafts,
registrars will open Chinese
Domain  Name registration without
considering the requirement of
Chinese Domain  Name and
Chinese Domain Name will fall into
confusion. This will damage 
Chinese Internet community seriously.


4. IDN would be flawed by not adopting CDN
requirements.

Chinese Domain Name Consortium 
CDNC Founding
members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC
Co-chair of CDNC: Qian
Hualin, Professor
Co-chair of CDNC: Shian
-Shyong Tseng,
Professor
2002.2.1
-----------------------------------------------
---------------
-------------






 

                      

                      


                      

                      

                      
                      

--------------050900070403070603010302--






From owner-idn@ops.ietf.org  Mon Feb  4 23:53: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 XAA14459
	for ; Mon, 4 Feb 2002 23:53:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XxW7-000Ko3-00
	for idn-data@psg.com; Mon, 04 Feb 2002 20:47:39 -0800
Date: Mon, 04 Feb 2002 14:43:23 -0800
To: Erin Chen 
From: Dave Crocker 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Cc: IESG , IAB , IETF.IDN.WG
Message-Id: 


In-Reply-To: <3C5F0B2C.10905@twnic.net.tw>
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Note: header field too long; To & Cc field have been snapped - JS]

At 06:29 AM 2/5/2002 +0800, Erin Chen wrote:
> > There are many things the IDN specifications do not do. Rather, the
> > specifications focus on solving satisfying only the requirement they
> > are supposed to satisfy.
>
>Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of
IDN
>WG and will be dropped. And we has submit a Requirements of Chinese
Domain
>Name draft.

no.  I mean that it is only the goal of the IDN working group to extend
the
range of characters valid for domain names.  It is NOT the goal of the
working group to solve language problems.  TC/SC is a language problem.


>I understand the IDN WG has discussed for a long time. But if the
>Unicode sets is still not well
>defined as you said. Why IDN refer to a unwell defined Unicode sets?

1.  If you wish to repair the Unicode definition, then the proper venue
for
discussions in the Unicode forum.  At any rate, the IETF is clearly not
the
venue for trying to make modifications to Unicode.

2.  Unicode was chosen  by the working group because it is the best
available specification for the working group's goal.  The choice was
considered extensively quite some time ago.  I hope that you are not
asking
the question because you are unaware of that history.


>If TC/SC equivalence could not be adopt by IDN, once IDN become
standard
>the serious expected delegation problem will occur. That means the user
>could not
>get the consistent resolving by DNS. DNS become untrust.

You are making a technical assessment about the DNS.  Your assessment is
that it will provide inconsistent resolution of references.

Your assessment is quite simply wrong.  The IDN effort will not alter
the
stability or correctness of DNS resolutions at all.


> > The purpose of IDN is to permit use of an increased range of
> > characters in domain name, beyond the current limit of ASCII. It is
> > not the goal of the working group to invent character set
conventions
> > such as equivalence between different sets.
>
>I suggest we have to measure if we omit some requirement such as
>equivalence between some variants like TC/SC, then what kind of serious
>problem would be caused. And to review the original goal of IDN you
>expressed is still proper or not.

Yes, it is clear that that is what some of you wish.  However it is
equally
clear that a) there is no ready technical solution to the problem you
seek
to solve, and b) the problem you are trying to solve is beyond the scope
of
this working group.

To repeat:  It will be good and useful to solve the problem of character
set equivalences.  However that problem is not part of the scope for
this
working group.


> > It will be wonderful when equivalence between sets is achieved.
> > However it is not the charter of IDN to solve basic issues of
> > character set equivalence and it is not reasonable to delay the
> > utility of the character set enhancement specified by IDN, in the
hope
> > that some day the question of character set equivalence is achieved.
>
>We made the CDNC declaration is not intend to hinder the progress of
>IDN.

When someone responds to an IETF working group Last Call with a claim
that
a specification is deficient, the clear and primary goal of that
response
is to delay the issuance of that specification.

IETF participants who are primarily interested in making progress pursue
that interest by creating and promosting viable specifications and
gaining
support for those specifications.  You are encouraged to follow that
path,
rather than to pursue delay of the current specification.


>  If the IDN still could not consider or find a proper solution for CDN
> requirement,
>we rather the IDN switch off CDN temperarily till the proper solution
>comes out to prevent
>the expectedserious problem occur.

The suggestion that use of a particular subset of Unicode be temporarily
restricted suggests a failure to understand basic issues of Internet
protocol design.  Such special case handling is not viable in the scale
of
global Internet community.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464






From owner-idn@ops.ietf.org  Tue Feb  5 00:04: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 AAA14579
	for ; Tue, 5 Feb 2002 00:04:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xxe5-000LDE-00
	for idn-data@psg.com; Mon, 04 Feb 2002 20:55:53 -0800
From: Erin Chen 
X-Accept-Language: en-us
MIME-Version: 1.0
To: Dave Crocker 
CC: IESG , IAB , IETF IDN WG
  
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1>
Content-Type: text/plain; charset=x-windows-949
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Date: Mon, 04 Feb 2002 20:55:53 -0800
Content-Transfer-Encoding: 7bit

[Note: header field too long; To & Cc have been snapped - JS]

Dear Dave Crocker,

Dave Crocker wrote:

> At 06:27 PM 2/1/2002 +0800, Erin Chen wrote:
>
>> But, the architecture of IDN defined in above four documents does not
>> solve the traditional and simplified Chinese character variant
problem.
>
>
> There are many things the IDN specifications do not do. Rather, the
> specifications focus on solving satisfying only the requirement they
> are supposed to satisfy.

Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of IDN
WG and will
be dropped. And we has submit a Requirements of Chinese Domain Name
draft.

> Solution of TC/SC is one example of equivalence among Unicode sets.
> Indeed, IDN does not attempt to specify such equivalences. Equivalence
> among separate Unicode sets is essentially an open technical topic for
> which there are no accepted practises.
>
> Still, this topic has been discussed, debated and explained
> extensively within the IDN working group.

I understand the IDN WG has discussed for a long time. But if the
Unicode sets is still not well
defined as you said. Why IDN refer to a unwell defined Unicode sets?
If TC/SC equivalence could not be adopt by IDN, once IDN become standard
the serious
expected delegation problem will occur. That means the user could not
get the consistent
resolving by DNS. DNS become untrust.

> The purpose of IDN is to permit use of an increased range of
> characters in domain name, beyond the current limit of ASCII. It is
> not the goal of the working group to invent character set conventions
> such as equivalence between different sets.

I suggest we have to measure if we omit some requirement such as
equivalence between some
variants like TC/SC, then what kind of serious problem would be caused.
And to review the
original goal of IDN you expressed is still proper or not.

> It will be wonderful when equivalence between sets is achieved.
> However it is not the charter of IDN to solve basic issues of
> character set equivalence and it is not reasonable to delay the
> utility of the character set enhancement specified by IDN, in the hope
> that some day the question of character set equivalence is achieved.

We made the CDNC declaration is not intend to hinder the progress of
IDN. If the IDN
still could not consider or find a proper solution for CDN requirement,
we rather the IDN
switch off CDN temperarily till the proper solution comes out to prevent
the expected
serious problem occur.

> Contrary to the claim that the working group is moving too quickly, my
> own guess is that it has been a major source of delay for the working
> group for at least 6 months. Perhaps much longer.
>
> d/

> ----------
> Dave Crocker 
> Brandenburg InternetWorking 
> tel +1.408.246.8253; fax +1.408.273.6464

Erin Chen

>








From owner-idn@ops.ietf.org  Tue Feb  5 00:05: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 AAA14591
	for ; Tue, 5 Feb 2002 00:05:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xxdl-000LCY-00
	for idn-data@psg.com; Mon, 04 Feb 2002 20:55:33 -0800
Date: Mon, 04 Feb 2002 14:43:23 -0800
To: Erin Chen 
From: Dave Crocker 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Cc: IESG , IAB , IETF IDN WG
   
In-Reply-To: <3C5F0B2C.10905@twnic.net.tw>
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

[Note: header field too long; To & Cc field have been snapped - JS]

At 06:29 AM 2/5/2002 +0800, Erin Chen wrote:
> > There are many things the IDN specifications do not do. Rather, the
> > specifications focus on solving satisfying only the requirement they
> > are supposed to satisfy.
>
>Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of
IDN
>WG and will be dropped. And we has submit a Requirements of Chinese
Domain
>Name draft.

no.  I mean that it is only the goal of the IDN working group to extend
the
range of characters valid for domain names.  It is NOT the goal of the
working group to solve language problems.  TC/SC is a language problem.


>I understand the IDN WG has discussed for a long time. But if the
>Unicode sets is still not well
>defined as you said. Why IDN refer to a unwell defined Unicode sets?

1.  If you wish to repair the Unicode definition, then the proper venue
for
discussions in the Unicode forum.  At any rate, the IETF is clearly not
the
venue for trying to make modifications to Unicode.

2.  Unicode was chosen  by the working group because it is the best
available specification for the working group's goal.  The choice was
considered extensively quite some time ago.  I hope that you are not
asking
the question because you are unaware of that history.


>If TC/SC equivalence could not be adopt by IDN, once IDN become
standard
>the serious expected delegation problem will occur. That means the user
>could not
>get the consistent resolving by DNS. DNS become untrust.

You are making a technical assessment about the DNS.  Your assessment is
that it will provide inconsistent resolution of references.

Your assessment is quite simply wrong.  The IDN effort will not alter
the
stability or correctness of DNS resolutions at all.


> > The purpose of IDN is to permit use of an increased range of
> > characters in domain name, beyond the current limit of ASCII. It is
> > not the goal of the working group to invent character set
conventions
> > such as equivalence between different sets.
>
>I suggest we have to measure if we omit some requirement such as
>equivalence between some variants like TC/SC, then what kind of serious
>problem would be caused. And to review the original goal of IDN you
>expressed is still proper or not.

Yes, it is clear that that is what some of you wish.  However it is
equally
clear that a) there is no ready technical solution to the problem you
seek
to solve, and b) the problem you are trying to solve is beyond the scope
of
this working group.

To repeat:  It will be good and useful to solve the problem of character
set equivalences.  However that problem is not part of the scope for
this
working group.


> > It will be wonderful when equivalence between sets is achieved.
> > However it is not the charter of IDN to solve basic issues of
> > character set equivalence and it is not reasonable to delay the
> > utility of the character set enhancement specified by IDN, in the
hope
> > that some day the question of character set equivalence is achieved.
>
>We made the CDNC declaration is not intend to hinder the progress of
>IDN.

When someone responds to an IETF working group Last Call with a claim
that
a specification is deficient, the clear and primary goal of that
response
is to delay the issuance of that specification.

IETF participants who are primarily interested in making progress pursue
that interest by creating and promosting viable specifications and
gaining
support for those specifications.  You are encouraged to follow that
path,
rather than to pursue delay of the current specification.


>  If the IDN still could not consider or find a proper solution for CDN
> requirement,
>we rather the IDN switch off CDN temperarily till the proper solution
>comes out to prevent
>the expectedserious problem occur.

The suggestion that use of a particular subset of Unicode be temporarily
restricted suggests a failure to understand basic issues of Internet
protocol design.  Such special case handling is not viable in the scale
of
global Internet community.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464







From owner-idn@ops.ietf.org  Tue Feb  5 00:05: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 AAA14621
	for ; Tue, 5 Feb 2002 00:05:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xxe1-000LD5-00
	for idn-data@psg.com; Mon, 04 Feb 2002 20:55:49 -0800
Date: Tue, 05 Feb 2002 06:43:42 +0800
From: Erin Chen 
MIME-Version: 1.0
To: John C Klensin 
CC: IESG , IAB , IETF IDN WG
   
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <3C5A6DAE.9040905@twnic.net.tw>
Message-Id: 

<178475239.1012596275@localhost>
Content-Type: multipart/alternative;
 boundary="------------050900070403070603010302"
Sender: owner-idn@ops.ietf.org
Precedence: bulk


--------------050900070403070603010302
Content-Type: text/plain; charset=Big5
Content-Transfer-Encoding: 7bit

[Note: header field too long; To & Cc field have been snapped - JS]

Dear John,

John C Klensin wrote:

>Erin,
>
>Let me follow up Vint's note with some thoughts of my own,
>with the understanding that they are mine personally and may
>not reflect positions I would feel obligated to take as
>technical advisor to the IDN WG or as a member of the IAB; the
>WG or the IAB might well disagree with what I'm about to say.
>
I hope every one would try to rethinking about some contention.

>I believe it has been fairly well demonstrated by this point
>that there are _many_ problems that the protocols specified in
>the IDN WG core documents will not solve.  Many of these
>problems involve Chinese Domain Names, many others do not.  At
>the root of most of both types of problems lies a distinction
>between "identifiers" -- character strings used in narrow
>contexts and to which many restrictive rules can be applied--
>and "user-visible names".  The latter must obey the rules of
>the languages in which they are constructed and written.  If
>they do not, confusion and astonishment results.
>
I agree with you. Some requirement MUST be solved in Layer1 if it is
essentially define
identifiers. But some requirement SHOULD be solve in upper Layer if it
is not essentially
define identifiers.

>But, while some issues can be addressed with sufficient
>ingenuity, the DNS cannot, in general, solve user-visible name
>problems within the current design and basic DNS protocols.
>Again, this raises especially difficult problems for Chinese
>names, but there are problems of one sort or another with most
>languages.  The solutions for those user-visible name
>problems, as we discussed in Minneapolis, lie in non-DNS
>mechanisms, protocols, and database, not in the DNS or the IDN
>WG's effort to fit some extra characters into the DNS.
>
It's nice to have chance to discuss with you in SLC(I know you mean
SLC).

>As we look at the IDN WG's efforts, it is important to
>remember, first, that Unicode (ISO 10646) is a tool.  It is a
>tool that is better suited to some purposes than to others and
>it is one that was designed in the context of very complex
>tradeoffs.   The WG chose to use that tool, largely because,
>given _their_ constraints, there were no plausible
>alternatives.
>
I agree with the IDN WG to use the well-defined part of Unicode. But
about equivalent TC/SC
is unwell-defined in the Unicode and it is also not the goal of Unicode
Consortium.

How can IDN stilll refer to the unwell-defined parts?

>Similarly, we should view the IDN WG's outputs --if, indeed,
>IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out to be the
>outputs-- to be tools.  They are not a perfect tool.  It is
>easy to find problems they don't solve, and problems with
>characters that have equivalent meanings and different
>appearances and code points (as in TC<->SC mapping) and
>characters that have similar or identical appearances but
>belong to different scripts and have different code points (as
>in matching characters in Latin, Greek, and Cyrillic scripts)
>are high on that list of unsolved problems.  But, again, they
>are a tool, and, while it quite drastic, I suggest that there
>is a registration-based solution if that tool is
>inappropriate.
>
Dear John, I'm afraid only the registgration-based solution still could
not overcome.
Even if there is a proper and well-defined registration policy(including
how to manage
the DNS zone file) but lack of corresponding technical solution to do
the police, the zone file
manager still can decide obey the policy or not. That will still cause
inconsistent DNS resolving.
As a identifier, the DNS would not be trusted.

>The IDN WG also has the constraints, ultimately imposed by the
>DNS architecture, that it cannot make a decision that solves a
>problem for Greek at the expense of Cyrillic, nor can it make
>one that solves a Chinese problem at the expense of making
>Japanese or Korean unusable.  Perhaps the more subtle matching
>and
>equivalence problems are sufficient to make the whole notion
>unusable, at least for user-visible names.  While I suspect
>that might be true, the argument has not been convincingly
>made.
>
>This suggests some actions you might consider:
>
>(i) Your colleagues argued quite persuasively in Minneapolis
>that the difficulties imposed by the IDN WG approach on
>Chinese-Language Domain names would cause serious consumer
>confusion and disruption and could be expected to provide an
>unreasonably good opportunity for fraudulent behavior.  I
>believe that I understand that argument, but many of the
>people to whom your statement was addressed probably do not.
>I would strongly suggest that you try to produce a document
>that explains the problems, in a tutorial style, and at a
>level adequate to educate someone with no knowledge of Chinese
>and, perhaps no working knowledge of any script other than his
>or her own.
>
Yes, it is important to let others understand the problems.

>(ii) If registrations of CDNs are dangerous, prohibit them in
>your own ccTLDs and, with the document mentioned above as a
>tool, recommend to ICANN and directly to other domain
>administrators (top-level and otherwise) that these codes not
>be registered.  That advice will, I fear inevitably, be
>ignored in some places.  But, if the explanation of the
>consumer risks is clear enough, governments, regulators, and
>injured parties will have solid grounds for holding registrars
>who promote the use of such names responsible for any problems
>they cause.
>
Once the IDN become a standard without adopt CDN requirements or other
script requirements
you'v mentioned, the serious problem would have occored. User can not
wait during the gap
untill the another, later, better,complete solution, such as non-DNS
solutions.

We have to separate the problem and solution is proper to deal with in
DNS level or not. Some
requirements are belonging to DNS level must still solved in the DNS
level. Some requirements
are beloning to non-DNS level should develop non-DNS solutions.

As you mentioned above "identifiers" -- character strings used in narrow
contexts is belonging
to DNS level. Then "user-visible names" is belonging to non-DNS level.

As for TC/SC 1 to 1 mapping, fit in with the definition of "identifiers"
-- character strings used in
narrow contexts. So it MUST solve in DNS level.

And move the other rest of complexity TC/SC mapping ( 1 to n, n to 1, n
to n , context ) to the
upper Layer which is non-DNS solution.

>(iii) Please continue to work with me and with others to
>develop non-DNS solutions for user-visible names that do meet
>your needs by accomodating matching that uses language and
>other information in ways that the DNS cannot.
>
Yes, there are many complexity or user oriented requirements should be
developed by
non-DNS solutions. But, because it is non-DNS solution, so it could not
substitute DNS
resolving. Unless, close the DNS resolving and substitute by the non-DNS
solution.

>thanks and regards,
>     john
>

Erin Chen

>
>--On Friday, 01 February, 2002 18:27 +0800 Erin Chen
> wrote:
>
>>--------------------------------------------------------------
>>-----------         Chinese Domain Name Consortium (CDNC)
>>Declaration
>>--------------------------------------------------------------
>>-----------
>>
>>Based on current status of Internationalized Domain Name, CDNC
>>makes  following declaration:
>>
>>1. Currently, IETF IDN WG begins Last Call for the WG core
>>documents (IDNA, NAMEPREP, STRINGPREP, and PUNYCODE).
>>
>>But, the architecture of IDN defined in above four documents
>>does not solve the traditional and simplified Chinese
>>character variant problem. That will cause serious delegation
>>problem in the application of  Chinese Domain Name. This
>>technical flaw can't be compensated by  registration policy;
>>it'll prevent Chinese Domain Name from being used widely. All
>>the future Internet applications based on Chinese Domain  Name
>>hierarchy will fail and ultimately Chinese Domain Name
>>technology will result in failure.
>>
>>2. Under the commercial and social pressure, IETF IDN WG
>>issues Last  Call hastily without presenting a proper Chinese
>>Domain Name technical solution. It will be detrimental to the
>>ethnic-Chinese Internet community.
>>
>>3. IETF IDN WG does not solve Chinese Domain Name technical
>>problem,  but it is IETF IDN WG's responsibility to sincerely
>>consider the  consequences from adopting these drafts. Under
>>the current condition,  if IETF approves these IDN drafts,
>>registrars will open Chinese Domain  Name registration without
>>considering the requirement of Chinese Domain  Name and
>>Chinese Domain Name will fall into confusion. This will damage
>>Chinese Internet community seriously.
>>
>>4. IDN would be flawed by not adopting CDN requirements.
>>
>>Chinese Domain Name Consortium
>>CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC
>>Co-chair of CDNC: Qian Hualin, Professor
>>Co-chair of CDNC: Shian-Shyong Tseng, Professor
>>2002.2.1
>>--------------------------------------------------------------
>>-------------
>>
>>
>>
>>
>>
>>
>>
>>
>


--------------050900070403070603010302
Content-Type: text/html; charset=Big5
Content-Transfer-Encoding: 7bit





Dear John,



John C Klensin wrote:



  
Erin,

Let me follow up Vint's note with some
thoughts of my own,
with the understanding that they are mine
personally and may
not reflect positions I would feel obligated to
take as
technical advisor to the IDN WG or as a member of the IAB;
the
WG or the IAB might well disagree with what I'm about to
say.

  

I hope every one would try to rethinking about some contention.

  

    
I believe it has been fairly well demonstrated by this
point
that there are _many_ problems that the protocols specified
in
the IDN WG core documents will not solve.  Many of
these
problems involve Chinese Domain Names, many others do not.
At
the root of most of both types of problems lies a
distinction
between "identifiers" -- character strings used in
narrow
contexts and to which many restrictive rules can be
applied--
and "user-visible names".  The latter must obey the rules
of
the languages in which they are constructed and written.
If
they do not, confusion and astonishment results.

    

I agree with you. Some requirement MUST be solved in Layer1 if it is
essentially
define

identifiers. But some requirement SHOULD be solve in upper Layer if it
is
not essentially 

define identifiers.

    

      
But, while some issues can be addressed with
sufficient
ingenuity, the DNS cannot, in general, solve user-visible
name
problems within the current design and basic DNS
protocols.
Again, this raises especially difficult problems for
Chinese
names, but there are problems of one sort or another with
most
languages.  The solutions for those user-visible
name
problems, as we discussed in Minneapolis, lie in
non-DNS
mechanisms, protocols, and database, not in the DNS or the
IDN
WG's effort to fit some extra characters into the DNS.

      

It's nice to have chance to discuss with you in SLC(I know you mean
SLC).
      

      

        
As we look at the IDN WG's efforts, it is important
to
remember, first, that Unicode (ISO 10646) is a tool.  It is
a
tool that is better suited to some purposes than to others
and
it is one that was designed in the context of very
complex
tradeoffs.   The WG chose to use that tool, largely
because,
given _their_ constraints, there were no
plausible
alternatives.

        

I agree with the IDN WG to use the well-defined part of Unicode. But
about
equivalent TC/SC

is unwell-defined in the Unicode and it is also not the goal of Unicode
Consortium.

        

How can IDN stilll refer to the unwell-defined  parts?

        

          
Similarly, we should view the IDN WG's
outputs --if, indeed,
IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out
to be the
outputs-- to be tools.  They are not a perfect tool.  It
is
easy to find problems they don't solve, and problems
with
characters that have equivalent meanings and
different
appearances and code points (as in TC<->SC mapping)
and
characters that have similar or identical appearances
but
belong to different scripts and have different code points
(as
in matching characters in Latin, Greek, and Cyrillic
scripts)
are high on that list of unsolved problems.  But, again,
they
are a tool, and, while it quite drastic, I suggest that
there
is a registration-based solution if that tool
is
inappropriate.

          

Dear John, I'm afraid only the registgration-based solution still could
not
overcome. 

Even if there is a proper and well-defined registration policy(including
how to manage 

the DNS zone file) but lack of corresponding technical solution to do
the
police, the zone file 

manager still can decide obey the policy or not. That will still cause
inconsistent
DNS resolving.

As a identifier, the DNS would not be trusted.

          

          

            
The IDN WG also has the constraints, ultimately
imposed by the
DNS architecture, that it cannot make a decision that
solves a
problem for Greek at the expense of Cyrillic, nor can it
make
one that solves a Chinese problem at the expense of
making
Japanese or Korean unusable.  Perhaps the more subtle
matching
and
equivalence problems are sufficient to make the whole
notion
unusable, at least for user-visible names.  While I
suspect
that might be true, the argument has not been
convincingly
made.

This suggests some actions you might
consider:

(i) Your colleagues argued quite persuasively in
Minneapolis
that the difficulties imposed by the IDN WG approach
on
Chinese-Language Domain names would cause serious
consumer
confusion and disruption and could be expected to provide
an
unreasonably good opportunity for fraudulent behavior.
I
believe that I understand that argument, but many of the
people
 to whom your statement was addressed probably do not.
I would
strongly suggest that you try to produce a document
that explains the
problems, in a tutorial style, and at a
level adequate to educate
someone with no knowledge of Chinese
and, perhaps no working
knowledge of any script other than his
or her own.

            

Yes, it is important to let others understand the problems. 

            

              
(ii) If registrations of CDNs are dangerous,
prohibit them in
your own ccTLDs and, with the document mentioned
above as a
tool, recommend to ICANN and directly to other
domain
administrators (top-level and otherwise) that these codes
not
be registered.  That advice will, I fear inevitably,
be
ignored in some places.  But, if the explanation of
the
consumer risks is clear enough, governments, regulators,
and
injured parties will have solid grounds for holding
registrars
who promote the use of such names responsible for any
problems
they cause.

              

Once the IDN become a standard without adopt CDN requirements or other
script
requirements

you'v mentioned, the serious problem would have occored. User can not
wait
during the gap 

untill the another, later, better,complete solution, such as non-DNS
solutions.

              

We have to separate  the problem and solution is proper to deal
with in DNS
level or not. Some

requirements are belonging to DNS level must still solved in the DNS
level.
Some requirements

are beloning to non-DNS level should develop non-DNS solutions.

              

As you mentioned above "identifiers" -- character strings used in narrow
contexts  is belonging

to DNS level. Then "user-visible names" is belonging to non-DNS
level.

              

As for TC/SC 1 to 1 mapping, fit in with the definition of
 "identifiers"
-- character strings used in

 narrow contexts. So it MUST solve in DNS level.

              

And move the other rest of complexity TC/SC mapping ( 1 to n, n to 1, n
to
n , context ) to the

upper Layer which is non-DNS solution.

              

              

                
(iii) Please continue to work with me and
with others to
develop non-DNS solutions for user-visible names that
do meet
your needs by accomodating matching that uses language
and
other information in ways that the DNS cannot.

                

Yes,  there are many complexity or user oriented requirements
should be developed
by 

non-DNS solutions. But, because it is non-DNS solution, so it
could  not
substitute DNS

resolving. Unless, close the DNS resolving and substitute by the non-DNS
solution.

                

                  
thanks and regards,
     john

                  

                  

Erin Chen

                  

                    

--On Friday, 01 February, 2002
18:27 +0800 Erin Chen
<erin@twnic.net.tw>
wrote:


                    

                      
-------------------------------------------------------------------------         Chinese Domain Name Consortium
(CDNC)
Declaration

--------------------------------------------------------------
--
---------

Based on current status of Internationalized Domain
Name, CDNC
makes  following declaration:

1. Currently, IETF
IDN WG begins Last Call for the WG core
documents (IDNA, NAMEPREP,
STRINGPREP, and PUNYCODE).

But, the architecture of IDN defined
in above four documents
does not solve the traditional and simplified
Chinese
character variant problem. That will cause serious
delegation
problem in the application of  Chinese Domain Name.
This
technical flaw can't be compensated by  registration
policy;
it'll prevent Chinese Domain Name from being used widely.
All
the future Internet applications based on Chinese Domain
Name
hierarchy will fail and ultimately Chinese Domain Name
t
echnology will result in failure.

2. Under the commercial and
social pressure, IETF IDN WG
issues Last  Call hastily without
presenting a proper Chinese
Domain Name technical solution. It will
be detrimental to the
ethnic-Chinese Internet community.

3.
IETF IDN WG does not solve Chinese Domain Name technical
problem,
but it is IETF IDN WG's responsibility to sincerely
consider the
consequences from adopting these drafts. Under
the current condition,
if IETF approves these IDN drafts,
registrars will open Chinese
Domain  Name registration without
considering the requirement of
Chinese Domain  Name and
Chinese Domain Name will fall into
confusion. This will damage 
Chinese Internet community seriously.


4. IDN would be flawed by not adopting CDN
requirements.

Chinese Domain Name Consortium 
CDNC Founding
members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC
Co-chair of CDNC: Qian
Hualin, Professor
Co-chair of CDNC: Shian
-Shyong Tseng,
Professor
2002.2.1
-----------------------------------------------
---------------
-------------






 

                      

                      


                      

                      

                      
                      

--------------050900070403070603010302--







From owner-idn@ops.ietf.org  Tue Feb  5 00:15: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 AAA14714
	for ; Tue, 5 Feb 2002 00:15:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XxpE-000LdK-00
	for idn-data@psg.com; Mon, 04 Feb 2002 21:07:24 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16XxpD-000Ld8-00
	for idn@ops.ietf.org; Mon, 04 Feb 2002 21:07:23 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id MAA27195;
	Tue, 5 Feb 2002 12:58:19 +0800
From: "Kenny Huang" 
To: "James Seng/Personal" ,
        "Erin Chen" , "Scott Bradner" 
Cc: , ,
        , , ,
        , ,
        , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , ,
        , 
Subject: RE: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Date: Tue, 5 Feb 2002 13:09:44 +0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <03e601c1ad7a$5dd2b570$0d01000a@jamessonyvaio>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA14714

Some clarifications:
 
> The problem of Traditional Chinese & Simplified Chinese cannot be
> expressed as a bicameral (upper/lower case) problem. To say it is
> similar to "A" and "a" is at best misleading. TC/SC is not a simple 1 to
> 1 mapping.

1-1 TC/SC mapping is exact the same as "A" to "a" mapping from 
computing algorithm point of view.  Your question should point to the 
source of table, not to the computational algorithm.

CDN requirement has been proposed. Read the CDN requirement, 
CDN is not Chinese literature. It is an identifier.  Sophisticated language 
issue should be discussed in the upper layers.
 
> Some subset of TC/SC problem can be solved using using this method,
> however unreliable it is. But such solution have to take into
> consideration of conflicting languages (such as Japanese & Korean) and
> thus striping it down to a even smaller subset. In a JET meeting whereby
> we do this investigation, this would bring the simple 2400+ TC/SC pairs,
> down to around 300+ TC/SC pairs. (And note, (U+81FA, U+53F0) pairs, an
> commonly used characters since it represent "tai" in "taiwan" is not
> part of the sub-subset). One would therefore question the usefulness of
> such partial solution.

I was chairing the JET meeting. The investigation is about 
1986 pairs (2237 pairs - 251 pairs which overlapping with Japanese
character). 


> And when there is only one obvious solution, it does not mean the
> obvious solution is the right one. As Dave points out, "When all you
> have is a hammer, everything look like a nail".
> 
> The IDN WG is not absolute. It is a beginning of a journey to do I18N in
> IETF and the Internet, one that can bring the Internet closer to the
> world; OR it can be a end to any further attempts to do I18N in IETF.
> Neither is it the only forum whereby all solutions to I18N is to be
> conducted. Not all solutions are technical in nature, and even if it is,
> not all problems can be solve within IETF.
> -James Seng
 

Unfortunately, IDN deployment is not a reversible process if things 
went wrong. If you do think the obvious solution is not the right one,
then we'd better consider the consequences from adopting the solution.
Trying to do it halfway is worse than not doing it at all.  


Kenny Huang
Secretariat, JET




From owner-idn@ops.ietf.org  Tue Feb  5 00:43: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 AAA15101
	for ; Tue, 5 Feb 2002 00:43:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16XyEW-000MBG-00
	for idn-data@psg.com; Mon, 04 Feb 2002 21:33:32 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16XyEV-000MB3-00
	for idn@ops.ietf.org; Mon, 04 Feb 2002 21:33:31 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16XyEU-00046L-00
	for ; Mon, 04 Feb 2002 21:33:30 -0800
Date: Tue, 5 Feb 2002 05:33:30 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] Re: peanut gallery
Message-ID: <20020205053329.GA12391@nicemice.net>
Reply-To: IETF idn working group 
References:  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <003c01c1a873$49945d90$08d8ea0c@c1340594a>  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003c01c1a873$49945d90$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

I wrote:

> Here's a more precise version of the proposal:  Prohibit a Han code
> point iff it has a kTraditionalVariant and has only "G" sources
> (China/Singapore).  Would that do what I intend?

"Mark Davis (jtcsv)"  replied:

> No, that wouldn't do as you intend. The kTraditionalVariant is not a
> normative field... while it has improved over time, I would not put
> any real weight on it without a thorough review.

Okay then, how about this:  Prohibit a Han code point iff it has only
"G" sources (China/Singapore).

That might prohibit a few characters unnecessarily, but it will make
sure that Taiwan, Japan, and Korea are able to use all their characters,
and will leave the maximum flexibility for China & Singapore to define
how to fold the remaining characters if they decide that's what they
want to do.

I wouldn't recommend this course, but if most of the Chinese community
wanted to do this, I don't see why the rest of us should object.

AMC



From owner-idn@ops.ietf.org  Tue Feb  5 01:32: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 BAA15546
	for ; Tue, 5 Feb 2002 01:32:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xz01-000MuA-00
	for idn-data@psg.com; Mon, 04 Feb 2002 22:22:37 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Xyzz-000Mu4-00
	for idn@ops.ietf.org; Mon, 04 Feb 2002 22:22:36 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g156N1l01466
	for idn@ops.ietf.org; Tue, 5 Feb 2002 15:23:01 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Tue, 5 Feb 2002 15:23:01 +0900
From: YangWoo Ko 
To: idn@ops.ietf.org
Subject: Re: [idn] Fw: Cyrillics - Latin
Message-ID: <20020205062301.GB1097@spsoft.co.kr>
References: <016e01c1ad95$427a53d0$08d8ea0c@c1340594a> <83629194.1012820974@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <83629194.1012820974@localhost>
User-Agent: Mutt/1.3.27i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Mon, Feb 04, 2002 at 11:09:34AM -0500, John C Klensin wrote:
> --On Monday, 04 February, 2002 08:01 -0800 Mark Davis
> > On the other hand, I think it would be quite useful--as I
> > suggested some time ago--to add some text that strongly
> > recommended that browsers and similar programs that display
> > URLs indicate with some sort of visual mechanism where they
> > contains mixed scripts, e.g. highlight those characters not in
> > the script of the majority of the characters (with a different
> > color or background).
> 
> I believe that it would be a significant service to the
> community --I would suggest that it is nearly necessary-- to
> write strong "security considerations" sections for these
> documents, or separate documents, that explicitly identify the
> character and range of as many of these problems as are
> well-understood.  I think that incorporating suggestions like
> Mark's into such explanations would be very helpful.

Dear John C Klensin and others,

Even though I doubt whether peoples out there may take "security
considerations" seriously enough to minimize problems, this is
one of what we MUST do.

I want to elaborate this idea a little bit. The security consideration 
section should cover at least three areas;
* For IDNA implementers
* For zone administrators (especially gTLD registries)
* For end users

Some may disagree with second and/or third area, we should never
forget that all of those problems will arise from registration 
and use of domain name not from bad implementation.

Regards

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Tue Feb  5 02:26: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 CAA24638
	for ; Tue, 5 Feb 2002 02:26:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Xzn3-000NhZ-00
	for idn-data@psg.com; Mon, 04 Feb 2002 23:13:17 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Xzn2-000NhT-00
	for idn@ops.ietf.org; Mon, 04 Feb 2002 23:13:16 -0800
Received: (qmail 24740 invoked by uid 1001); 5 Feb 2002 07:12:13 -0000
Date: 5 Feb 2002 07:12:13 -0000
Message-ID: <20020205071213.9725.qmail@cr.yp.to>
Mail-Followup-To: dhc@dcrocker.net,
  smb@research.att.com,
  Elisabeth.Porteneuve@cetp.ipsl.fr,
  Marc.Blanchet@viagenie.qc.ca,
  ajm@icann.org,
  erin@twnic.net.tw,
  fred@cisco.com,
  harald@alvestrand.no,
  htk@eecs.harvard.edu,
  iab@ISI.EDU,
  idn@ops.ietf.org,
  iesg@ietf.org,
  jet-member@nic.ad.jp,
  jseng@pobox.org.sg,
  klensin@jck.com,
  lynn@icann.org,
  mkatoh@mkatoh.net,
  mkatoh@wdc.fujitsu.com,
  mouhamet@next.sn,
  narten@us.ibm.com,
  nordmark@eng.sun.com,
  paf@cisco.com,
  phoffman@imc.org,
  qhhu@public.bta.net.cn,
  sharil@cmc.gov.my,
  shkyong@kgsm.kaist.ac.kr,
  vcerf@mci.net,
  alanysho@hkdnr.net.hk,
  christine.tsang@hkdnr.net.hk,
  deng@cnnic.net.cn,
  hlqian@cnnic.net.cn,
  hoho@iis.sinica.edu.tw,
  huangk@alum.sinica.edu,
  jasonho@umac.mo,
  lee@whale.cnnic.net.cn,
  mao@cnnic.net.cn,
  snw@twnic.net.tw,
  sstseng@twnic.net.tw,
  tsenglm@cc.ncu.edu.tw,
  whzhang@cnnnic.net.cn,
  wschen@twnic.net.tw,
  wuch@gate.sinica.edu.tw,
  yktham@umac.mo
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: Dave Crocker ,
        "Steven M. Bellovin" ,
        Elisabeth Porteneuve ,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw,
        fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu,
        iab@ISI.EDU, idn@ops.ietf.org, iesg@ietf.org, jet-member@nic.ad.jp,
        jseng@pobox.org.sg, klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net,
        mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com,
        nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org,
        qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk,
        deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw,
        huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn,
        mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw,
        tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,
        wuch@gate.sinica.edu.tw, yktham@umac.mo
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <20020204023529.79C5B7B4B@berkshire.research.att.com> <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> <20020204172414.13472.qmail@cr.yp.to> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dave Crocker writes:
> we have moved from technical specification into analysis of human behavior

Wake up, Dave: Human behavior is a central issue. The whole point of
IDNs is to improve the user interface. IDNs are supposed to allow
_humans_ to see non-ASCII glyphs in domain names.

You say that the IETF is exceedingly bad at this. No argument there.

> In point of fact, this "attack" has been performed, presumably with
> some success.

You admit that some users have been fooled by domain names with similar
appearance, yet you continue to advocate that we allow domain names with
_identical_ appearance, names that can't be visually distinguished even
by the most careful reader. Wow.

---Dan



From owner-idn@ops.ietf.org  Tue Feb  5 03:21: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 DAA25184
	for ; Tue, 5 Feb 2002 03:21:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y0kq-000Ohv-00
	for idn-data@psg.com; Tue, 05 Feb 2002 00:15:04 -0800
To: "D. J. Bernstein" 
From: Dave Crocker 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Cc: "Steven M. Bellovin" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Date: Tue, 05 Feb 2002 00:15:04 -0800

[Note: header field too long; To & Cc header snapped - JS]

At 07:12 AM 2/5/2002 +0000, D. J. Bernstein wrote:
>Dave Crocker writes:
> > we have moved from technical specification into analysis of human
behavior
>
>Wake up, Dave: Human behavior is a central issue. The whole point of
>IDNs is to improve the user interface. IDNs are supposed to allow
>_humans_ to see non-ASCII glyphs in domain names.

wake up, dan.  there is a difference between providing a richer set of
characters, versus trying to solve open research topics in language
equivalence or even script equivalence.


>You say that the IETF is exceedingly bad at this. No argument there.

but what the heck.  let's insist that the IETF solve this open research
topic anyhow, right?


> > In point of fact, this "attack" has been performed, presumably with
> > some success.
>
>You admit that some users have been fooled by domain names with similar
>appearance, yet you continue to advocate that we allow domain names
with
>_identical_ appearance, names that can't be visually distinguished even
>by the most careful reader.

Provide an existing specification for solving this problem outside the
domain name service.  Provide a basis for believing that it has gained
wide
acceptance.

Oh.  You can't do that.

wow.

d/

>  Wow.
>
>---Dan

----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464






From owner-idn@ops.ietf.org  Tue Feb  5 03:21: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 DAA25196
	for ; Tue, 5 Feb 2002 03:21:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y0jU-000OgO-00
	for idn-data@psg.com; Tue, 05 Feb 2002 00:13:40 -0800
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
To: "Paul Hoffman / IMC" 
Cc: idn@ops.ietf.org
From: yktham@umac.mo
Date: Tue, 5 Feb 2002 14:53:01 +0800
Message-ID: 
MIME-Version: 1.0
Content-type: multipart/mixed;

Boundary="0__=48256B57002469D18f9e8a93df938690918c48256B57002469D1"
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

--0__=48256B57002469D18f9e8a93df938690918c48256B57002469D1
Content-type: text/plain; charset=us-ascii


 (Embedded
 image moved   "Paul Hoffman / IMC" 
 to file:      2002/02/05 05:32 AM
 pic29426.pcx)








To:   idn@ops.ietf.org
cc:   Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca,
      ajm@icann.org, erin@twnic.net.tw, fred@cisco.com,
      harald@alvestrand.no, htk@eecs.harvard.edu, iab@ISI.EDU,
      iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg,
      lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com,
      mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com,
      paf@cisco.com, qhhu@public.bta.net.cn, sharil@cmc.gov.my,
      shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk,
      christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn,
hlqian@cnnic.net.cn,
      hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, JasonHo/UMAC@UMAC,
      lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw,
      sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw,
whzhang@cnnnic.net.cn,
      wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, YKTham/UMAC@UMAC
Subject:  Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration

MONIC, Macao Network Information Center, as a member of the Chinese
Domain
      Name Consortium, takes great exception to the following
denigration
      of its role as information technology facilitator in Macao:
Of course, CDNC members would like to maximize their
financial gain in registration

MONIC operates out of shoe-string budget allocation of the University of
Macau, and particpates in CDNC because we share the same heritage in
culture and language.  We are saddened to see the politicisation and
side-tracking of the process of empowering ethnic-Chinese to use the
Chinese language for Internet communication.

Tham, Yiu Kwok
MONIC/Computer Service Bureau, University of Macau

The message from CDNC says that the Traditional-Simplified problem
for Chinese users cannot be solved by registration policy. This is
not true, and many of the CDNC members who have come to IETF meetings
know that. Of course, CDNC members would like to maximize their
financial gain in registration, but the concern of the IETF is always
towards helping users. There is a huge different between "cannot be
solved" and "it will cost a small number of organizations a lot of
money".

Solving the Traditional-Simplified problem in the IDN protocol would
have given more uniform results for users. The intense discussions
over the past 18 months have shown that not only is it unlikely that
there will ever be an IETF-based solution, and it has also become
clear that a registration-based solution will likely give Chinese
users more sensible naming that anything than the IETF could
standardize. For example, in the IDN WG, the proposals from CDNC
members only addressed part of the Traditional-Simplified problem
(the 1:1 mapping), while the registration solution can address all of
the problem in a manner that will help Chinese users.

Due to the efforts of some CDNC members, the IETF is now well aware
of the "2^n" variant problem that is unique to the use of Han
characters in the Chinese language. Fortunately, using registration
guidelines will solve the problem. The only people seriously affected
by the size of DNS zones created by the "2^n" problem will be very
large, flat zones such as those managed by CDNC members, but they are
able to compensate for the size of zones with no changes to the DNS
protocols.

Of course, the character variant problem exists in many different
languages, not just in Chinese. Because of this, each registry or
zone that includes IDN names needs to make decisions about name
equivalence (and therefore multiple registrations) before they enter
any IDN names into their zone. Based on this input during Working
Group last call from the CDNC, it seems clear that we need to explain
these points more in the IDNA document.

--Paul Hoffman, Director
--Internet Mail Consortium



--0__=48256B57002469D18f9e8a93df938690918c48256B57002469D1
Content-type: application/octet-stream;
name="pic29426.pcx"
Content-Disposition: attachment; filename="pic29426.pcx"
Content-transfer-encoding: base64

CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA
AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT
zRPH
E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1
E9sT
zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG
1hPL
E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgIS
wgLD
BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgIT
wgIS
D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJ
E8QT
whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMP
whMP
xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfS
DMkD
wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMIT
E9YT
B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzL
A8IM
BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMG
BxIT
AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMG
xBLD
Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIO
Ag4C
DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4Q
wgLG
EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAO
EMIC
EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMC
A8UC
EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gT
BgfE
EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IM
B9oT
DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzC
AwwH
3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfe
EwYH
xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8US
AgMR
xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhEC
AwID
EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIH
BgcG
yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QT
whMT
xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8IT
yhMH
xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPD
ExPu
EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sT
zRPH
E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A
AAD/
/wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A
//8A
AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA
AP8A
//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA
/wAA
AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk
gICA
/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw
oKCk
gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw
//vw
oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA
psrw
//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA
wNzA
psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA
wMDA
wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA
AICA
wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA
gACA
AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAA
AACA
gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////

--0__=48256B57002469D18f9e8a93df938690918c48256B57002469D1--




-------


From owner-idn@ops.ietf.org  Tue Feb  5 05:41: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 FAA26755
	for ; Tue, 5 Feb 2002 05:41:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y2bX-0000No-00
	for idn-data@psg.com; Tue, 05 Feb 2002 02:13:35 -0800
Received: from [140.115.17.111] (helo=dove.cc.ncu.edu.tw)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Y2bV-0000NJ-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 02:13:34 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g15ACYU20582
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Tue, 5 Feb 2002 18:12:35 +0800 (CST)
Message-ID: <008001c1ae2d$41283540$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= 
To: "Erin Chen" , "Dave Crocker" 
Cc: "IESG" , "IAB" ,
        "IETF IDN WG" 
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1> 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Date: Tue, 5 Feb 2002 18:09:50 +0800
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 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

Dear Dave Crocker:
                  My  friend give me an example about  CJK UNICODE ,  It is
so ambiguous to me to deifferentiate which  one is a correct Chinese
characters or  not ?  In  our  hand writting , each pair are used and mixed
.

淸眞敎 U+6DF8 U+771E U+654E
淸眞教 U+6DF8 U+771E U+6559
淸真敎 U+6DF8 U+771F U+654E
淸真教 U+6DF8 U+771F U+6559
清眞敎 U+6E05 U+771E U+654E
清眞教 U+6E05 U+771E U+6559
清真敎 U+6E05 U+771F U+654E
清真教 U+6E05 U+771F U+6559

L.M.Tseng

----- Original Message -----
From: "Dave Crocker" 
To: "Erin Chen" 
Cc: "IESG" ; "IAB" ; "IETF IDN WG"

Sent: Tuesday, February 05, 2002 6:43 AM
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration


> [Note: header field too long; To & Cc field have been snapped - JS]
>
> At 06:29 AM 2/5/2002 +0800, Erin Chen wrote:
> > > There are many things the IDN specifications do not do. Rather, the
> > > specifications focus on solving satisfying only the requirement they
> > > are supposed to satisfy.
> >
> >Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of
> IDN
> >WG and will be dropped. And we has submit a Requirements of Chinese
> Domain
> >Name draft.
>
> no.  I mean that it is only the goal of the IDN working group to extend
> the
> range of characters valid for domain names.  It is NOT the goal of the
> working group to solve language problems.  TC/SC is a language problem.
>
>
> >I understand the IDN WG has discussed for a long time. But if the
> >Unicode sets is still not well
> >defined as you said. Why IDN refer to a unwell defined Unicode sets?
>
> 1.  If you wish to repair the Unicode definition, then the proper venue
> for
> discussions in the Unicode forum.  At any rate, the IETF is clearly not
> the
> venue for trying to make modifications to Unicode.
>
> 2.  Unicode was chosen  by the working group because it is the best
> available specification for the working group's goal.  The choice was
> considered extensively quite some time ago.  I hope that you are not
> asking
> the question because you are unaware of that history.
>
>
> >If TC/SC equivalence could not be adopt by IDN, once IDN become
> standard
> >the serious expected delegation problem will occur. That means the user
> >could not
> >get the consistent resolving by DNS. DNS become untrust.
>
> You are making a technical assessment about the DNS.  Your assessment is
> that it will provide inconsistent resolution of references.
>
> Your assessment is quite simply wrong.  The IDN effort will not alter
> the
> stability or correctness of DNS resolutions at all.
>
>
> > > The purpose of IDN is to permit use of an increased range of
> > > characters in domain name, beyond the current limit of ASCII. It is
> > > not the goal of the working group to invent character set
> conventions
> > > such as equivalence between different sets.
> >
> >I suggest we have to measure if we omit some requirement such as
> >equivalence between some variants like TC/SC, then what kind of serious
> >problem would be caused. And to review the original goal of IDN you
> >expressed is still proper or not.
>
> Yes, it is clear that that is what some of you wish.  However it is
> equally
> clear that a) there is no ready technical solution to the problem you
> seek
> to solve, and b) the problem you are trying to solve is beyond the scope
> of
> this working group.
>
> To repeat:  It will be good and useful to solve the problem of character
> set equivalences.  However that problem is not part of the scope for
> this
> working group.
>
>
> > > It will be wonderful when equivalence between sets is achieved.
> > > However it is not the charter of IDN to solve basic issues of
> > > character set equivalence and it is not reasonable to delay the
> > > utility of the character set enhancement specified by IDN, in the
> hope
> > > that some day the question of character set equivalence is achieved.
> >
> >We made the CDNC declaration is not intend to hinder the progress of
> >IDN.
>
> When someone responds to an IETF working group Last Call with a claim
> that
> a specification is deficient, the clear and primary goal of that
> response
> is to delay the issuance of that specification.
>
> IETF participants who are primarily interested in making progress pursue
> that interest by creating and promosting viable specifications and
> gaining
> support for those specifications.  You are encouraged to follow that
> path,
> rather than to pursue delay of the current specification.
>
>
> >  If the IDN still could not consider or find a proper solution for CDN
> > requirement,
> >we rather the IDN switch off CDN temperarily till the proper solution
> >comes out to prevent
> >the expectedserious problem occur.
>
> The suggestion that use of a particular subset of Unicode be temporarily
> restricted suggests a failure to understand basic issues of Internet
> protocol design.  Such special case handling is not viable in the scale
> of
> global Internet community.
>
> d/
>
>
> ----------
> Dave Crocker  
> Brandenburg InternetWorking  
> tel +1.408.246.8253;  fax +1.408.273.6464
>
>
>
>
>




From owner-idn@ops.ietf.org  Tue Feb  5 06:41: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 GAA27611
	for ; Tue, 5 Feb 2002 06:41:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y3fa-0001oF-00
	for idn-data@psg.com; Tue, 05 Feb 2002 03:21:50 -0800
From: "Eric Yu" 
To: 
Subject: [idn] Please do not pass an IDN document which you know will
    cause conflicts and chaos
Date: Tue, 5 Feb 2002 17:54:28 +0800
Message-ID: <000701c1ae2b$19de2460$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGuKxneNZt7+S4zRCGUwxlXjtJ1/Q==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA27611


Ive recently come to know that IETF is about to release drafts on
IDN standards, and to my regret, I found that the document does not solve problems for Chinese domain names.  And this defect in your drafts
will result conflicts and chaos for Internet users of Han characters, namely Chinese, Korean and Japanese, and the effect is international because users of these languages are all over the world.

It is important to know that while a certain character can have different appearance in Simplified Chinese and Traditional Chinese Character forms even though they are actually same words with the same meaning; at the same time, a certain character which might look exactly
the same, but in fact are two different words with different meaning when applied to different languages such as Chinese and Japanese.  I believe that IETF bears great responsible in setting standards which will bring order to the Internet world, and any document which might cause disorder, should be carefully reconsidered before release.  Therefore, Before IETF can resolve this problem and identify one mechanism which can differentiate these delicate language difference, IETF should not pass the document which would apply Unicode for IDN resolution, because this irresponsible decision is going to cause conflicts and chaos in DN registration policy and DRP worldwide.


Eric Yu
ericyu@mail2000.com.tw
National Taiwan University





From owner-idn@ops.ietf.org  Tue Feb  5 06:50: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 GAA27763
	for ; Tue, 5 Feb 2002 06:50:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y3vK-0002HJ-00
	for idn-data@psg.com; Tue, 05 Feb 2002 03:38:06 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Y3vJ-0002HD-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 03:38:05 -0800
Received: (qmail 1027 invoked by uid 1001); 5 Feb 2002 11:36:31 -0000
Date: 5 Feb 2002 11:36:31 -0000
Message-ID: <20020205113631.23349.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org,
  dhc@dcrocker.net,
  smb@research.att.com,
  Elisabeth.Porteneuve@cetp.ipsl.fr,
  Marc.Blanchet@viagenie.qc.ca,
  ajm@icann.org,
  erin@twnic.net.tw,
  fred@cisco.com,
  harald@alvestrand.no,
  htk@eecs.harvard.edu,
  iab@ISI.EDU,
  iesg@ietf.org,
  jet-member@nic.ad.jp,
  jseng@pobox.org.sg,
  klensin@jck.com,
  lynn@icann.org,
  mkatoh@mkatoh.net,
  mkatoh@wdc.fujitsu.com,
  mouhamet@next.sn,
  narten@us.ibm.com,
  nordmark@eng.sun.com,
  paf@cisco.com,
  phoffman@imc.org,
  qhhu@public.bta.net.cn,
  sharil@cmc.gov.my,
  shkyong@kgsm.kaist.ac.kr,
  vcerf@mci.net,
  alanysho@hkdnr.net.hk,
  christine.tsang@hkdnr.net.hk,
  deng@cnnic.net.cn,
  hlqian@cnnic.net.cn,
  hoho@iis.sinica.edu.tw,
  huangk@alum.sinica.edu,
  jasonho@umac.mo,
  lee@whale.cnnic.net.cn,
  mao@cnnic.net.cn,
  snw@twnic.net.tw,
  sstseng@twnic.net.tw,
  tsenglm@cc.ncu.edu.tw,
  whzhang@cnnnic.net.cn,
  wschen@twnic.net.tw,
  wuch@gate.sinica.edu.tw,
  yktham@umac.mo
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org, Dave Crocker ,
        "Steven M. Bellovin" ,
        Elisabeth Porteneuve ,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw,
        fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu,
        iab@ISI.EDU, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg,
        klensin@jck.com, lynn@icann.org, mkatoh@mkatoh.net,
        mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com,
        nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org,
        qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        vcerf@mci.net, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk,
        deng@cnnic.net.cn, hlqian@cnnic.net.cn, hoho@iis.sinica.edu.tw,
        huangk@alum.sinica.edu, jasonho@umac.mo, lee@whale.cnnic.net.cn,
        mao@cnnic.net.cn, snw@twnic.net.tw, sstseng@twnic.net.tw,
        tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,
        wuch@gate.sinica.edu.tw, yktham@umac.mo
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dave Crocker writes:
> Provide an existing specification for solving this problem outside the
> domain name service.

One well-known example is the standard TeX OML encoding, which includes
lowercase gamma and uppercase Gamma, and lowercase b and uppercase B,
and lowercase beta, but not a separate uppercase Beta. Why? Because
uppercase Beta and uppercase B have the same glyph.

> Provide a basis for believing that it has gained wide acceptance.
> Oh.  You can't do that.

Feel free to continue making a fool of yourself, Dave.

---Dan



From owner-idn@ops.ietf.org  Tue Feb  5 07:23: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 HAA28252
	for ; Tue, 5 Feb 2002 07:23:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y4XT-0003HT-00
	for idn-data@psg.com; Tue, 05 Feb 2002 04:17:31 -0800
Received: from bartok.sidn.nl ([193.176.144.164])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Y4XS-0003HJ-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 04:17:30 -0800
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1])
	by bartok.sidn.nl (8.11.6/8.11.6) with ESMTP id g15CHPe35647
	for ; Tue, 5 Feb 2002 13:17:25 +0100 (CET)
	(envelope-from jaap@bartok.sidn.nl)
Message-Id: <200202051217.g15CHPe35647@bartok.sidn.nl>
To: idn@ops.ietf.org
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration 
In-reply-to: Your message of 05 Feb 2002 11:36:31 +0000.
             <20020205113631.23349.qmail@cr.yp.to> 
Date: Tue, 05 Feb 2002 13:17:24 +0100
From: Jaap Akkerhuis 
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Adressee list trimmed to normal proportions]

    Dave Crocker writes:
    > Provide an existing specification for solving this problem outside the
    > domain name service.
    
  djb:
    One well-known example is the standard TeX OML encoding, which includes
    lowercase gamma and uppercase Gamma, and lowercase b and uppercase B,
    and lowercase beta, but not a separate uppercase Beta. Why? Because
    uppercase Beta and uppercase B have the same glyph.

I seem to remember that the Euler font, especially made for TeX,
does has a seperate upper and lower case Beta. For every example,
one can always bring up a counter example.

	jaap



From owner-idn@ops.ietf.org  Tue Feb  5 08:11: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 IAA28948
	for ; Tue, 5 Feb 2002 08:11:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y5HS-0004MY-00
	for idn-data@psg.com; Tue, 05 Feb 2002 05:05:02 -0800
Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Y5HR-0004MN-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 05:05:01 -0800
Received: from mailb.telia.se (localhost [127.0.0.1])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g15D4vJ13974
	for ; Tue, 5 Feb 2002 14:04:57 +0100 (MET)
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 g15D4tv13957;
	Tue, 5 Feb 2002 14:04:55 +0100 (MET)
Message-ID: <3C5FD877.20E71284@trab.se>
Date: Tue, 05 Feb 2002 14:04:55 +0100
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: dufberg@nic-se.se, idn@ops.ietf.org
Subject: Re: [idn] IDNA in real life
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mats wrote:

>> As IDNA promotes the use of ACE, many vendors with little understanding
>> for the need of non-ASCII characters will just use ACE, I can expect
>> a long wait before applications handle native host names instead of ACE
>> unless you can force it on them by for example changing the resolver
>> library.
>
>I don't think that your assumption will come true. Next version of Windows
>NT (whatever it is called) will have a nameserver with support of the
>local character set.

Windows 2000 does allow host names with non-ASCII characters.
And it's DNS server uses UTF-8 based domain names following
RFC 1035.

So you are right in that Microsoft already support native host names
including native support in DNS (and that is following RFC 1035).
But not we get ACE names instead of native support and I expect
many other vendors will take a long time to move native as they
now can use ACE. 

   Dan



From owner-idn@ops.ietf.org  Tue Feb  5 08:13: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 IAA28973
	for ; Tue, 5 Feb 2002 08:13:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y5LL-0004TW-00
	for idn-data@psg.com; Tue, 05 Feb 2002 05:09:03 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16Y5LK-0004TO-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 05:09:02 -0800
Received: (qmail 7610 invoked by uid 1001); 5 Feb 2002 13:08:01 -0000
Date: 5 Feb 2002 13:08:01 -0000
Message-ID: <20020205130801.4749.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <20020205113631.23349.qmail@cr.yp.to> <200202051217.g15CHPe35647@bartok.sidn.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Jaap Akkerhuis writes:
> I seem to remember that the Euler font, especially made for TeX,
> does has a seperate upper and lower case Beta. For every example,
> one can always bring up a counter example.

A counterexample to what? We already knew that b and beta and B and Beta
are often separated. They're separated in Unicode; that's why we're
having this discussion.

Anyway, you should learn to check your facts. The standard Euler fonts
follow the standard TeX encodings. For example, eurb10 uses the OML
encoding, which has a unified B/Beta, exactly as I explained before.

---Dan



From owner-idn@ops.ietf.org  Tue Feb  5 09:45: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 JAA01363
	for ; Tue, 5 Feb 2002 09:45:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y6hb-0006b1-00
	for idn-data@psg.com; Tue, 05 Feb 2002 06:36:07 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Y6hb-0006av-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 06:36:07 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Tue, 5 Feb 2002 06:51:53 -0800
Message-ID: <004801c1ae53$db02d8c0$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "IETF idn working group" ,
        "Kenny Huang" 
References:  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <003c01c1a873$49945d90$08d8ea0c@c1340594a>  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <20020205053329.GA12391@nicemice.net>
Subject: Re: [idn] Re: peanut gallery
Date: Tue, 5 Feb 2002 09:46:11 -0500
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

Hi Kenny,

>
> That might prohibit a few characters unnecessarily, but it will make
> sure that Taiwan, Japan, and Korea are able to use all their
characters,
> and will leave the maximum flexibility for China & Singapore to
define
> how to fold the remaining characters if they decide that's what they
> want to do.
>
> I wouldn't recommend this course, but if most of the Chinese
community
> wanted to do this, I don't see why the rest of us should object.
>

Adam's suggestion seems like a resonable compromise (but even more
important, a *do-able* compromise).  It will allow our friends in the
Chinese community as much time as it needs to come up with a TC<->SC
solution and yet still allow IDN to move forward as the majority of
this WG wants.

Please let me know what you think?

Thanks,
Ben






From owner-idn@ops.ietf.org  Tue Feb  5 12:29: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 MAA09748
	for ; Tue, 5 Feb 2002 12:29:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y8xb-0009e6-00
	for idn-data@psg.com; Tue, 05 Feb 2002 09:00:47 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Y8xa-0009dz-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 09:00:46 -0800
Received: from jamescompaq (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g15H0gZJ025242
	for ; Wed, 6 Feb 2002 01:00:42 +0800
Message-ID: <001501c1ae64$e39770c0$0701000a@jamescompaq>
From: "James Seng/Personal" 
To: 
Subject: [idn] Fw: 53rd IETF WG/BOF Scheduling
Date: Wed, 6 Feb 2002 00:48:07 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Is there sufficient interest for us to have a face meeting at the next IETF?
Please provide your feedback.

-James Seng

> We would like to remind you that on Friday, February 22, at 17:00 ET
> the scheduling will be closed.
> Please check the Draft Agenda on
http://www.ietf.org/meetings/agenda_53.txt and
> submit your requests (in the appropriate form as we ask you) if you
didn't.
>
> Thanks.
>
> Dinara Suleymanova
>
>




From owner-idn@ops.ietf.org  Tue Feb  5 14:48: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 OAA16179
	for ; Tue, 5 Feb 2002 14:48:23 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YBNg-000CU1-00
	for idn-data@psg.com; Tue, 05 Feb 2002 11:35:52 -0800
Received: from fluorine.singnet.com.sg ([165.21.74.72] helo=fluorine.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YBNf-000CTv-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 11:35:51 -0800
Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Wed, 6 Feb 2002 03:23:45 +0800
Received: from mx16.singnet.com.sg ([165.21.74.116]) by fluorine.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Wed, 6 Feb 2002 01:44:57 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx16.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g15HivqH004722
	for ; Wed, 6 Feb 2002 01:44:57 +0800
Received: by blake.i-email.net (Postfix)
	id 53B31A890E; Wed,  6 Feb 2002 01:44:57 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id 04C3FA8901
	for ; Wed,  6 Feb 2002 01:44:57 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Y8xb-0009e6-00
	for idn-data@psg.com; Tue, 05 Feb 2002 09:00:47 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Y8xa-0009dz-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 09:00:46 -0800
Received: from jamescompaq (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g15H0gZJ025242
	for ; Wed, 6 Feb 2002 01:00:42 +0800
Message-ID: <001501c1ae64$e39770c0$0701000a@jamescompaq>
From: "James Seng/Personal" 
To: 
Subject: [idn] Fw: 53rd IETF WG/BOF Scheduling
Date: Wed, 6 Feb 2002 00:48:07 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Is there sufficient interest for us to have a face meeting at the next IETF?
Please provide your feedback.

-James Seng

> We would like to remind you that on Friday, February 22, at 17:00 ET
> the scheduling will be closed.
> Please check the Draft Agenda on
http://www.ietf.org/meetings/agenda_53.txt and
> submit your requests (in the appropriate form as we ask you) if you
didn't.
>
> Thanks.
>
> Dinara Suleymanova
>
>




From owner-idn@ops.ietf.org  Tue Feb  5 15:23: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 PAA17846
	for ; Tue, 5 Feb 2002 15:23:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YC0I-000D5m-00
	for idn-data@psg.com; Tue, 05 Feb 2002 12:15:46 -0800
Received: from rwcrmhc54.attbi.com ([216.148.227.87])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YC0H-000D5g-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 12:15:45 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc54.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020205201544.QVIM7443.rwcrmhc54.attbi.com@c1340594a>
          for ; Tue, 5 Feb 2002 20:15:44 +0000
Message-ID: <005801c1ae82$351a6bb0$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "IETF idn working group" 
References:  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <003c01c1a873$49945d90$08d8ea0c@c1340594a>  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <20020205053329.GA12391@nicemice.net>
Subject: Re: [idn] Re: peanut gallery
Date: Tue, 5 Feb 2002 12:17:59 -0800
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 am coveying some background information from John Jenkins (who is on
the IRG), slightly condensed:

==========

1) Presence in the G source is *not* an indication of being either
"Chinese" or "simplified Chinese."  The G source is the source which
was used to include all of the KangXi, for example, which is hardly
"simplified Chinese."  There are also some traditional characters used
for Cantonese, and Korean characters in there.

The IRG sources are indications of who *asked* for a character to be
included, and *not* an indication of "what kind of character" is
involved. Excluding G-source-only characters on the presumption that
they're SC would be a mistake.

2) There is still the assumption being made that one can look at a
character and say, "Ah, yes, this is SC" or "Ah, yes, this is TC."  It
is impossible to separate Chinese from Japanese and Korean cleanly
since they use the same characters. Also, given the significant
percentage of characters which are *both* traditional forms in their
own right *and* simplifications of other characters, the whole process
is extremely problematic.

You *cannot* from the 10646 data, or the IRG data, or presence in
charset mappings extrapolate whether a particular ideograph is SC or
TC.  You must have knowledge of the individual characters.

Mark

—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Adam M. Costello" 
To: 
Sent: Monday, February 04, 2002 21:33
Subject: Re: [idn] Re: peanut gallery


> I wrote:
>
> > Here's a more precise version of the proposal:  Prohibit a Han
code
> > point iff it has a kTraditionalVariant and has only "G" sources
> > (China/Singapore).  Would that do what I intend?
>
> "Mark Davis (jtcsv)"  replied:
>
> > No, that wouldn't do as you intend. The kTraditionalVariant is not
a
> > normative field... while it has improved over time, I would not
put
> > any real weight on it without a thorough review.
>
> Okay then, how about this:  Prohibit a Han code point iff it has
only
> "G" sources (China/Singapore).
>
> That might prohibit a few characters unnecessarily, but it will make
> sure that Taiwan, Japan, and Korea are able to use all their
characters,
> and will leave the maximum flexibility for China & Singapore to
define
> how to fold the remaining characters if they decide that's what they
> want to do.
>
> I wouldn't recommend this course, but if most of the Chinese
community
> wanted to do this, I don't see why the rest of us should object.
>
> AMC
>
>




From owner-idn@ops.ietf.org  Tue Feb  5 17:20: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 RAA21499
	for ; Tue, 5 Feb 2002 17:20:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YDkc-000EsV-00
	for idn-data@psg.com; Tue, 05 Feb 2002 14:07:42 -0800
Received: from spider.nic-se.se ([212.247.3.67])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YDka-000EsP-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 14:07:41 -0800
Received: from localhost (dufberg@localhost)
	by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g15M6IS11751;
	Tue, 5 Feb 2002 23:06:18 +0100 (CET)
X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs
Date: Tue, 5 Feb 2002 23:06:18 +0100 (CET)
From: Mats Dufberg 
To: Dan Oscarsson 
cc: 
Subject: Re: [idn] IDNA in real life
In-Reply-To: <3C5FD877.20E71284@trab.se>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Feb 5, 2002, 14:04 (+0100) Dan Oscarsson  wrote:

> >I don't think that your assumption will come true. Next version of Windows
> >NT (whatever it is called) will have a nameserver with support of the
> >local character set.
>
> Windows 2000 does allow host names with non-ASCII characters.
> And it's DNS server uses UTF-8 based domain names following
> RFC 1035.

It is hard to argue that UTF-8 follows the current standard for DNS and
domain names.


> So you are right in that Microsoft already support native host names
> including native support in DNS (and that is following RFC 1035).
> But not we get ACE names instead of native support and I expect
> many other vendors will take a long time to move native as they
> now can use ACE.

I think that you underestimate the willingness of Microsoft of creating an
interface for their DNS server where the user can enter hostnames in the
local character set with automatic conversion to the ACE format in the
zone file.

I'll buy you a beer at appropriate IETF meeting if the first version of
Server Windows ("based on NT technology") released after published RFC's
on IDN will not allow you to enter native hostnames in local character
set!


Mats

----------------------------------------------------------------------
Mats Dufberg 
----------------------------------------------------------------------






From owner-idn@ops.ietf.org  Tue Feb  5 18:11: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 SAA22895
	for ; Tue, 5 Feb 2002 18:11:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YEa9-000Fkr-00
	for idn-data@psg.com; Tue, 05 Feb 2002 15:00:57 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YEa8-000Fkl-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 15:00:56 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16YEa7-0006k0-00
	for ; Tue, 05 Feb 2002 15:00:55 -0800
Date: Tue, 5 Feb 2002 23:00:55 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] Re: peanut gallery
Message-ID: <20020205230055.GB25535@nicemice.net>
Reply-To: IETF idn working group 
References: <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <003c01c1a873$49945d90$08d8ea0c@c1340594a>  <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net> <20020205053329.GA12391@nicemice.net> <005801c1ae82$351a6bb0$08d8ea0c@c1340594a>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005801c1ae82$351a6bb0$08d8ea0c@c1340594a>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Mark Davis  wrote:

> 1) Presence in the G source is *not* an indication of being either
> "Chinese" or "simplified Chinese."

I know.

> The IRG sources are indications of who *asked* for a character to
> be included, and *not* an indication of "what kind of character" is
> involved.

I understand.

> Excluding G-source-only characters on the presumption that they're SC
> would be a mistake.

I am not presuming that they are simplified.  I am presuming that the
Japanese, Korean, Taiwanese, and Vietnamese communities will not be
bothered much by having those characters prohibited or folded, since
those countries never asked for them to be included in the first place.

> You *cannot* from the 10646 data, or the IRG data, or presence in
> charset mappings extrapolate whether a particular ideograph is SC or
> TC.  You must have knowledge of the individual characters.

Right, which is why this latest proposal would leave those questions in
the hands of the Chinese experts, not us, not the Unicode folks.

AMC



From owner-idn@ops.ietf.org  Tue Feb  5 19:43: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 TAA26123
	for ; Tue, 5 Feb 2002 19:43:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YFub-000H9a-00
	for idn-data@psg.com; Tue, 05 Feb 2002 16:26:09 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16YFuZ-000H9U-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 16:26:07 -0800
Received: (qmail 3650 invoked by uid 1001); 6 Feb 2002 00:25:01 -0000
Date: 6 Feb 2002 00:25:00 -0000
Message-ID: <20020206002500.1211.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: [idn] Alpha Online
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Some readers don't have UTF-8 MUAs yet, so I'll use ``q'' in this
message to mean a lowercase Greek alpha.]

A web search immediately reveals several organizations with ``Alpha
Online'' in their names: Alpha Online Berlin, Alpha Online Power, JN
Alpha Online, etc.

Presumably one of these organizations will want to register and use
qol.com. Yes or no: Will they be allowed to do so?

Under trademark law, cybersquatting law, etc., there is probably no
conflict between qol.com and aol.com, but there is obviously a conflict
between the uppercase versions of the same names, because those
uppercase versions use the same glyphs: AOL.COM.

The current IDN proposals insist on tying the lowercase and uppercase
versions together. Does this mean that qol.com won't be allowed?

We can avoid this problem. As I said before, the careful approach to
IDNs is to start with

   (1) case-sensitive IDNs in which
   (2) uppercase non-ASCII letters are prohibited by the registries.

If case-insensitivity turns out to be a good idea, we can add it later,
because of #2. Otherwise, we can avoid case-insensitivity problems, and
skip a horribly complicated part of IDN implementation, because of #1.

These observations are not new. They've been brought up repeatedly. The
only counterargument is speculation that users won't be able to adapt to
case-sensitive names---even though URLs are already case-sensitive!

To summarize: These proposals impose huge software costs and guarantee
mass confusion among domain names having the same glyphs, because the
proponents think users are too stupid to handle case-sensitive names.
Furthermore, the proponents insist on cementing this decision now,
rather than taking a careful approach that defers the commitment.

I continue to be amazed at the carelessness of the IDNA proponents.
Apparently they don't even listen when their ``internationalization''
proposals receive incredibly strong objections from the users most
affected by the proposals. IDNA would never have reached ``last call''
stage in a legitimate standards organization.

---Dan



From owner-idn@ops.ietf.org  Tue Feb  5 20:46: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 UAA27355
	for ; Tue, 5 Feb 2002 20:46:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YH1x-000I9b-00
	for idn-data@psg.com; Tue, 05 Feb 2002 17:37:49 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YH1w-000I9S-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 17:37:48 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id JAA30759;
	Wed, 6 Feb 2002 09:31:17 +0800
From: "Kenny Huang" 
To: "ben" , "IETF idn working group" 
Subject: RE: [idn] Re: peanut gallery
Date: Wed, 6 Feb 2002 09:42:43 +0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <004801c1ae53$db02d8c0$cd462b18@mtag.phub.net.cable.rogers.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA27355

Dear Ben and Adam,

Thanks for your suggestion. This could be one option for Han users.
I've proposed phased implementation for IDNA, that would be another
compromise.

Cheers

Kenny Huang


> -----Original Message-----
> From: ben [mailto:ben@cc-www.com]
> Sent: Tuesday, February 05, 2002 10:46 PM
> To: IETF idn working group; Kenny Huang
> Subject: Re: [idn] Re: peanut gallery
> 
> 
> Hi Kenny,
> 
> >
> > That might prohibit a few characters unnecessarily, but it will make
> > sure that Taiwan, Japan, and Korea are able to use all their
> characters,
> > and will leave the maximum flexibility for China & Singapore to
> define
> > how to fold the remaining characters if they decide that's what they
> > want to do.
> >
> > I wouldn't recommend this course, but if most of the Chinese
> community
> > wanted to do this, I don't see why the rest of us should object.
> >
> 
> Adam's suggestion seems like a resonable compromise (but even more
> important, a *do-able* compromise).  It will allow our friends in the
> Chinese community as much time as it needs to come up with a TC<->SC
> solution and yet still allow IDN to move forward as the majority of
> this WG wants.
> 
> Please let me know what you think?
> 
> Thanks,
> Ben
> 
> 




From owner-idn@ops.ietf.org  Tue Feb  5 21:48: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 VAA29645
	for ; Tue, 5 Feb 2002 21:48:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YHsU-000J24-00
	for idn-data@psg.com; Tue, 05 Feb 2002 18:32:06 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YHsT-000J1x-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 18:32:05 -0800
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 SAA32005;
	Tue, 5 Feb 2002 18:31:49 -0800
Message-Id: <5.1.0.14.2.20020205182353.035b5038@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 05 Feb 2002 18:28:50 -0800
To: "D. J. Bernstein" 
From: Dave Crocker 
Subject: Re: [idn] Alpha Online
Cc: idn@ops.ietf.org
In-Reply-To: <20020206002500.1211.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 12:25 AM 2/6/2002 +0000, D. J. Bernstein wrote:
>Under trademark law, cybersquatting law, etc., there is probably no
>conflict between qol.com and aol.com, but there is obviously a conflict
>between the uppercase versions of the same names, because those
>uppercase versions use the same glyphs: AOL.COM.

 From one jurisdiction to the next, trademark law is complicated enough and 
variable enough to strongly suggest that predictions about trademark 
disputes are best left to experienced trademark attorneys.  Those of us on 
this list are dabblers in the law and our opinions about outcomes do not 
have much basis.


>I continue to be amazed at the carelessness of the IDNA proponents.

Some of us continue to be amazed at the constant hyperbole and ad hominem 
disparagement offered by others.

All that is achieved by this high emotion is low counter-productivity.

d/
----------

Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Feb  5 23:22: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 XAA02345
	for ; Tue, 5 Feb 2002 23:21:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YJPO-000KaS-00
	for idn-data@psg.com; Tue, 05 Feb 2002 20:10:10 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YJPO-000KaM-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 20:10:10 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Tue, 5 Feb 2002 20:25:57 -0800
Message-ID: <004901c1aec5$9578d940$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "Kenny Huang" ,
        "IETF idn working group" 
References: 
Subject: Re: [idn] Re: peanut gallery
Date: Tue, 5 Feb 2002 23:20:17 -0500
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

Hi Kenny,

Thanks for your reply.  However, just a friendly reminder that Adam's
suggestion is still *only a suggestion*.  As IDNA's last call
continues to move forward, I hope the WG gets to see your proposal(s)
soon.

Thanks,
Ben


---- Original Message -----
From: "Kenny Huang" 
To: "ben" ; "IETF idn working group"

Sent: Tuesday, February 05, 2002 8:42 PM
Subject: RE: [idn] Re: peanut gallery


Dear Ben and Adam,

Thanks for your suggestion. This could be one option for Han users.
I've proposed phased implementation for IDNA, that would be another
compromise.

Cheers

Kenny Huang


> -----Original Message-----
> From: ben [mailto:ben@cc-www.com]
> Sent: Tuesday, February 05, 2002 10:46 PM
> To: IETF idn working group; Kenny Huang
> Subject: Re: [idn] Re: peanut gallery
>
>
> Hi Kenny,
>
> >
> > That might prohibit a few characters unnecessarily, but it will
make
> > sure that Taiwan, Japan, and Korea are able to use all their
> characters,
> > and will leave the maximum flexibility for China & Singapore to
> define
> > how to fold the remaining characters if they decide that's what
they
> > want to do.
> >
> > I wouldn't recommend this course, but if most of the Chinese
> community
> > wanted to do this, I don't see why the rest of us should object.
> >
>
> Adam's suggestion seems like a resonable compromise (but even more
> important, a *do-able* compromise).  It will allow our friends in
the
> Chinese community as much time as it needs to come up with a TC<->SC
> solution and yet still allow IDN to move forward as the majority of
> this WG wants.
>
> Please let me know what you think?
>
> Thanks,
> Ben
>
>







From owner-idn@ops.ietf.org  Wed Feb  6 00:02: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 AAA03407
	for ; Wed, 6 Feb 2002 00:02:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YK5E-000LKs-00
	for idn-data@psg.com; Tue, 05 Feb 2002 20:53:24 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YK5E-000LKm-00
	for idn@ops.ietf.org; Tue, 05 Feb 2002 20:53:24 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id UAA03429
	for ; Tue, 5 Feb 2002 20:53:13 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id UAA14012
	for ; Tue, 5 Feb 2002 20:53:23 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id UAA14002;
	Tue, 5 Feb 2002 20:53:22 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id UAA00699;
	Tue, 5 Feb 2002 20:52:22 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id UAA01563;
	Tue, 5 Feb 2002 20:53:19 -0800 (PST)
Date: Tue, 5 Feb 2002 20:53:19 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202060453.UAA01563@birdie.sybase.com>
To: tsenglm@cc.ncu.edu.tw
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Cc: idn@ops.ietf.org
X-Sun-Charset: ISO-8859-1
Sender: owner-idn@ops.ietf.org
Precedence: bulk

L.M. Tseng wrote:

> From owner-idn@ops.ietf.org Tue Feb  5 02:36:26 2002
> To: "Erin Chen" , "Dave Crocker" 
> Cc: "IESG" , "IAB" ,
>         "IETF IDN WG" 
> Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration

> Dear Dave Crocker:
>                   My  friend give me an example about  CJK UNICODE ,  It is
> so ambiguous to me to deifferentiate which  one is a correct Chinese
> characters or  not ?  In  our  hand writting , each pair are used and mixed
> .
> 
> 淸眞敎 U+6DF8 U+771E U+654E
> 淸眞教 U+6DF8 U+771E U+6559
> 淸真敎 U+6DF8 U+771F U+654E
> 淸真教 U+6DF8 U+771F U+6559
> 清眞敎 U+6E05 U+771E U+654E
> 清眞教 U+6E05 U+771E U+6559
> 清真敎 U+6E05 U+771F U+654E
> 清真教 U+6E05 U+771F U+6559

Huh? How is this contributing to closure on Last Call on
the IDNA documents? And why is it cc'd to IESG and IAB?

For those who may be mystified, this is the Chinese word for
"Islam", qing1zhen1jiao4.

The ordinary way this would appear in a PRC dictionary is:

   U+6E05 U+771F U+6559

and not any of the other 7 permutations.

In a more traditional dictionary as might be seen in Taiwan
or Hong Kong, it might be printed:

   U+6DF8 U+771E U+6559

and not any of the other 7 permutations.

However, if you were using a Big-5 computer in Taiwan,
you would use the same characters as for the PRC for
this:

   U+6E05 U+771F U+6559

and not any of the other 7 permutations. (though the
fonts might vary in which glyph they show, in any case)

U+6E05 and U+771F, by the way, are examples of "traditional
simplifications" reflecting handwritten forms, that
predate the PRC systematic simplifications. The same two
forms are also used in Japan.

U+654E is another handwriting alternative for U+6559, but
it is seldom seen in printed material. U+654E is used in
the PRC, Taiwan, and in Japan alike.

All 6 characters have G, T, and K sources in 10646, and
4 of them have J sources as well. So for this kind of
overlap of forms, any suggestion to delete G-source-only
characters from the allowed set does nothing at all.

And lest this example be taken on its face value
as indicating a problem in "CJK UNICODE", it should be noted
that the presence of these alternate forms of the "same character"
in Unicode is due to the same distinctions being made in
legacy CJK character encodings in Asia. In particular,
note the following mappings:

For "GBK", Code Page 936 Simplified Chinese:

0x9C5B	0x6DF8	#CJK UNIFIED IDEOGRAPH
0xC7E5	0x6E05	#CJK UNIFIED IDEOGRAPH
0xB177	0x771E	#CJK UNIFIED IDEOGRAPH
0xD5E6	0x771F	#CJK UNIFIED IDEOGRAPH
0x949C	0x654E	#CJK UNIFIED IDEOGRAPH
0xBDCC	0x6559	#CJK UNIFIED IDEOGRAPH

And for "Shift-JIS", Code Page 932 Japanese:

0xEDE4	0x6DF8	#CJK UNIFIED IDEOGRAPH
0xFB43	0x6DF8	#CJK UNIFIED IDEOGRAPH
0x90B4	0x6E05	#CJK UNIFIED IDEOGRAPH
0xE1C1	0x771E	#CJK UNIFIED IDEOGRAPH
0x905E	0x771F	#CJK UNIFIED IDEOGRAPH
0xEDB1	0x654E	#CJK UNIFIED IDEOGRAPH
0xFACD	0x654E	#CJK UNIFIED IDEOGRAPH
0x8BB3	0x6559	#CJK UNIFIED IDEOGRAPH

So if you are working on a Windows system in either of
these legacy code pages, in China or Japan, you
already have the same options for representational
ambiguity, without invoking Unicode at all.

--Ken

> 
> L.M.Tseng
> 



From owner-idn@ops.ietf.org  Wed Feb  6 03:38: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 DAA14356
	for ; Wed, 6 Feb 2002 03:38:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YNNw-000Oii-00
	for idn-data@psg.com; Wed, 06 Feb 2002 00:24:56 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YNNv-000Oic-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 00:24:55 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id QAA32043
	for ; Wed, 6 Feb 2002 16:18:36 +0800
From: "Kenny Huang" 
To: "IETF-IDN" 
Subject: [idn] Internet Draft - Phased Implementation for IDNA
Date: Wed, 6 Feb 2002 16:30:02 +0800
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0010_01C1AF2B.86CFBBA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C1AF2B.86CFBBA0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Dear IETF IDN members,

The attached draft  "Phased Implementation for IDNA" was submitted.
You are welcome to commont on the draft.

FYI

Kenny Huang

------=_NextPart_000_0010_01C1AF2B.86CFBBA0
Content-Type: text/plain;
	name="ietf-tseng-idn-piidna-00.txt.txt"
Content-Disposition: attachment;
	filename="ietf-tseng-idn-piidna-00.txt.txt"
Content-Transfer-Encoding: quoted-printable

Internet Draft                                    Lee Ming Tseng
                  Jan Ming Ho   =20
01 Feb 2002                                       Kenny Huang            =
=20
expires  01 August 2002                                       =20

Phased Implementation for Internationalized Domain Names in Applications

Status of this Memo

    This document is an Internet-Draft and is in full conformance=20
    with all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet=20
    Engineering Task Force (IETF), its areas, and its working=20
    groups. Note that other groups may also distribute working=20
    documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of
    six months and may be updated, replaced, or obsoleted by other
    documents at any time. It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

    A copy of this particular draft is also archived at=20
    http://www.twnic.net.tw

Abstract

This document proposes a phased implementation for IDNA=20
(Internationalized Domain Names in Applications). DNS infrastructure=20
is critical for the Internet operation. The implementation of IDNA=20
shall be carefully considered and examined. Deployment of IDN=20
infrastructure shall be migrated step by step to ensure the reliability=20
of the new infrastructure. To fulfill the incremental change =
requirements,=20
this document proposes a phased implementation for IDNA.

1 Terminology

The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119 =
[7].

A "code point" is an integer value associated with a character in a =
coded
character set.

"TC" is an abbreviation for Traditional Chinese.

"SC" is an abbreviation for Simplified Chinese.

"CDN" is defined as an acronym of Chinese Domain Name that represents=20
internationalized domain name, which contains at least one Chinese=20
character. As to the scope of Chinese character, please refer to=20
ISO/IEC 10646-1:2000(E) [second edition 2000-09-15], if one character is =

marked "C and G-Hanzi-T", it MUST be a Chinese character, such a =
definition=20
does not mean that it is not a character of other countries that use HAN =

ideograph.[8]


2 Proposed Phased implementation of IDNA

The IDN Working Group decides to use Unicode as the basis to enable
IDN services. This proposal proposes two phases implementation for=20
IDNA, namely Bootstrapping Phase and Mature Phase as described below.

2.1 Bootstrapping Phase

At bootstrapping phase, the lists in Appendix B shall be applied=20
to prohibit these code points until future update is requested by
user community. The description on how Appendix B was formed is=20
specified in the section 3.=20

                     +------+
                     | User |
                     +------+
                        ^
                        | Input and display: local interface methods
                        | (pen, keyboard, glowing phosphorus, ...)
    +-------------------|-------------------------------+
    |                   v                               |
    |          +-----------------------------+          |
    |          |        NamePrep             |          |
    |          |  1 Mapping                  |          |
    |          |  2 Normalization            |          |
    |          |  3 Prohibited Output        |          |
    |          +-----------------------------+          |
    |                   ^                               |
    |                   |                               |
    |                   v                               |
    |          +-----------------------------+          |
    |          |  Extended Prohibited Output |          |
    |          +-----------------------------+          |
    |                   ^                               |  =20
    |                   |                               |
    |                   v                               |
    |          +-----------------------------+          |
    |          |        Punycode[5]          |          |
    |          +-----------------------------+          |
    |                    ^       ^                      | End system
    |                    |       |                      |
    |  Call to resolver: |       | Application-specific |
    |               ACE  |       | protocol:            |
    |                    v       | predefined by the    |
    |           +----------+     | protocol or defaults |
    |           | Resolver |     | to ACE               |
    |           +----------+     |                      |
    |                 ^          |                      |
    +-----------------|----------|----------------------+
        DNS protocol: |          |
                  ACE |          |
                      v          v
           +-------------+    +---------------------+
           | DNS servers |    | Application servers |
           +-------------+    +---------------------+

Table 1. IDNA architecture [4] with extended prohibited output module.


2.2 Mature Phase=20

The phased implementation of IDNA shall maintain the flexibility for
future revision. Unknown code points will be sent to the extended=20
prohibited output module. Valid code points on the other hand will=20
never be prohibited. The future version of IDNA simply removes=20
the prohibition on the code points listed in Appendix B, resulting
in the same IDNA that's now on the table.=20

                     +------+
                     | User |
                     +------+
                        ^
                        | Input and display: local interface methods
                        | (pen, keyboard, glowing phosphorus, ...)
    +-------------------|-------------------------------+
    |                   v                               |
    |          +-----------------------------+          |
    |          |        NamePrep             |          |
    |          |  1 Mapping                  |          |
    |          |  2 Normalization            |          |
    |          |  3 Prohibited Output        |          |
    |          +-----------------------------+          |
    |                   ^                               |
    |                   |                               |
    |                   v                               |
    |          +-----------------------------+          |
    |          |        Punycode[5]          |          |
    |          +-----------------------------+          |
    |                    ^       ^                      | End system
    |                    |       |                      |
    |  Call to resolver: |       | Application-specific |
    |               ACE  |       | protocol:            |
    |                    v       | predefined by the    |
    |           +----------+     | protocol or defaults |
    |           | Resolver |     | to ACE               |
    |           +----------+     |                      |
    |                 ^          |                      |
    +-----------------|----------|----------------------+
        DNS protocol: |          |
                  ACE |          |
                      v          v
           +-------------+    +---------------------+
           | DNS servers |    | Application servers |
           +-------------+    +---------------------+

Table 2. IDNA architecture [4].


3 Extended Prohibited Output

This diagram specifies how the extended prohibition table=20
(Appendix B) is used. The code points listed in Appendix B=20
are proposed by the authors. Appendix B covers Partial Han
code points, which may be used in Japan, Korea, Taiwan and
China.=20

The subsections below describe why the code points are selected=20
in Appendix B. Implementations of this diagram MUST be based=20
on Appdendix B, not based on the descriptions in this section.=20
The lists in Appendix B MUST be used by implementations of=20
this specification.

3.1 Equivalent matching

Some character sets has the issue of equivalent matching, such as=20
Han code points. Han characters are used in many countries in Asia.=20
For a single written language, two Han characters are said to be=20
variants of each other if they have the same meaning and pronounce=20
the same. In other words, they are supposed to be matched as=20
equivalent characters. But, the variant relation can be either=20
context sensitive or context free. [1][2]

It is also true that some variant relation in one country does not=20
exist in other countries. Since Han ideograph is an open set, it is=20
still growing even in modern days. What makes it even more complicated=20
is the number of variants of Han character in different versions of=20
Unicode. The number of unified Han characters is 21,204 in Unicode 2.0,=20
27,786 in Unicode 3.0, and 70,207 in Unicode 3.1 [6]. The larger is the=20
size of Unicode, the larger is the size of its associated variants.=20
We noticed that there are some dictionaries of variants. But, =
international=20
standardizing efforts on variants based on Unicode had not been engaged=20
by any organization at the time the authors are preparing this document.

We also recognize that one does not have to consider the existence of=20
variants if names are nothing but identifiers. But, if a name itself=20
is a product with commercial value as is the case in domain name=20
services, then the ambiguity introduced by the variants into delegation=20
and resolution processes must be minimized. A domain name service=20
which is unable to minimize these ambiguities will cause serious=20
consumer protection problems.

On possible solution to the Han variant problem is to standardize=20
a variant relation,which is context free and is true for all nations=20
or regions, with respect to a given subset of Han characters. The=20
purpose is not to provide a complete solution to the Han variant=20
problem given the fact that Chinese character is an open set. Instead,=20
its purpose is to define a maximal set of equivalent variants such that
ambiguity in a name service can be minimized at a reasonable cost by=20
a low-level mechanism like IDNA. It is easier and thus is recommended=20
by the authors to define variant relation on a small subset of Han=20
ideograph, e.g., Unicode 2.0. If this is the case, then Han characters=20
beyond this code range should be forbidden in a domain name. Note that=20
Han characters outside of Unicode 2.0 are not commonly used in our=20
daily life. It is also possible to work on a more recent version of=20
Unicode if it is justifiable though. Han variant can be standardized=20
in other standardization bodies, e.g., in Unicode Consortium.=20

Note that Han variants refer to relation of characters. It is different=20
from the equivalence of the words "color" and "colour" which refers to=20
relation of strings of characters.

As mentioned earlier, once variant relation is defined in a closed=20
subset of Han ideograph, then character-level equivalence matching=20
can be implemented at IDNA. On the other hand, intelligent matching=20
algorithms can also be developed at higher layers to match=20
context-sensitive and localized Han variants [15].

The degree of severity for an inconsistent matching rule is distinct=20
from different language communities. The requirements and importance=20
of equivalent CDN were also addressed by Chinese Domain Name=20
Consortium (CDNC) and JET (Joint Engineering Team, formed by JPNIC,=20
KRNIC, CNNIC, TWNIC). CDN requirements are listed in Appdedix A. Before=20
standardizing a set of consistent matching rules, these controversial=20
code points are recommended to be temporarily prohibited in the=20
bootstrapping stage.

3.2 Visual difficulty

Some code points are visually impossible to differentiate and=20
could lead to many user entry errors. In this case these=20
code points can cause unpredictable results when queried.
The issue of visual diffculty may exist in many scripts, but
the impact of visual difficulty by different language groups
should be particularly evaluated.=20

3.3 Solutions incompleteness

It is generally accepted that the IDNA solution does not solve the
CDN problems that listed in Appendix A. Although the WG considered=20
some possible solutions to the CDN problem, those solutions did not=20
meet the IETF's requirements. Thus, this document proposes prohibiting=20
the Han characters listed in Appendix B until a solution that is=20
acceptable to the IETF can be found, or until it is clear that no=20
such solution is possible.


4. Security Considerations [3]

Additional function of the architecture imply addition of opportunities
for compromising the mechanism. Another security issue is, if a user=20
entering a name from the extended prohibited table that results in a=20
failure in the bootstrapping phase..=20

Current applications may assume that the characters allowed in host
names will always be the same as they are in RFC1034[16], RFC1035[17].=20
NamePrep[3] infrastructure vastly increases the number of characters=20
available in host names. Every program that uses "special" characters=20
in conjunction with host names may be vulnerable to attack based on=20
the new characters allowed by NamePrep[3] specification.


5 Other Considerations for Appendix B

5.1 Other scripts requirements

Other scripts (e.g., Arabic and Hebrew..,etc.) may have the same
issues as described in the subsections of section 3. The Appendix B
includes but is not only limited to Han code points. To expedite IDN=20
deployment,"Go fast and prohibit only the code points you understand"=20
model is recommended, thus Appendix B encompass only major Han code=20
points for this version.

However, Appendix B can be extended if there are other code points
proposed by other scripts users.


5.2 Issues for prohibiting Han code points

The Han code points are used in many countries and territories,such
as Japan, Korea, China, Taiwan, Hong Kong, Macao, Singapore..,etc.
Except Han code points, Kana is also used in Japan and Hangel is used in =
Korea.
The proposal will temporarily prevent the users especially in the above
areas from using CDN in the bootstrapping phase. CDN service can only
be activated in the mature phase. This proposed document will cause the
delay of CDN services, on the other hand this will create a good=20
opportunity to pursue a more complete CDN solution.=20


6. Acknowledgement:

Many people from the JET (Joint Engineering Team), CDNC (Chinese
Domain Name Consortium)and IETF IDN Working Group contributed ideas
that went into this document, include

Paul Hoffman
John Klensin
Fred Baker
Vincent Chen
Hua Lin Qian
Yang Woo Ko
Yoshiro Yoneya
Kazunori Konishi
Ching Chun Hsieh
Scott Bradner


7. Author Contact Information:

Li Ming Tseng, Prof
National Central University, TWNIC
Email: tsenglm@cc.ncu.edu.tw
Tel: +886-3-490-4421

Jan Ming Ho, Prof
Academia Sinica, TWNIC
Email: hoho@iis.sinica.edu.tw
Tel: +886-2-2788-3799 x 1803

Kenny Huang
AsiaInfra, Academia Sinica, TWNIC
Email: huangk@alum.sinica.edu
Tel: +886-2-2658-6510


8. References:

[1] A Complete Set of Simplified Chinese Characters, published=20
in 1986 by the Committee of National Language and Chinese=20
Character of China.
=20
[2] Dictionary of Chinese Character Variants, compiled by Mandarin=20
Promotion Council of Taiwan. Version 2 was published in Aug 2001=20
on Web site.http://140.111.1.40/
=20
[3] Paul Hoffman, Marc Blanchet, " Stringprep Profile for=20
Internationalized Host Names",2002-Jan-09,=20
draft-ietf-idn-nameprep-07.txt
=20
[4] Patrik Falstrom, Paul Hoffman, "Internationalizing Domain Names=20
In Applications (IDNA)", 2002-Jan-07, draft-ietf-idn-idna-06.txt
=20
[5] Adam Costello, "Punycode version 0.3.3", 2002-Jan-06,=20
draft-ietf-idn-punycode-00=20
=20
[6] The Unicode Consortium, "The Unicode Standard",
http://www.unicode.org/unicode/standard/standard.html.
=20
[7] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
=20
[8] ISO/IEC 10646-1:2000(E). International Standard - Information=20
technology -- universal Multiple-Octet Coded Character Set (UCS)

[9] H. Alvestrand, "IETF Policy on Character Sets and Languages",=20
1998-Jan, RFC 2277

[10] F. Yergeau, "UTF-8, a transformation format of ISO 10646",=20
1998-Jan, RFC 2279

[11] P. Vixie, "Extension Mechanisms for DNS (EDNS0)",1999-Aug,=20
RFC 2671

[12] CJKV Information Processing, ISBN 1-56592-224-7

[13] Unicode Normalization Forms, Mark Davis and Martin Duerst,
Unicode Technical Report 15 [UTR15].

[14] Case Mappings, Mark Davis, Unicode Technical Report 21 [UTR21].

[15] John C. Klensin, "A Search-based access model for the DNS",=20
2001-Nov-16, draft-klensin-dns-search-02d.txt

[16] Paul Mockapetris, "Domain names - concepts and facilities",=20
1987-Nov, RFC1034

[17] Paul Mockapetris, "Domain names - implementation and=20
specification", 1987-Nov, RFC1035


Appendix A  CDN Requirements:

The original list of CDN requirements were derived from the result=20
of the consensus of 7th JET meeting held on Nov 19th, 2001 in Beijing. =20
The requirements of traditional and simplified Chinese domain name=20
include

(1) Traditional/Simplified CDN solution MUST be consistent for all=20
    CDN users, including but not limited to end users and=20
    administrators.

(2) The need to do multiple registrations and delegation for an=20
    equivalent CDN MUST be minimized. There MUST be only one=20
    registration for equivalent S-CDN. The delegation(s) for an=20
    equivalent CDN MUST be consistent.

(3) Equivalent S-CDN MUST be treated as equivalent in IDN comparison.

(4) There SHOULD be a consistent mechanism to validate CDN. The=20
    validation algorithm of CDN MAY be revised.

(5) Applications that support CDN MAY display the equivalent S-CDN=20
    to users depending on the priority order of user preference=20
    followed by default original form and then lastly ACE fallback.

(6) Implementation of IDN that supports CDN MUST preserve the=20
    original form of CDN.

(7) IDN requirements MUST accommodate CDN user requirements.




Appendix B. Extended Prohibited Code Point List

----- Start Extended Prohibited Table -----
4E00-9FAF
3400-4DBF
----- End Extended Prohibited Table -----

------=_NextPart_000_0010_01C1AF2B.86CFBBA0--




From owner-idn@ops.ietf.org  Wed Feb  6 04:23: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 EAA14959
	for ; Wed, 6 Feb 2002 04:23:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YO7R-000PVQ-00
	for idn-data@psg.com; Wed, 06 Feb 2002 01:11:57 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YO7P-000PVK-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 01:11:56 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g169CKD02633
	for idn@ops.ietf.org; Wed, 6 Feb 2002 18:12:20 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Wed, 6 Feb 2002 18:12:20 +0900
From: YangWoo Ko 
To: IETF-IDN 
Subject: Re: [idn] Internet Draft - Phased Implementation for IDNA
Message-ID: <20020206091220.GL2189@spsoft.co.kr>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.3.27i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Kenny Huang,

Good work !

Now we have a foundation to re-start discussion on this issue.
I'd like to comment on a few points. See below,

On Wed, Feb 06, 2002 at 04:30:02PM +0800, Kenny Huang wrote:
> (snip)
> Phased Implementation for Internationalized Domain Names in Applications
> (snip)
 
> 3.2 Visual difficulty
> 
> Some code points are visually impossible to differentiate and 
> could lead to many user entry errors. In this case these 
> code points can cause unpredictable results when queried.
> The issue of visual diffculty may exist in many scripts, but
> the impact of visual difficulty by different language groups
> should be particularly evaluated. 

Though I am not so good at English, but I think "visual ambiguity" is
a more proper term.

> 3.3 Solutions incompleteness
> 
> It is generally accepted that the IDNA solution does not solve the
> CDN problems that listed in Appendix A. Although the WG considered 
> some possible solutions to the CDN problem, those solutions did not 
> meet the IETF's requirements. Thus, this document proposes prohibiting 
> the Han characters listed in Appendix B until a solution that is 
> acceptable to the IETF can be found, or until it is clear that no 
> such solution is possible.

In what condition, we can declare that "it is clear that no such
solution is possible" ? This may be too tough or too loose depending 
upon understanding and attitude toward this issue.

> (snip)
> 5.2 Issues for prohibiting Han code points
> 
> The Han code points are used in many countries and territories,such
> as Japan, Korea, China, Taiwan, Hong Kong, Macao, Singapore..,etc.
> Except Han code points, Kana is also used in Japan and Hangel is 
> used in Korea.

Hangel -> Hangeul

> (snip)

My best regards

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Feb  6 05:23: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 FAA15803
	for ; Wed, 6 Feb 2002 05:23:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YP9D-0000aQ-00
	for idn-data@psg.com; Wed, 06 Feb 2002 02:17:51 -0800
Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YP9A-0000aG-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 02:17:50 -0800
Received: from maila.telia.se (localhost [127.0.0.1])
	by maila.telia.se (8.11.6/8.11.6) with ESMTP id g16AHac26978
	for ; Wed, 6 Feb 2002 11:17:36 +0100 (MET)
Received: from trab.se (terra.malmo.trab.se [131.115.48.22])
	by maila.telia.se (8.11.6/8.11.6) with ESMTP id g16AHZx26939;
	Wed, 6 Feb 2002 11:17:35 +0100 (MET)
Message-ID: <3C610290.4A053DE2@trab.se>
Date: Wed, 06 Feb 2002 11:16:49 +0100
From: Dan Oscarsson 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: dufberg@nic-se.se, idn@ops.ietf.org
Subject: Re: [idn] IDNA in real life
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mats wrote:

>>
>> Windows 2000 does allow host names with non-ASCII characters.
>> And it's DNS server uses UTF-8 based domain names following
>> RFC 1035.
>
>It is hard to argue that UTF-8 follows the current standard for DNS and
>domain names.

RFC 1035 allows any octet value in labels, this includes all needed for
UTF-8.
So it is allowed and required to be handled by current servers.
All values outside the ASCII range is compared binary, so you have do
agree on case and form to use just like in IDNA to make it work.

Characters outside the ASCII range is not allowed in some systems
concept of "host names", but DNS itself may not restrict them.

So using UTF-8 follows the current DNS standard.


>
>I'll buy you a beer at appropriate IETF meeting if the first version of
>Server Windows ("based on NT technology") released after published RFC's
>on IDN will not allow you to enter native hostnames in local character
>set!

As they already allow you to enter hostnames in local character set,
that
is already fullfilled. Exactely how they are going to introduce ACE
while
retaining their current UTF-8 scheme without breaking therir current
implementation will be interesting to see.

   Dan



From owner-idn@ops.ietf.org  Wed Feb  6 06:44: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 GAA17510
	for ; Wed, 6 Feb 2002 06:44:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YQMA-0001oE-00
	for idn-data@psg.com; Wed, 06 Feb 2002 03:35:18 -0800
From: Elisabeth Porteneuve 
Message-Id: <200202061124.MAA01153@balsa.cetp.ipsl.fr>
To: deng@cnnic.net.cn, erin@twnic.net.tw, mclaughlin@pobox.com
Cc: Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca,
        ajm@icann.org, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk,
        fred@cisco.com, harald@alvestrand.no, hlqian@cnnic.net.cn,
        hoho@iis.sinica.edu.tw, htk@eecs.harvard.edu, huangk@alum.sinica.edu,
        iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo,
        jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com,
        lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn,
        mkatoh@mkatoh.net, mouhamet@next.sn, narten@us.ibm.com,
        nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org,
        qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw,
        vcerf@mci.net, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,
        wuch@gate.sinica.edu.tw, yktham@umac.mo
Subject: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Date: Wed, 06 Feb 2002 03:35:18 -0800



Greetings,

Thank you to all for providing a lot of information, which
helps me to understand better the IDN difficulties.

I would like to ask the last question on Chinese letters subject
- my apology if the answer is well known to all but me.

There is an IETF draft document from Chinese team:
[TC/SC] XiaoDong Lee, Hsu Nai-Wen, Deng Xiang, Erin Chen, Zhang Hong,
Sun Guonian, "Traditional and Simplified Chinese Conversion" (16 Nov
2001)
http://www.ietf.org/internet-drafts/draft-ietf-idn-tsconv-02.txt

This document provide for straightforward function SC/TC in Unicode.

Why this proposal cannot be taken into account by IETF IDN WG?

We are speaking about DNS _labels_, and not _language_ (this has been
beaten to death since years, domain names are labels not language,
there is always an approximation, the accuracy is an exceptionnal
coincidence).

Taking this into account the SC/TC _labels_ conversion is therefore NOT
as complicated issue as _language_ translation, on which I could read
a lot in http://www.cjk.org/cjk/c2c/c2cbasis.htm

Please note there is many many cases in Latin when the meaning is
changed
by diacritical marks, but we can all live with current "LDH"
simplification and lack of accuracy.

Elisabeth Porteneuve






From owner-idn@ops.ietf.org  Wed Feb  6 06:46: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 GAA17555
	for ; Wed, 6 Feb 2002 06:46:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YQPc-0001re-00
	for idn-data@psg.com; Wed, 06 Feb 2002 03:38:52 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YQPb-0001rY-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 03:38:51 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g16BcWU25753
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Wed, 6 Feb 2002 19:38:32 +0800 (CST)
Message-ID: <000901c1af02$711547e0$4007738c@q.j.tw>
From: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= 
To: "Kenneth Whistler" 
Cc: 
References: <200202060453.UAA01563@birdie.sybase.com>
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Date: Wed, 6 Feb 2002 19:35:54 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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

Dear Kenneth Whistler:
                    This is a typical example, everybody is right and
individual event is no problems, but when these are combined and mixed ,
something is unpredictable .
>
> >                   My  friend give me an example about  CJK UNICODE ,  It
is
> > so ambiguous to me to deifferentiate which  one is a correct Chinese
> > characters or  not ?  In  our  hand writting , each pair are used and
mixed.
> >
> > 淸???U+6DF8 U+771E U+654E
> > 淸???U+6DF8 U+771E U+6559
> > 淸???U+6DF8 U+771F U+654E
> > 淸???U+6DF8 U+771F U+6559
> > 清???U+6E05 U+771E U+654E
> > 清???U+6E05 U+771E U+6559
> > 清???U+6E05 U+771F U+654E
> > 清???U+6E05 U+771F U+6559
>
> Huh? How is this contributing to closure on Last Call on
> the IDNA documents? And why is it cc'd to IESG and IAB?
>
> For those who may be mystified, this is the Chinese word for
> "Islam", qing1zhen1jiao4.
>
       What is the worst ?  when I view these  eight records by IE ,
notepad, word and telnet terminal, all these are displayed with diffenent
scripts font.  Someone may be said: that is the bug of  MicroSoft .  But
unfortunately, the Win2K just use UNICODE internally,  the local phonic IME
now can input and selecting  partial scripts of Japan, China and Taiwan
altogether.
       The basic assumtion: UNICODE character is unified and othogonal is
not totally  correct.
> The ordinary way this would appear in a PRC dictionary is:
>
>    U+6E05 U+771F U+6559
>
> and not any of the other 7 permutations.
>
> In a more traditional dictionary as might be seen in Taiwan
> or Hong Kong, it might be printed:
>
>    U+6DF8 U+771E U+6559
>
> and not any of the other 7 permutations.
>
> However, if you were using a Big-5 computer in Taiwan,
> you would use the same characters as for the PRC for
> this:
>
>    U+6E05 U+771F U+6559
>
> and not any of the other 7 permutations. (though the
> fonts might vary in which glyph they show, in any case)
>
          The restriction come from the native-code input method mask out
these characters, even your example of GBK and SJIS have both characters,
but one of them are forbidden in  newspaper and popular input method.  To
push more characters to Domain Name system to support registration is not a
correct approach.
> U+6E05 and U+771F, by the way, are examples of "traditional
> simplifications" reflecting handwritten forms, that
> predate the PRC systematic simplifications. The same two
> forms are also used in Japan.
>
> U+654E is another handwriting alternative for U+6559, but
> it is seldom seen in printed material. U+654E is used in
> the PRC, Taiwan, and in Japan alike.
>
> All 6 characters have G, T, and K sources in 10646, and
> 4 of them have J sources as well. So for this kind of
> overlap of forms, any suggestion to delete G-source-only
> characters from the allowed set does nothing at all.
>
> And lest this example be taken on its face value
> as indicating a problem in "CJK UNICODE", it should be noted
> that the presence of these alternate forms of the "same character"
> in Unicode is due to the same distinctions being made in
> legacy CJK character encodings in Asia. In particular,
> note the following mappings:
>
> For "GBK", Code Page 936 Simplified Chinese:
>
> 0x9C5B 0x6DF8 #CJK UNIFIED IDEOGRAPH
> 0xC7E5 0x6E05 #CJK UNIFIED IDEOGRAPH
> 0xB177 0x771E #CJK UNIFIED IDEOGRAPH
> 0xD5E6 0x771F #CJK UNIFIED IDEOGRAPH
> 0x949C 0x654E #CJK UNIFIED IDEOGRAPH
> 0xBDCC 0x6559 #CJK UNIFIED IDEOGRAPH
>
> And for "Shift-JIS", Code Page 932 Japanese:
>
> 0xEDE4 0x6DF8 #CJK UNIFIED IDEOGRAPH
> 0xFB43 0x6DF8 #CJK UNIFIED IDEOGRAPH
> 0x90B4 0x6E05 #CJK UNIFIED IDEOGRAPH
> 0xE1C1 0x771E #CJK UNIFIED IDEOGRAPH
> 0x905E 0x771F #CJK UNIFIED IDEOGRAPH
> 0xEDB1 0x654E #CJK UNIFIED IDEOGRAPH
> 0xFACD 0x654E #CJK UNIFIED IDEOGRAPH
> 0x8BB3 0x6559 #CJK UNIFIED IDEOGRAPH
>
> So if you are working on a Windows system in either of
> these legacy code pages, in China or Japan, you
> already have the same options for representational
> ambiguity, without invoking Unicode at all.
           Right,  that is the problem of these legacy code pages, but these
sripts are used in printing of publication or electronic books which do not
need to differentiate them precisiely. That is  not working as a name
identifier.
           Even now, CJK area have not enough experience to use their
characters as the  ML-domain name under ccTLD,  using mixed characters in
gTLD will be  a big march in DNS history.

L.M.Tseng




From owner-idn@ops.ietf.org  Wed Feb  6 10:49: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 KAA23949
	for ; Wed, 6 Feb 2002 10:49:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YU5p-0006Mf-00
	for idn-data@psg.com; Wed, 06 Feb 2002 07:34:41 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YU5p-0006MZ-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 07:34:41 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net for ;
          Wed, 6 Feb 2002 07:50:27 -0800
Message-ID: <005901c1af25$36248ba0$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "IETF-IDN" 
References: 
Subject: Re: [idn] Internet Draft - Phased Implementation for IDNA
Date: Wed, 6 Feb 2002 10:44:48 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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

>Dear IETF IDN members,

>The attached draft  "Phased Implementation for IDNA" was submitted.
>You are welcome to commont on the draft.

The last call of the documents will end on Feb 11th 2002 (which
coincidentally is "Chinese New Year" by the way) so it is important
that we don't waste anymore time on things that have been discussed
over and over and over and over... and over again for the past 2
years.  Thanks to Kenny for coming up with the new proposal and
providing us with a basis to work with...

After reading the I-D, my question is-  Is it possible to modify the
Appendix B so that it *only* prohibits the "Simplified Chinese code
points" and allow all the rest to move forward?

Thanks,
Ben











From owner-idn@ops.ietf.org  Wed Feb  6 11:20: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 LAA24938
	for ; Wed, 6 Feb 2002 11:20:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YUfQ-00075d-00
	for idn-data@psg.com; Wed, 06 Feb 2002 08:11:28 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YUfP-00075I-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 08:11:28 -0800
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 IAA25877;
	Wed, 6 Feb 2002 08:10:19 -0800
Message-Id: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Feb 2002 08:02:45 -0800
To: Elisabeth Porteneuve 
From: Dave Crocker 
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Cc: deng@cnnic.net.cn, erin@twnic.net.tw, mclaughlin@pobox.com,
        Elisabeth.Porteneuve@cetp.ipsl.fr, Marc.Blanchet@viagenie.qc.ca,
        ajm@icann.org, alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk,
        fred@cisco.com, harald@alvestrand.no, hlqian@cnnic.net.cn,
        hoho@iis.sinica.edu.tw, htk@eecs.harvard.edu, huangk@alum.sinica.edu,
        iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo,
        jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com,
        lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn,
        mkatoh@mkatoh.net, mouhamet@next.sn, narten@us.ibm.com,
        nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org,
        qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw,
        vcerf@mci.net, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,
        wuch@gate.sinica.edu.tw, yktham@umac.mo
In-Reply-To: <200202061124.MAA01153@balsa.cetp.ipsl.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 03:35 AM 2/6/2002 -0800, Elisabeth Porteneuve wrote:
>Why this proposal cannot be taken into account by IETF IDN WG?

Elisabeth,

This entire topic, and all its proposals, have very much been taken into 
account by the IDN working group.  They have been taken into account at the 
cost of many months of delay, although this topic is actually outside the 
scope of the working group.

The topic calls for an algorithm that equates portions of different 
scripts.  This goes beyond the model of equating upper/lower case WITHIN a 
script.

In fact, this topic is an open research question with no generally accepted 
practise.  So even if the topic were within scope the solution would, at 
best, be very, very risky.

The risk is exacerbated by the fact that this technical approach does not 
scale well.  As soon as an approach like the TC/SC proposal is added, then 
we must find mappings for many, many other multi-script equivalences.  That 
effort will probably take years.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Wed Feb  6 12:22: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 MAA26249
	for ; Wed, 6 Feb 2002 12:22:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YVdy-0008KP-00
	for idn-data@psg.com; Wed, 06 Feb 2002 09:14:02 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YVdx-0008KE-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 09:14:01 -0800
Received: from MASTER ([210.217.27.236])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g16HBWR25056;
	Thu, 7 Feb 2002 02:11:33 +0900
Message-ID: <005501c1af31$5c4ad170$ec1bd9d2@temp>
From: "Soobok Lee" 
To: "Elisabeth Porteneuve" ,
        "Dave Crocker" 
Cc: , , ,
        , ,
        , ,
        , ,
        , ,
        , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , ,
        , 
References: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1>
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Date: Thu, 7 Feb 2002 02:11: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: "Dave Crocker" 
> Elisabeth,
>
> This entire topic, and all its proposals, have very much been taken into
> account by the IDN working group.  They have been taken into account at the
> cost of many months of delay, although this topic is actually outside the
> scope of the working group.
>
> The topic calls for an algorithm that equates portions of different
> scripts.  This goes beyond the model of equating upper/lower case WITHIN a
> script.

No. You are maybe pointing to my half-baked draft "look-alike normaliation + multicase ACE equivalence encoding ACROSS
cyrillic/greek/latin script",  not to CDNC's TSCONV-02 draft which attempts to
add  TC/SC 1:1 equivalence WITHIN the unified Han script block by borrowing the suggested framework briefed in my pre-draft. That
may let you mix up the two. TSCONV-02 is succeeded by TSCONV-03 that
takes brand new validation-based TC/SC filtering approach.


>
> In fact, this topic is an open research question with no generally accepted
> practise.  So even if the topic were within scope the solution would, at
> best, be very, very risky.
>
> The risk is exacerbated by the fact that this technical approach does not
> scale well.  As soon as an approach like the TC/SC proposal is added, then
> we must find mappings for many, many other multi-script equivalences.  That
> effort will probably take years.

True. There are a huge set of "look-similar" equivalences in Unicode!  But, fortunately,
we have a  much smaller set of "look-identical" equivalences. for example, the size
of each set of equivalent cyrillic/gree/cherokee/latin characters is relatively small,
and the equivalent pairs are more easily found   than 'look-similar' ones.
If we restrict the problem space into the 'look-identical' equivalence,
we will reach the ideal goal  faster and we can avoid the scalability problem
in the proposed multicase encoding.

As for "look-similar" characters, we can recommend new disambiguating font sets for
IDN represenations. For LDH domains, we have already some font sets which
have '0' in slashed-zero shape to be easily distinguished from alphabet 'o'.

Soobok Lee

>
> d/
>
>
> ----------
> Dave Crocker  
> Brandenburg InternetWorking  
> tel +1.408.246.8253;  fax +1.408.273.6464
>




From owner-idn@ops.ietf.org  Wed Feb  6 17:28: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 RAA04306
	for ; Wed, 6 Feb 2002 17:28:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaKJ-000FU9-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:14:03 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
  by psg.com with esmtp (Exim 3.33 #1)
  id 16YY5V-000CZu-00
  for idn@ops.ietf.org; Wed, 06 Feb 2002 11:50:37 -0800
Received: from kp02 (kp02 [140.109.18.202])
  by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16JjiT05829
  for ; Thu, 7 Feb 2002 03:45:44 +0800 (CST)
From: "Hung-Yu Kao" 
To: 
Subject: [idn] Please do not pass an IDN document which you know will cause
   conflicts and chaos
Date: Thu, 7 Feb 2002 03:44:07 +0800
Message-ID: <000301c1af46$a3a8ba40$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGvRqOouZiZV2pbQLOb/SJ7P2t7dA==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA04306

[Note: there is a series of emails with the exact same content originated
from iis.sinica.edu.tw. I will continue to bounce it to the list until
someone ask me to stop - JS]

Ive recently come to know that IETF is about to release drafts on IDN standards, and to my regret, I found that the document does not solve problems for Chinese domain names.  And this defect in your drafts will result conflicts and chaos for Internet users of Han characters, namely Chinese, Korean and Japanese, and the effect is international because users of these languages are all over the world.

It is important to know that while a certain character can have different appearance in Simplified Chinese and Traditional Chinese Character forms even though they are actually same words with the same meaning; at the same time, a certain character which might look exactly the same, but in fact are two different words with different meaning when applied to different languages such as Chinese and Japanese.  I believe that IETF bears great responsible in setting standards which will bring order to the Internet world, and any document which might cause disorder, should be carefully reconsidered before release.  Therefore, Before IETF can resolve this problem and identify one mechanism which can differentiate these delicate language difference, IETF should not pass the document which would apply Unicode for IDN resolution, because this irresponsible decision is going to cause conflicts and chaos in DN registration policy and DRP worldwide.


Hung-Yu Kao
bobby@iis.sinica.edu.tw
IIS, Academia Sinica






From owner-idn@ops.ietf.org  Wed Feb  6 17:29: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 RAA04337
	for ; Wed, 6 Feb 2002 17:29:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaIM-000FPs-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:12:02 -0800
Received: from smtp24.singnet.com.sg ([165.21.101.204])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YaIL-000FPm-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 14:12:02 -0800
Received: from jamescompaq (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp24.singnet.com.sg (8.12.2/8.12.2) with SMTP id g16MFaWS000723
	for ; Thu, 7 Feb 2002 06:15:36 +0800
Message-ID: <005101c1af59$87fdec80$0701000a@jamescompaq>
From: "James Seng/Personal" 
To: 
Subject: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission from ["Chien-Ming Tseng" ]   
Date: Thu, 7 Feb 2002 05:59:21 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
  by psg.com with esmtp (Exim 3.33 #1)
  id 16YWSm-000ANp-00
  for idn@ops.ietf.org; Wed, 06 Feb 2002 10:06:32 -0800
Received: from kp02 (kp02 [140.109.18.202])
  by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16I1kT29647
  for ; Thu, 7 Feb 2002 02:01:46 +0800 (CST)
From: "Chien-Ming Tseng" 
To: 
Subject: PROTEST! RESCUE CHINESE DOMAIN NAMES.
Date: Thu, 7 Feb 2002 02:00:08 +0800
Message-ID: <000101c1af38$1cfb38a0$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain;
charset="big5"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGvOBz7QVK67ou/S0q9KfWj/a4AMQ==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300

[Note: there is a series of emails with the exact same content originated
from iis.sinica.edu.tw. I will continue to bounce it to the list until
someone ask me to stop - JS]

PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han character variants, also known as equivalent Chinese =
characters, exists in Unicode. A Chinese domain name thus usually has =
many different Unicode representations. As Unicode evolves, more CJK Han =
characters are added to Unicode. It also increases the number of =
variants of a character and the number of characters with variants, and =
thus the number of Unicode representations per Chinese domain name. =20

Though it meets the needs for internationalized domain name of those =
people who uses phonetic characters. However, a Chinese domain name =
service based on IDN WG technology is defective.

We urge the working group to seriously take these cultural differences =
into account. Do not finalize IDN documents without minimizing their =
negative impacts against Chinese domain names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!






Chien-Ming Tseng
curtain_tseng@hotmail.com
National Cheng Kung University, Taiwan, ROC






From owner-idn@ops.ietf.org  Wed Feb  6 17:31: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 RAA04369
	for ; Wed, 6 Feb 2002 17:31:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaIZ-000FQD-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:12:15 -0800
Received: from smtp22.singnet.com.sg ([165.21.101.202])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YaIY-000FQ7-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 14:12:14 -0800
Received: from jamescompaq (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g16MC7Qr004080
	for ; Thu, 7 Feb 2002 06:12:07 +0800
Message-ID: <005201c1af59$8c488e80$0701000a@jamescompaq>
From: "James Seng/Personal" 
To: 
Subject: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission from ["Chien-Ming Tseng" ]   
Date: Thu, 7 Feb 2002 05:59:28 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
  by psg.com with esmtp (Exim 3.33 #1)
  id 16YWSm-000ANp-00
  for idn@ops.ietf.org; Wed, 06 Feb 2002 10:06:32 -0800
Received: from kp02 (kp02 [140.109.18.202])
  by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16I1kT29647
  for ; Thu, 7 Feb 2002 02:01:46 +0800 (CST)
From: "Chien-Ming Tseng" 
To: 
Subject: PROTEST! RESCUE CHINESE DOMAIN NAMES.
Date: Thu, 7 Feb 2002 02:00:08 +0800
Message-ID: <000101c1af38$1cfb38a0$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGvOBz7QVK67ou/S0q9KfWj/a4AMQ==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300

[Note: there is a series of emails with the exact same content originated
from iis.sinica.edu.tw. I will continue to bounce it to the list until
someone ask me to stop - JS]

PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han character variants, also known as equivalent Chinese =
characters, exists in Unicode. A Chinese domain name thus usually has =
many different Unicode representations. As Unicode evolves, more CJK Han =
characters are added to Unicode. It also increases the number of =
variants of a character and the number of characters with variants, and =
thus the number of Unicode representations per Chinese domain name. =20

Though it meets the needs for internationalized domain name of those =
people who uses phonetic characters. However, a Chinese domain name =
service based on IDN WG technology is defective.

We urge the working group to seriously take these cultural differences =
into account. Do not finalize IDN documents without minimizing their =
negative impacts against Chinese domain names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!






Chien-Ming Tseng
curtain_tseng@hotmail.com
National Cheng Kung University, Taiwan, ROC






From owner-idn@ops.ietf.org  Wed Feb  6 17:31: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 RAA04370
	for ; Wed, 6 Feb 2002 17:31:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaG0-000FLp-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:09:36 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
  by psg.com with esmtp (Exim 3.33 #1)
  id 16YXpY-000CF8-00
  for idn@ops.ietf.org; Wed, 06 Feb 2002 11:34:08 -0800
Received: from kp02 (kp02 [140.109.18.202])
  by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16JTLT00068
  for ; Thu, 7 Feb 2002 03:29:21 +0800 (CST)
From: "Hsin-Hung Chou" 
To: 
Subject: [idn] PROTEST! RESCUE CHINESE DOMAIN NAMES.
Date: Thu, 7 Feb 2002 03:27:43 +0800
Message-ID: <000201c1af44$5928af40$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGvRFkom+OlSvMAQX+0tGr76vwCqg==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA04370

[Note: there is a series of emails with the exact same content originated
from iis.sinica.edu.tw. I will continue to bounce it to the list until
someone ask me to stop - JS]

PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han character variants, also known as equivalent Chinese characters, exists in Unicode. A Chinese domain name thus usually has many different Unicode representations. As Unicode evolves, more CJK Han characters are added to Unicode. It also increases the number of variants of a character and the number of characters with variants, and thus the number of Unicode representations per Chinese domain name.  

Though it meets the needs for internationalized domain name of those people who uses phonetic characters. However, a Chinese domain name service based on IDN WG technology is defective.

We urge the working group to seriously take these cultural differences into account. Do not finalize IDN documents without minimizing their negative impacts against Chinese domain names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!







From owner-idn@ops.ietf.org  Wed Feb  6 17:31: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 RAA04392
	for ; Wed, 6 Feb 2002 17:31:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaHa-000FNk-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:11:14 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
  by psg.com with esmtp (Exim 3.33 #1)
  id 16YWRj-000ALw-00
  for idn@ops.ietf.org; Wed, 06 Feb 2002 10:05:28 -0800
Received: from kp02 (kp02 [140.109.18.202])
  by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16I0eT29277
  for ; Thu, 7 Feb 2002 02:00:40 +0800 (CST)
From: "Chien-Ming Tseng" 
To: 
Subject: [idn] Please do not pass an IDN document which you know will cause
Message-Id: 
Date: Wed, 06 Feb 2002 14:11:14 -0800

conflicts and chaos
Date: Thu, 7 Feb 2002 01:59:02 +0800
Message-ID: <000001c1af37$f59884c0$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGvN/WY/WNAgmvTTFSxkhNnz2j0KA==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Note: there is a series of emails with the exact same content originated
from iis.sinica.edu.tw. I will continue to bounce it to the list until
someone ask me to stop - JS]

I=A1=A6ve recently come to know that IETF is about to release drafts on =
IDN standards, and to my regret, I found that the document does not =
solve problems for Chinese domain names.  And this defect in your drafts =
will result conflicts and chaos for Internet users of Han characters, =
namely Chinese, Korean and Japanese, and the effect is international =
because users of these languages are all over the world.

It is important to know that while a certain character can have =
different appearance in Simplified Chinese and Traditional Chinese =
Character forms even though they are actually same words with the same =
meaning; at the same time, a certain character which might look exactly =
the same, but in fact are two different words with different meaning =
when applied to different languages such as Chinese and Japanese.  I =
believe that IETF bears great responsible in setting standards which =
will bring order to the Internet world, and any document which might =
cause disorder, should be carefully reconsidered before release.  =
Therefore, Before IETF can resolve this problem and identify one =
mechanism which can differentiate these delicate language difference, =
IETF should not pass the document which would apply Unicode for IDN =
resolution, because this irresponsible decision is going to cause =
conflicts and chaos in DN registration policy and DRP worldwide.


Chien-Ming Tseng
curtain_tseng@hotmail.com
National Cheng Kung University, Taiwan, ROC






From owner-idn@ops.ietf.org  Wed Feb  6 17:35: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 RAA04447
	for ; Wed, 6 Feb 2002 17:35:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaJI-000FRu-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:13:00 -0800
Received: from smtp21.singnet.com.sg ([165.21.101.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YaJH-000FRl-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 14:13:00 -0800
Received: from jamescompaq (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g16MCvWh022690
	for ; Thu, 7 Feb 2002 06:12:57 +0800
Message-ID: <005801c1af59$aa2b5040$0701000a@jamescompaq>
From: "James Seng/Personal" 
To: 
Subject: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission from ["Hsin-Hung Chou" ]   
Date: Thu, 7 Feb 2002 06:00:18 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
  by psg.com with esmtp (Exim 3.33 #1)
  id 16YXpY-000CF8-00
  for idn@ops.ietf.org; Wed, 06 Feb 2002 11:34:08 -0800
Received: from kp02 (kp02 [140.109.18.202])
  by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16JTLT00068
  for ; Thu, 7 Feb 2002 03:29:21 +0800 (CST)
From: "Hsin-Hung Chou" 
To: 
Subject: PROTEST! RESCUE CHINESE DOMAIN NAMES.
Date: Thu, 7 Feb 2002 03:27:43 +0800
Message-ID: <000201c1af44$5928af40$ca126d8c@iis.sinica.edu.tw>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcGvRFkom+OlSvMAQX+0tGr76vwCqg==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300

[Note: there is a series of emails with the exact same content originated
from iis.sinica.edu.tw. I will continue to bounce it to the list until
someone ask me to stop - JS]

PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han character variants, also known as equivalent Chinese =
characters, exists in Unicode. A Chinese domain name thus usually has =
many different Unicode representations. As Unicode evolves, more CJK Han =
characters are added to Unicode. It also increases the number of =
variants of a character and the number of characters with variants, and =
thus the number of Unicode representations per Chinese domain name. =20

Though it meets the needs for internationalized domain name of those =
people who uses phonetic characters. However, a Chinese domain name =
service based on IDN WG technology is defective.

We urge the working group to seriously take these cultural differences =
into account. Do not finalize IDN documents without minimizing their =
negative impacts against Chinese domain names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!






Hsin-Hung Chou
d6526005@csie.ntu.edu.tw
National Taiwan University






From owner-idn@ops.ietf.org  Wed Feb  6 17:39: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 RAA04480
	for ; Wed, 6 Feb 2002 17:39:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YaUH-000Fm8-00
	for idn-data@psg.com; Wed, 06 Feb 2002 14:24:21 -0800
Received: from 66.123.187.68.ar.com ([66.123.187.68] helo=bean.ar.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YaUG-000Fm2-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 14:24:20 -0800
Received: from loki (IDENT:wessorh@loki [66.123.187.67])
	by bean.ar.com (8.12.0/8.12.0) with ESMTP id g16MOAU1003668;
	Wed, 6 Feb 2002 14:24:10 -0800 (PST)
Date: Wed, 6 Feb 2002 14:24:10 -0800 (PST)
From: Rick H Wesson 
To: James Seng/Personal 
cc: 
Subject: Re: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission from
 ["Hsin-Hung Chou" ]   
In-Reply-To: <005801c1af59$aa2b5040$0701000a@jamescompaq>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


James,

could you ask the posters to include specific issues not already addressed
by the working group. Just protesting dirring a last call doesn't help us
identify way to improve the documents.

Just protesting doesn't count, if an alternative or fix is't included in
how to fix the idn documents.

-rick


On Thu, 7 Feb 2002, James Seng/Personal wrote:

> Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
>   by psg.com with esmtp (Exim 3.33 #1)
>   id 16YXpY-000CF8-00
>   for idn@ops.ietf.org; Wed, 06 Feb 2002 11:34:08 -0800
> Received: from kp02 (kp02 [140.109.18.202])
>   by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g16JTLT00068
>   for ; Thu, 7 Feb 2002 03:29:21 +0800 (CST)
> From: "Hsin-Hung Chou" 
> To: 
> Subject: PROTEST! RESCUE CHINESE DOMAIN NAMES.
> Date: Thu, 7 Feb 2002 03:27:43 +0800
> Message-ID: <000201c1af44$5928af40$ca126d8c@iis.sinica.edu.tw>
> MIME-Version: 1.0
> Content-Type: text/plain; charset="big5"
> Content-Transfer-Encoding: quoted-printable
> X-Mailer: Microsoft CDO for Windows 2000
> Thread-Index: AcGvRFkom+OlSvMAQX+0tGr76vwCqg==
> Content-Class: urn:content-classes:message
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
>
> [Note: there is a series of emails with the exact same content originated
> from iis.sinica.edu.tw. I will continue to bounce it to the list until
> someone ask me to stop - JS]
>
> PROTEST! RESCUE CHINESE DOMAIN NAMES.
>
> Many Han character variants, also known as equivalent Chinese =
> characters, exists in Unicode. A Chinese domain name thus usually has =
> many different Unicode representations. As Unicode evolves, more CJK Han =
> characters are added to Unicode. It also increases the number of =
> variants of a character and the number of characters with variants, and =
> thus the number of Unicode representations per Chinese domain name. =20
>
> Though it meets the needs for internationalized domain name of those =
> people who uses phonetic characters. However, a Chinese domain name =
> service based on IDN WG technology is defective.
>
> We urge the working group to seriously take these cultural differences =
> into account. Do not finalize IDN documents without minimizing their =
> negative impacts against Chinese domain names.
>
> DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!
>
>
>
>
>
>
> Hsin-Hung Chou
> d6526005@csie.ntu.edu.tw
> National Taiwan University
>
>
>
>




From owner-idn@ops.ietf.org  Wed Feb  6 18:12: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 SAA04871
	for ; Wed, 6 Feb 2002 18:12:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yb7A-000Gr5-00
	for idn-data@psg.com; Wed, 06 Feb 2002 15:04:32 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yb79-000Gqj-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 15:04:31 -0800
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 PAA10245;
	Wed, 6 Feb 2002 15:01:46 -0800
Message-Id: <5.1.0.14.2.20020206145759.02534e38@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Feb 2002 15:00:41 -0800
To: "Edward Chuang" 
From: Dave Crocker 
Subject: Re: [idn] Please do not pass an IDN document which you know
  will cause conflicts and chaos
Cc: 
In-Reply-To: <000601c1addd$5c7454f0$ca126d8c@iis.sinica.edu.tw>
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 SAA04871

At 08:37 AM 2/5/2002 +0800, Edward Chuang wrote:
>Ive recently come to know that IETF is about to release drafts on
>IDN standards, and to my regret, I found that the document does not solve 
>problems for Chinese domain names.  And this defect in your drafts

Please review the working group email archive.  It has considered this 
topic extensively.  When you can a) provide explanation for the specific 
failures to the working group discussion, and b) a viable specification for 
solving this open research topic, there might be something to talk about.

The solution you seek can be added to registry administrative policy later.

Until then, please consider that further delay means that there is no 
standardized DNS support at all for any characters other than ASCII.

Please consider whether it is better to wait years for a perfect, complete 
solution, or whether it is better to do something useful sooner.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Wed Feb  6 18:39: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 SAA05131
	for ; Wed, 6 Feb 2002 18:39:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YbVB-000HSW-00
	for idn-data@psg.com; Wed, 06 Feb 2002 15:29:21 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16YbVA-000HSQ-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 15:29:20 -0800
Received: (qmail 28334 invoked by uid 1001); 6 Feb 2002 23:28:18 -0000
Date: 6 Feb 2002 23:28:18 -0000
Message-ID: <20020206232818.31484.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Alpha Online
References: <20020206002500.1211.qmail@cr.yp.to> <5.1.0.14.2.20020205182353.035b5038@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

The question remains: Will an Alpha Online organization be allowed to
register qol.com, with q changed to a lowercase alpha?

Or will ICANN take the domain name away and give it to AOL, because the
uppercase version of the name is visually identical to AOL.COM? Is it
okay if Alpha Online never uses the uppercase version of the name, and
client software doesn't automatically convert names to uppercase?

The question is whether case insensitivity will---beyond imposing huge
software costs and creating huge new opportunities for fraud---prevent
legitimate users from registering perfectly reasonable domain names.

Dave Crocker writes:
> predictions about trademark disputes are best left to experienced
> trademark attorneys.

I will readily agree that the exact definition of ``likelihood of
confusion'' in trademark law is beyond your legal experience. However,
I'm sure you can grasp the fact that the picture

   AOL.COM

has a conflict with the identical picture

   AOL.COM

even though one of the A's is represented inside a computer as the Latin
A while the other one is represented as the Greek Alpha.

---Dan



From owner-idn@ops.ietf.org  Wed Feb  6 19:21: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 TAA05526
	for ; Wed, 6 Feb 2002 19:21:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yc8I-000IQp-00
	for idn-data@psg.com; Wed, 06 Feb 2002 16:09:46 -0800
Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yc8H-000IQj-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 16:09:45 -0800
Received: from admsrvnt02.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101])
	by sharplabs.com (8.9.1/8.9.2) with ESMTP id QAA19707;
	Wed, 6 Feb 2002 16:06:10 -0800 (PST)
Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19)
	id <1MDRWAH0>; Wed, 6 Feb 2002 16:09:16 -0800
Message-ID: <116DB56CD7DED511BC7800508B2CA5370A18F6@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" 
To: "'D. J. Bernstein'" , idn@ops.ietf.org
Subject: RE: [idn] Alpha Online
Date: Wed, 6 Feb 2002 16:09:14 -0800 
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

Hi,

My two cents...

There are lots of postings here (I just rejoined this mailing list)
presuming that case sensitive domain names are reasonable or even
desirable.

Yet RFC 1035 "Domain Names - Implementation and Specification" says
(on page 8):

    Note that while upper and lower case letters are allowed in domain
    names, no significance is attached to the case.  That is, two names with
    the same spelling but different case are to be treated as if identical.

And RFC 2616 "HTTP/1.1" in section 3.2.3 "URI Comparison says 
(on page 20):

    When comparing two URIs to decide if they match or not, a client
    SHOULD use a case-sensitive octet-by-octet comparison of the entire
    URIs, with these exceptions:

       - A port that is empty or not given is equivalent to the default
         port for that URI-reference;

>>>>     - Comparisons of host names MUST be case-insensitive;

         - Comparisons of scheme names MUST be case-insensitive;

         - An empty abs_path is equivalent to an abs_path of "/".

It's likely that the attempt to retroactively introduce case sensitive
domain names will simply break almost all deployed Internet software.

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: D. J. Bernstein [mailto:djb@cr.yp.to]
Sent: Wednesday, February 06, 2002 5:28 PM
To: idn@ops.ietf.org
Subject: Re: [idn] Alpha Online


The question remains: Will an Alpha Online organization be allowed to
register qol.com, with q changed to a lowercase alpha?

Or will ICANN take the domain name away and give it to AOL, because the
uppercase version of the name is visually identical to AOL.COM? Is it
okay if Alpha Online never uses the uppercase version of the name, and
client software doesn't automatically convert names to uppercase?

The question is whether case insensitivity will---beyond imposing huge
software costs and creating huge new opportunities for fraud---prevent
legitimate users from registering perfectly reasonable domain names.

Dave Crocker writes:
> predictions about trademark disputes are best left to experienced
> trademark attorneys.

I will readily agree that the exact definition of ``likelihood of
confusion'' in trademark law is beyond your legal experience. However,
I'm sure you can grasp the fact that the picture

   AOL.COM

has a conflict with the identical picture

   AOL.COM

even though one of the A's is represented inside a computer as the Latin
A while the other one is represented as the Greek Alpha.

---Dan



From owner-idn@ops.ietf.org  Wed Feb  6 20:07: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 UAA05969
	for ; Wed, 6 Feb 2002 20:07:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ycu8-000JeX-00
	for idn-data@psg.com; Wed, 06 Feb 2002 16:59:12 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Ycu7-000JeQ-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 16:59:11 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id QAA11700
	for ; Wed, 6 Feb 2002 16:59:00 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id QAA16939
	for ; Wed, 6 Feb 2002 16:59:10 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id QAA16920;
	Wed, 6 Feb 2002 16:59:09 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id QAA22474;
	Wed, 6 Feb 2002 16:58:09 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id QAA01717;
	Wed, 6 Feb 2002 16:59:01 -0800 (PST)
Date: Wed, 6 Feb 2002 16:59:01 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202070059.QAA01717@birdie.sybase.com>
To: djb@cr.yp.to
Subject: Re: [idn] Alpha Online
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> The question remains: Will an Alpha Online organization be allowed to
> register qol.com, with q changed to a lowercase alpha?
> 
> Or will ICANN take the domain name away and give it to AOL, because the
> uppercase version of the name is visually identical to AOL.COM? 

Well, they apparently haven't taken away A0L.COM, which seems to
belong to DomainSource.com, Inc. and which has a website www.A0L.COM
which one would surmise is not just an accidental string of letters. :-)

> The question is whether case insensitivity will---beyond imposing huge
> software costs and creating huge new opportunities for fraud---prevent
> legitimate users from registering perfectly reasonable domain names.

And the answer is no.

Furthermore, it is far more likely that if the various domain
registrants seek to register ol.com, it is they themselves
who may be fraudulently seeking to confuse their identity with aol.com.

The *reasonable* registrants among them will continue to seek
reasonably differentiated and nonconfusing domain names, as they
have in the past:

alpha-online.ch   Alpha Online Der Kadermarkt der Schweiz
alpha-online.org  Alpha Internetbetreuung
aoberlin.de       Alpha Online Berlin
alphaonlinepower.com   Alpha Online Power
alpha.musicpage.com    Alpha Online (a progressive rock band)

--Ken




From owner-idn@ops.ietf.org  Wed Feb  6 20:13: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 UAA06007
	for ; Wed, 6 Feb 2002 20:13:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YcqC-000JWY-00
	for idn-data@psg.com; Wed, 06 Feb 2002 16:55:08 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YcqA-000JWS-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 16:55:07 -0800
Received: from MASTER ([210.217.27.236])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g170pNR28588;
	Thu, 7 Feb 2002 09:51:23 +0900
Message-ID: <00df01c1af71$869dac50$ec1bd9d2@temp>
From: "Soobok Lee" 
To: "Edward Chuang" ,
        "Dave Crocker" 
Cc: 
References: <5.1.0.14.2.20020206145759.02534e38@127.0.0.1>
Subject: Re: [idn] Please do not pass an IDN document which you know  will cause conflicts and chaos
Date: Thu, 7 Feb 2002 09:51: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: "Dave Crocker" 
> Until then, please consider that further delay means that there is no
> standardized DNS support at all for any characters other than ASCII.
>
> Please consider whether it is better to wait years for a perfect, complete
> solution,

Sorry. Premature IDN solutions ,if ever issued, will last for several decades .
If just a few years of more work could give us perfect IDN solutions including TSCONV,
I'm willing to be patient living only with IDN testbed registrations or
alternative directory/search solutions which address the need for
internationalized *ACCESS* to LDH domain names. that's enough to today's
needs.

> or whether it is better to do something useful sooner.
>

Solving unresolved IDN issues using Registratation policies above IDN
doesn't remove the apparent serious problem of application-side matching failures.
Policies can guarantee the ownership by the same registrant, but cannot guarantee
the universal identifer equivalence across the entire internet and applications.

Moreover, it is not scalable in general.
disputes resolution processes or zone admin's inspections for IDN-vs-IDN and IDN-vs-LDH RR
conflicts will explode and they will consume very precious time and resources
from zone admins and end users and therefore, they are not scalable to huge zones
and the general public. Dynamic RR insertion/updates features should be turned off
for the fear of introducing new conflicting RR.

The concept of IDN itself has been challenged repeatedly.
When end users - most of them is unilingual or at most bilingual if gifted -
are exposed to exotic IDN labels, the level of confusions and difficulties
will be great but are not measured and researched sufficiently.
Even after more than one century from the invention of telephone networks,
we still have digits-only phone numbers.

Enen though this may looks somewhat drastic and ironic,
If domain names are to be truely *international*, the basic lexical atoms of the domain labels
should be remained as LDH set, the greatest common denominator of characters and scripts used by modern civilized language groups.
LDH is the true IDN, and the "IDN" that we discuss  had better be renamed to LDN (localized domain names) that have requirements to
be internationally interoperable by
machines and human beings but not satisfied.

Soobok Lee





From owner-idn@ops.ietf.org  Wed Feb  6 20:13: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 UAA06020
	for ; Wed, 6 Feb 2002 20:13:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yczg-000Jmx-00
	for idn-data@psg.com; Wed, 06 Feb 2002 17:04:56 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yczf-000Jmk-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 17:04:55 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g1714SU01333
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Thu, 7 Feb 2002 09:04:29 +0800 (CST)
Message-ID: <000601c1af73$076bf520$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= 
To: "McDonald, Ira" ,
        "'D. J. Bernstein'" , 
References: <116DB56CD7DED511BC7800508B2CA5370A18F6@mailsrvnt02.enet.sharplabs.com>
Subject: Re: [idn] Alpha Online
Date: Thu, 7 Feb 2002 09:01:45 +0800
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

Hi ! All:
              I think there are some confusing in here.
1.People using non-ASCII want their non-ASCII characters after ACE encoding
can keep the information of  original character case in the
ASCII-ACE-STRING.
2.The alphabet case of ASCII-ACE-STRING can be preserved and keep in
communication .
3.The comparison of  ASCII-ACE-STRING is still case insensitive in DNS and
URI.
4.That is say to do ASCII-STRING comparison in DNS or URI must forced the
ASCII-ACE-STRING to lower case and can not be recovering of these original
information FOREVER  is over requirement/specification.
5.No one want to violate the backward compatibility of DNS and URI.

L.M.Tseng
> There are lots of postings here (I just rejoined this mailing list)
> presuming that case sensitive domain names are reasonable or even
> desirable.
>
> Yet RFC 1035 "Domain Names - Implementation and Specification" says
> (on page 8):
>
>     Note that while upper and lower case letters are allowed in domain
>     names, no significance is attached to the case.  That is, two names
with
>     the same spelling but different case are to be treated as if
identical.
>
> And RFC 2616 "HTTP/1.1" in section 3.2.3 "URI Comparison says
> (on page 20):
>
>     When comparing two URIs to decide if they match or not, a client
>     SHOULD use a case-sensitive octet-by-octet comparison of the entire
>     URIs, with these exceptions:
>
>        - A port that is empty or not given is equivalent to the default
>          port for that URI-reference;
>
> >>>>     - Comparisons of host names MUST be case-insensitive;
>
>          - Comparisons of scheme names MUST be case-insensitive;
>
>          - An empty abs_path is equivalent to an abs_path of "/".
>
> It's likely that the attempt to retroactively introduce case sensitive
> domain names will simply break almost all deployed Internet software.
>
> Cheers,
> - Ira McDonald
>   High North Inc
>
>
> -----Original Message-----
> From: D. J. Bernstein [mailto:djb@cr.yp.to]
> Sent: Wednesday, February 06, 2002 5:28 PM
> To: idn@ops.ietf.org
> Subject: Re: [idn] Alpha Online
>
>
> The question remains: Will an Alpha Online organization be allowed to
> register qol.com, with q changed to a lowercase alpha?
>
> Or will ICANN take the domain name away and give it to AOL, because the
> uppercase version of the name is visually identical to AOL.COM? Is it
> okay if Alpha Online never uses the uppercase version of the name, and
> client software doesn't automatically convert names to uppercase?
>
> The question is whether case insensitivity will---beyond imposing huge
> software costs and creating huge new opportunities for fraud---prevent
> legitimate users from registering perfectly reasonable domain names.
>
> Dave Crocker writes:
> > predictions about trademark disputes are best left to experienced
> > trademark attorneys.
>
> I will readily agree that the exact definition of ``likelihood of
> confusion'' in trademark law is beyond your legal experience. However,
> I'm sure you can grasp the fact that the picture
>
>    AOL.COM
>
> has a conflict with the identical picture
>
>    AOL.COM
>
> even though one of the A's is represented inside a computer as the Latin
> A while the other one is represented as the Greek Alpha.
>
> ---Dan
>




From owner-idn@ops.ietf.org  Wed Feb  6 20:19: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 UAA06100
	for ; Wed, 6 Feb 2002 20:19:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yd4X-000Jz9-00
	for idn-data@psg.com; Wed, 06 Feb 2002 17:09:57 -0800
Received: from friendly.realnames.com ([63.251.238.102])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Yd4X-000Jz2-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 17:09:57 -0800
Received: (qmail 23456 invoked by uid 104); 7 Feb 2002 01:09:56 -0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.832084 secs); 07 Feb 2002 01:09:56 -0000
Received: from heaven.internal.realnames.com (10.1.5.39)
  by friendly.realnames.com with SMTP; 7 Feb 2002 01:09:54 -0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1948]) by heaven.internal.realnames.com
	Mail essentials (server 2.422) with SMTP id: <253673@heaven.internal.realnames.com>
	 for ; Wed, 6 Feb 2002 5:05:37 PM -0800
	smtpmailfrom  
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 6 Feb 2002 17:09:46 -0800
Message-ID: <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>
From: Yves Arrouye 
To: idn@ops.ietf.org
Subject: RE: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Date: Wed, 6 Feb 2002 17:07:07 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Is it just me (having just browsed through that), or is the new prohibited
table looking strange? It starts with:

0000-0020
007F
0080-009F

so a bunch of ASCII characters are not prohibited anymore. For instance, the
name $$$.com is now allowed. It may be that one expects IDN applications to
do more checks than just Nameprep (for example, check for non-ASCII
characters first), but then why bother with the 0000-0020 and 007F, right?
Anyway, with this, a simple implementation of IDN that relies on the
Nameprep tables only to determine whether a label can be encoded or not,
will allow $$$.com, which isn't changed at all by Punycode.

YA

gabier% ./npdiff -u --name nameprep-06 --name nameprep-07
--- /tmp/npdiff.1716.1  Wed Feb  6 13:37:54 2002
+++ /tmp/npdiff.1716.2  Wed Feb  6 13:37:55 2002
@@ -1367,11 +1367,8 @@
 ----- End Mapping Table -----
 
 ----- Start Prohibited Table -----
-0000-002C
-002E-002F
-003A-0040
-005B-0060
-007B-00A0
+0000-0020
+007F-00A0
 070F
 1680
 180E
gabier% 

In the following, all the characters starting with a - have been removed
from the prohibited table, and are thus allowed by Nameprep.

gabier% ./npdiff -u --name nameprep-06 --name nameprep-07 --char-names
--- /tmp/npdiff.1784.1  Wed Feb  6 13:39:12 2002
+++ /tmp/npdiff.1784.2  Wed Feb  6 13:39:23 2002
@@ -1400,37 +1400,6 @@
 001E 
 001F 
 0020 SPACE
-0021 EXCLAMATION MARK
-0022 QUOTATION MARK
-0023 NUMBER SIGN
-0024 DOLLAR SIGN
-0025 PERCENT SIGN
-0026 AMPERSAND
-0027 APOSTROPHE
-0028 LEFT PARENTHESIS
-0029 RIGHT PARENTHESIS
-002A ASTERISK
-002B PLUS SIGN
-002C COMMA
-002E FULL STOP
-002F SOLIDUS
-003A COLON
-003B SEMICOLON
-003C LESS-THAN SIGN
-003D EQUALS SIGN
-003E GREATER-THAN SIGN
-003F QUESTION MARK
-0040 COMMERCIAL AT
-005B LEFT SQUARE BRACKET
-005C REVERSE SOLIDUS
-005D RIGHT SQUARE BRACKET
-005E CIRCUMFLEX ACCENT
-005F LOW LINE
-0060 GRAVE ACCENT
-007B LEFT CURLY BRACKET
-007C VERTICAL LINE
-007D RIGHT CURLY BRACKET
-007E TILDE
 007F 
 0080 
 0081 
gabier%



From owner-idn@ops.ietf.org  Wed Feb  6 20:34: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 UAA06426
	for ; Wed, 6 Feb 2002 20:34:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YdFn-000KKp-00
	for idn-data@psg.com; Wed, 06 Feb 2002 17:21:35 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YdFm-000KKU-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 17:21:34 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g171LT309402
	for ; Wed, 6 Feb 2002 17:21:29 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <20020206232818.31484.qmail@cr.yp.to>
References: <20020206002500.1211.qmail@cr.yp.to>
 <5.1.0.14.2.20020205182353.035b5038@127.0.0.1>
 <20020206232818.31484.qmail@cr.yp.to>
Date: Wed, 6 Feb 2002 17:20:22 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: Re: [idn] Alpha Online
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 11:28 PM +0000 2/6/02, D. J. Bernstein wrote:
>The question remains: Will an Alpha Online organization be allowed to
>register qol.com, with q changed to a lowercase alpha?

If you have a question for ICANN, you should address it to ICANN. 
Asking a question like this in the IETF is pretty useless.

>The question is whether case insensitivity will---beyond imposing huge
>software costs and creating huge new opportunities for fraud---prevent
>legitimate users from registering perfectly reasonable domain names.

If the case-matching table we have would impose "huge" software 
costs, what will the software costs be for a table that will probably 
be an order of magnitude larger? That is a rhetorical question, of 
course; correctly making a list of look-alike characters is 
essentially impossible. But I am interested in how much bigger than 
"huge" your proposal would cost.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Wed Feb  6 20: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 UAA06573
	for ; Wed, 6 Feb 2002 20:40:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YdOH-000Kb2-00
	for idn-data@psg.com; Wed, 06 Feb 2002 17:30:21 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YdOG-000Kav-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 17:30:21 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g171UG309619
	for ; Wed, 6 Feb 2002 17:30:16 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: 
 <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>
References: 
 <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>
Date: Wed, 6 Feb 2002 17:30:10 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: RE: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 5:07 PM -0800 2/6/02, Yves Arrouye wrote:
>Is it just me (having just browsed through that), or is the new prohibited
>table looking strange? It starts with:
>
>0000-0020
>007F
>0080-009F
>
>so a bunch of ASCII characters are not prohibited anymore.

It's not just you. They are prohibited in IDNA for other reasons, so 
we took them out of nameprep because the prohibition was redundant.

>  For instance, the
>name $$$.com is now allowed.

No, nor has it ever been. nameprep is called by IDNA. If you see a 
way to get "$$$" though IDNA, but all means let us know, because it 
should not.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Wed Feb  6 20:48: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 UAA06755
	for ; Wed, 6 Feb 2002 20:48:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YdQZ-000Kdw-00
	for idn-data@psg.com; Wed, 06 Feb 2002 17:32:43 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YdQY-000Kdp-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 17:32:43 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id JAA02304
	for ; Thu, 7 Feb 2002 09:26:24 +0800
From: "Kenny Huang" 
To: "IETF-IDN" 
Subject: [idn] FW: draft-tseng-idn-piidna-00.txt
Date: Thu, 7 Feb 2002 09:37:51 +0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA06755


Dear IETF IDN members,

The draft of "draft-tseng-idn-piidna-00.txt was demanded by the WG chair
to be posted as individual submission. Therefore you can't find it from the 
draft list of IDN wg.  It took me a little bit time to find out the draft location:
 
 ftp://ietf.org/internet-drafts/draft-tseng-idn-piidna-00.txt
 and 
 http://www.ietf.org/internet-drafts/draft-tseng-idn-piidna-00.txt
 

I help this information could help if you want to read the draft in detail.


Best Regards


Kenny Huang




From owner-idn@ops.ietf.org  Wed Feb  6 21:07: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 VAA07202
	for ; Wed, 6 Feb 2002 21:07:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ydpc-000LMz-00
	for idn-data@psg.com; Wed, 06 Feb 2002 17:58:36 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Ydpb-000LMs-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 17:58:35 -0800
Received: (qmail 18736 invoked by uid 1001); 7 Feb 2002 01:57:34 -0000
Date: 7 Feb 2002 01:57:34 -0000
Message-ID: <20020207015734.603.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Alpha Online
References: <116DB56CD7DED511BC7800508B2CA5370A18F6@mailsrvnt02.enet.sharplabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

McDonald, Ira writes:
> It's likely that the attempt to retroactively introduce case sensitive
> domain names will simply break almost all deployed Internet software.

You are misreading the proposal.

Software will treat uppercase ASCII and lowercase ASCII as equivalent,
for interoperability with existing configurations. However, software
will not adopt the new insensitivity rules for non-ASCII characters.
Uppercase Beta, for example, won't be automatically converted into
lowercase beta.

Registries will prohibit uppercase non-ASCII characters. Users will
stick to lowercase characters. Consequently we'll have the flexibility
to add case-insensitivity later _if_ that turns out to be a good idea.

Case insensitivity is quite a bit of added work for implementors, and it
dramatically expands the number of opportunities for visual confusion,
as well as the severity of the confusion. The only counterargument is
the unjustified speculation that users are too stupid to handle a world
of case-sensitive names---even though URLs are already case-sensitive,
specifically in path names.

Do you think that the unjustified speculation outweighs the big
problems? Are you so sure about this that you support making an
irreversible decision right now?

The careful approach is to start with lowercase IDNs. Registries will
allow a carefully selected set of characters. It will be possible to
expand the set later, when we have more experience, but for the moment
we'll stick to something safe. Similar comments apply to Chinese.

---Dan



From owner-idn@ops.ietf.org  Wed Feb  6 21:14: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 VAA07428
	for ; Wed, 6 Feb 2002 21:14:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YdwZ-000Lbl-00
	for idn-data@psg.com; Wed, 06 Feb 2002 18:05:47 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16YdwY-000Lbe-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 18:05:46 -0800
Received: (qmail 32285 invoked by uid 1001); 7 Feb 2002 02:03:51 -0000
Date: 7 Feb 2002 02:03:51 -0000
Message-ID: <20020207020351.18991.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission from ["Hsin-Hung Chou" ]
References: <005801c1af59$aa2b5040$0701000a@jamescompaq> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Rick H Wesson writes:
> Just protesting doesn't count,

False. The protests, and your refusal to take the protests into account,
will be helpful evidence in any antitrust lawsuit.

---Dan



From owner-idn@ops.ietf.org  Wed Feb  6 21:20: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 VAA07513
	for ; Wed, 6 Feb 2002 21:20:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ye23-000Lkm-00
	for idn-data@psg.com; Wed, 06 Feb 2002 18:11:27 -0800
Received: from 66.123.187.68.ar.com ([66.123.187.68] helo=bean.ar.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Ye22-000Lkf-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 18:11:26 -0800
Received: from loki (IDENT:wessorh@loki [66.123.187.67])
	by bean.ar.com (8.12.0/8.12.0) with ESMTP id g172AxU1002484;
	Wed, 6 Feb 2002 18:10:59 -0800 (PST)
Date: Wed, 6 Feb 2002 18:10:59 -0800 (PST)
From: Rick H Wesson 
To: "D. J. Bernstein" 
cc: 
Subject: Re: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission from
 ["Hsin-Hung Chou" ]
In-Reply-To: <20020207020351.18991.qmail@cr.yp.to>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


Dan,

thats a completely inappropiate post and way out of scope for our work
here.


-rick


On 7 Feb 2002, D. J. Bernstein wrote:

> Rick H Wesson writes:
> > Just protesting doesn't count,
>
> False. The protests, and your refusal to take the protests into account,
> will be helpful evidence in any antitrust lawsuit.
>
> ---Dan
>




From owner-idn@ops.ietf.org  Wed Feb  6 21:21: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 VAA07553
	for ; Wed, 6 Feb 2002 21:21:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ye5K-000Lro-00
	for idn-data@psg.com; Wed, 06 Feb 2002 18:14:50 -0800
Received: from shell.nominum.com ([128.177.192.160])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Ye5J-000Lrg-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 18:14:49 -0800
Received: from [128.177.194.115] (shell.nominum.com [128.177.192.160])
	by shell.nominum.com (Postfix) with ESMTP
	id 1A7CB3190C; Wed,  6 Feb 2002 18:14:49 -0800 (PST)
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Wed, 06 Feb 2002 18:15:26 -0800
Subject: Re: [idn] Fw: BOUNCE idn@ops.ietf.org:    Non-member submission
	from ["Hsin-Hung Chou" ]
From: David Conrad 
To: "D. J. Bernstein" ,
        Internationalized Domain Names 
Message-ID: 
In-Reply-To: <20020207020351.18991.qmail@cr.yp.to>
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

Wow.

On 2/6/02 6:03 PM, "D. J. Bernstein"  wrote:
>> Rick H Wesson writes:
>> Just protesting doesn't count,
> 
> False. The protests, and your refusal to take the protests into account,
> will be helpful evidence in any antitrust lawsuit.

and 

> Registries will prohibit uppercase non-ASCII characters. Users will
> stick to lowercase characters.

What color is the sky on the planet you're on?

Rgds,
-drc




From owner-idn@ops.ietf.org  Wed Feb  6 21:41: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 VAA08736
	for ; Wed, 6 Feb 2002 21:41:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YeNj-000MR3-00
	for idn-data@psg.com; Wed, 06 Feb 2002 18:33:51 -0800
Received: from friendly.realnames.com ([63.251.238.102])
	by psg.com with smtp (Exim 3.33 #1)
	id 16YeNi-000MQx-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 18:33:50 -0800
Received: (qmail 27438 invoked by uid 104); 7 Feb 2002 02:33:49 -0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.821581 secs); 07 Feb 2002 02:33:49 -0000
Received: from heaven.internal.realnames.com (10.1.5.39)
  by friendly.realnames.com with SMTP; 7 Feb 2002 02:33:48 -0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4865]) by heaven.internal.realnames.com
	Mail essentials (server 2.422) with SMTP id: <254019@heaven.internal.realnames.com>
	 for ; Wed, 6 Feb 2002 6:29:21 PM -0800
	smtpmailfrom  
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 6 Feb 2002 18:33:30 -0800
Message-ID: <7FC3066C236FD511BC5900508BAC86FE919681@trestles.internal.realnames.com>
From: Yves Arrouye 
To: "'Paul Hoffman / IMC'" , idn@ops.ietf.org
Subject: RE: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Date: Wed, 6 Feb 2002 18:30:55 -0800 
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

> No, nor has it ever been. nameprep is called by IDNA. If you see a 
> way to get "$$$" though IDNA, but all means let us know, because it 
> should not.

Yes, I know, I meant that the "$$$" part is allowed by the Nameprep tables.
I do think it's a good idea to have the redundant prohibition as it will be
one less pitfall for implementers. But as long as my library works, I don't
really care :-)

YA



From owner-idn@ops.ietf.org  Wed Feb  6 22:13: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 WAA09188
	for ; Wed, 6 Feb 2002 22:13:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yep9-000NEs-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:02:11 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yep9-000NEm-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:02:11 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id TAA26107
	for ; Wed, 6 Feb 2002 19:01:59 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id TAA08844
	for ; Wed, 6 Feb 2002 19:02:10 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id TAA08825;
	Wed, 6 Feb 2002 19:02:09 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id TAA01346;
	Wed, 6 Feb 2002 19:01:08 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id TAA01733;
	Wed, 6 Feb 2002 19:02:05 -0800 (PST)
Date: Wed, 6 Feb 2002 19:02:05 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202070302.TAA01733@birdie.sybase.com>
To: ben@cc-www.com
Subject: Re: [idn] Internet Draft - Phased Implementation for IDNA
Cc: idn@ops.ietf.org, jenkins@apple.com
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Ben asked:

> >Dear IETF IDN members,
> 
> >The attached draft  "Phased Implementation for IDNA" was submitted.
> >You are welcome to commont on the draft.
> 

> After reading the I-D, my question is-  Is it possible to modify the
> Appendix B so that it *only* prohibits the "Simplified Chinese code
> points" and allow all the rest to move forward?

And I think the answer is clearly no.

The problem, of course, is that the very term "Simplified Chinese
code point" is unclearly defined. It is certainly not defined by
the Unicode Standard. The proposal to use the source set tables
in 10646 to define it by listing those characters that have
G-source-only encompasses most, but not all of the formal list
of simplifications mandated by the PRC, but also includes scads
of traditional forms. The term "S-CDN" is bandied about in this
I-D, and even in the tsconv I-D, as if this is well-defined.

But the Chinese writing system is sloshing around in an ancient
ocean of Chinese lexicography and millennia of character usage
change. There is no quick fix engineering solution that gets
the "right answer" for this.

Take just one among many examples of the problem:

U+5F53 dang1 is a common usage character meaning "equal; to work
              as, serve as, be..."

U+7576 dang1 is the traditional variant of the same character.

So, U+5F53 is the simplified form of U+7576. We prohibit U+5F53
by adding it to Appendix B, but allow U+7576, and we are done,
right?

Wrong.

U+5F53 also is onomatopoetic for the sound of a gong or bell.
In that sense it is *also* a simplification of the traditional form
U+5679. (And historically, of course, U+5679 was just an innovation
adding the mouth radical to U+7576, to distinguish the "clang" sense
of dang1 from the "equal" sense of dang1.)

But then we also have U+943A dang1 "clank, clang", which has the
same component, but with the metal radical, instead of the mouth
radical. And *it* has a simplified form U+94DB dang1. Again,
historically, these are the same word as the onomatopoetic U+7576,
but are variants separated out by attachment of a radical.

But wait, there's more. It turns out that U+5F53 is not a recent,
systematic PRC simplification mandated by the ministry tables
of 1986 published in dictionaries (although of course it does
appear there). It is an older example of a "traditional
simplification" ([U+4fd7][U+5b57] su2zi4) that got carried into
the systematic PRC simplifications. And guess what, U+5F53 is
the *ordinary* character used in Japanese, which by and large
avoids all of the PRC simplifications for historical reasons.
U+5F53 is not only the ordinary character in Japanese -- it is
in the Jyooyookanji, the short list of characters *required* for
Japanese and learned by all Japanese school kids in their
basic education.

So just in this one example, we see both the inherent complexity
of variants of "the same character" in Chinese, and an
illustration of the fact that trying to eliminate the
"SC" from the allowed set of characters for IDN would immediately
cripple the repertoire for use in Japanese.

I am fully sympathetic with the expressed Chinese requirement that
Chinese expressions for the "same thing", whether represented
in the "simplified" orthography or the "traditional" orthography,
should match transparently to a user. For example:

U+7576 U+6B78 dang1gui1 "Chinese angelica" (traditional characters)

should match

U+5F53 U+5F52 dang1gui1 "Chinese angelica" (simplified characters)

for the .tw website. But while you
could probably match the whole words, run them through any
of a number of commercially available TC<-->SC transducers,
and get the match you want, if you just try to do code point
matching, all hell breaks loose around the edges, and your
scheme is fatally flawed for Japanese (and Korean) use.

By the way, U+6B78 gui1 *also* has a traditional simplification
used in Japan (U+5E30), which is not the same as the U+5F52
simplified form used in the PRC. But don't get me started on gui1,
as I might have to start talking about turtles... ;-)

--Ken



From owner-idn@ops.ietf.org  Wed Feb  6 22:13: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 WAA09200
	for ; Wed, 6 Feb 2002 22:13:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YeoR-000NDN-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:01:27 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YeoQ-000NDH-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:01:26 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16YeoQ-0001co-00
	for ; Wed, 06 Feb 2002 19:01:26 -0800
Date: Thu, 7 Feb 2002 03:01:26 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Message-ID: <20020207030125.GC5125@nicemice.net>
Reply-To: IETF idn working group 
References: <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>  <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:  <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Yves Arrouye  wrote:

> a bunch of ASCII characters are not prohibited anymore.

Yep.

> It may be that one expects IDN applications to do more checks than
> just Nameprep

Indeed.  Please look at the IDNA draft.  Nameprep is just one of a whole
list of steps to be performed.

> why bother with the 0000-0020 and 007F

I've wondered about that myself.  The nameprep draft gives the reasons
for all the prohibited code points.  I'm not sure how convincing all the
reasons are, but you can look at them and judge for yourself.

The reason some printable ASCII characters were prohibited in earlier
versions of nameprep is that they are prohibited in host names, but
that was not a good reason, because we want nameprep to be usable not
only for host names, but for all domain names, including names like
_ldap._tcp.foo.net (see RFC 2782 about SRV records).

The special restrictions on host names (not only the LDH restriction,
but also the leading/trailing hyphen restriction) are now checked in
ToASCII in the IDNA spec, not in nameprep.

For convenience, here are steps 2 and 3 of ToASCII:

    2. Perform the steps specified in [NAMEPREP].

    3. Host-specific restrictions: If the label is part of a host name
       (or is subject to host name syntax rules) then perform these
       checks:

         * Verify the absence of non-LDH ASCII code points; that is, the
           absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.

         * Verify the absence of leading and trailing hyphen-minus; that
           is, the absence of U+002D at the beginning and end of the
           sequence.

Paul Hoffman / IMC  wrote:

> If you see a way to get "$$$" though IDNA, but all means let us know,
> because it should not.

If an application is using the domain name $$$.com and knows that
it's not a host name and not subject to the host name syntax rules (I
can think of no example scenarios today, but maybe someday this will
happen), then $$$ will indeed pass through ToASCII successfully (and
unchanged), as it should.

AMC



From owner-idn@ops.ietf.org  Wed Feb  6 22:39: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 WAA10381
	for ; Wed, 6 Feb 2002 22:39:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YfFD-000O3A-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:29:07 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YfFB-000O2t-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:29:05 -0800
Received: from iis.sinica.edu.tw (dhcp067 [140.109.21.74])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g173LnT08231;
	Thu, 7 Feb 2002 11:21:50 +0800 (CST)
Message-ID: <3C61F46D.D034F08C@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 11:28:45 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Scott Bradner 
CC: deng@cnnic.net.cn, Elisabeth.Porteneuve@cetp.ipsl.fr, erin@twnic.net.tw,
        mclaughlin@pobox.com, ajm@icann.org, alanysho@hkdnr.net.hk,
        christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@Alvestrand.no,
        hlqian@cnnic.net.cn, htk@eecs.harvard.edu, huangk@alum.sinica.edu,
        iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo,
        jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com,
        lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn,
        Marc.Blanchet@viagenie.qc.ca, mkatoh@mkatoh.net, mouhamet@next.sn,
        narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com,
        phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my,
        shkyong@kgsm.kaist.ac.kr, snw@twnic.net.tw
Subject: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
References: <200202031600.g13G07n19482@newdev.harvard.edu>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Dear Scott,

It's getting more often after  Microsoft launched Windows 2000. Now,
people could use it to input Unicode CJK Han characters including 
TC, SC, and even Japanese Han characters. Please refer to the 
following article.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q227483

-- Janming

Scott Bradner gJG

> > Assume Chinese name of 10 glyphs. Each one may take 2 versions,
> > TC or SC.
>
> how often are Chinese names written using a mixture of TC & SC?
>
> Scott



From owner-idn@ops.ietf.org  Wed Feb  6 22:39: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 WAA10393
	for ; Wed, 6 Feb 2002 22:39:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YfG4-000O53-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:30:00 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YfG3-000O4v-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:29:59 -0800
Received: from iis.sinica.edu.tw (dhcp067 [140.109.21.74])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g173MET08374;
	Thu, 7 Feb 2002 11:22:14 +0800 (CST)
Message-ID: <3C61F486.FFD1D701@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 11:29:10 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Dave Crocker 
CC: Elisabeth Porteneuve ,
        deng@cnnic.net.cn, erin@twnic.net.tw, mclaughlin@pobox.com,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, alanysho@hkdnr.net.hk,
        christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@alvestrand.no,
        hlqian@cnnic.net.cn, htk@eecs.harvard.edu, huangk@alum.sinica.edu,
        iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo,
        jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com,
        lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn,
        mkatoh@mkatoh.net, mouhamet@next.sn, narten@us.ibm.com,
        nordmark@eng.sun.com, paf@cisco.com, phoffman@imc.org,
        qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw,
        vcerf@mci.net, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,
        wuch@gate.sinica.edu.tw, yktham@umac.mo
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Dear Dave,

Two comments:

1. The TC/SC problem or variant problem comes from Unicode and the
decision
   to adopt Unicode as the basis to develop IDN technology. If the
working
   group chooses to use Unicode as basis, then it becomes a partial
solution 
   to the "global" IDN problem because of this side-effect.
2. We do not want to delay your process either. Please refer to the
draft
   "Phased Implementation of Internationalized Domain Names in
Applications" 
   for more details.

-- Janming

Dave Crocker gJG

> At 03:35 AM 2/6/2002 -0800, Elisabeth Porteneuve wrote:
> >Why this proposal cannot be taken into account by IETF IDN WG?
>
> Elisabeth,
>
> This entire topic, and all its proposals, have very much been taken into
> account by the IDN working group.  They have been taken into account at the
> cost of many months of delay, although this topic is actually outside the
> scope of the working group.
>
> The topic calls for an algorithm that equates portions of different
> scripts.  This goes beyond the model of equating upper/lower case WITHIN a
> script.
>
> In fact, this topic is an open research question with no generally accepted
> practise.  So even if the topic were within scope the solution would, at
> best, be very, very risky.
>
> The risk is exacerbated by the fact that this technical approach does not
> scale well.  As soon as an approach like the TC/SC proposal is added, then
> we must find mappings for many, many other multi-script equivalences.  That
> effort will probably take years.
>
> d/
>
> ----------
> Dave Crocker  
> Brandenburg InternetWorking  
> tel +1.408.246.8253;  fax +1.408.273.6464



From owner-idn@ops.ietf.org  Wed Feb  6 22:40: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 WAA10450
	for ; Wed, 6 Feb 2002 22:40:20 -0500 (EST)
From: owner-idn@ops.ietf.org
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YfIl-000O8j-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:32:47 -0800
Message-Id: 
To: idn-data@psg.com
Date: Wed, 06 Feb 2002 19:32:47 -0800

Thu, 7 Feb 2002 11:22:28 +0800 (CST)
Message-ID: <3C61F493.FAA13198@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 11:29:23 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Dave Crocker 
CC: Erin Chen , IESG , IAB
,
   IETF IDN WG ,
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Note: header field too long; To & Cc field trim - JS]

Dear Dave,

I understand that you are only interested in extending the range of
domain
names beyond ASCII and are not interested in solving either TC/SC or the
CJK variants problem. We are not asking you to do that either. Unicode
and
IDNA, etc., do extend the range of domain names for you. But, in the
mean
time, it extends too much and brings too many variants of Han characters
and the associated delegation and resolution problems to Internet users
in
other culture where these characters are used in their daily life.

In other words, what you called an IDN WG solution is a partial
solution.
It works for a portion of the world but not the whole. We are asking
people
here in the WG to take the part of solution you are happy with.  But,
please
bear in mind that there is no consensus regarding the IDN "solution" on
the
CJK portion, so we urge the WG to adopt a phased implementation
strategy.

-- Janming Ho

Dave Crocker gJG

> At 06:27 PM 2/1/2002 +0800, Erin Chen wrote:
> >But, the architecture of IDN defined in above four documents does not
> >solve the traditional and simplified Chinese character variant
problem.
>
> There are many things the IDN specifications do not do.  Rather, the
> specifications focus on solving satisfying only the requirement they
are
> supposed to satisfy.
>
> Solution of TC/SC is one example of equivalence among Unicode
> sets.  Indeed, IDN does not attempt to specify such
> equivalences.  Equivalence among separate Unicode sets is essentially
an
> open technical topic for which there are no accepted practises.
>
> Still, this topic has been discussed, debated and explained
extensively
> within the IDN working group.  .
>
> The purpose of IDN is to permit use of an increased range of
characters in
> domain name, beyond the current limit of ASCII.  It is not the goal of
the
> working group to invent character set conventions such as equivalence
> between different sets.
>
> It will be wonderful when equivalence between sets is achieved.
However it
> is not the charter of IDN to solve basic issues of character set
> equivalence and it is not reasonable to delay the utility of the
character
> set enhancement specified by IDN, in the hope that some day the
question of
> character set equivalence is achieved.
>
> Contrary to the claim that the working group is moving too quickly, my
own
> guess is that it has been a major source of delay for the working
group for
> at least 6 months.  Perhaps much longer.
>
> d/
>
> ----------
> Dave Crocker  
> Brandenburg InternetWorking  
> tel +1.408.246.8253;  fax +1.408.273.6464





From owner-idn@ops.ietf.org  Wed Feb  6 22:53: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 WAA10731
	for ; Wed, 6 Feb 2002 22:53:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YfVi-000Oaw-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:46:10 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YfVh-000Oan-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:46:09 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 54415 for idn@ops.ietf.org; Wed, 06 Feb 2002 21:45:29 -0600
Message-ID: <3C61F87E.6B7CBD83@ehsco.com>
Date: Wed, 06 Feb 2002 21:46:06 -0600
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-nameprep-07.txt
References: <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>  <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com> <20020207030125.GC5125@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:
> 
> Yves Arrouye  wrote:

> > why bother with the 0000-0020 and 007F
> 
> I've wondered about that myself.  The nameprep draft gives the reasons
> for all the prohibited code points.  I'm not sure how convincing all the
> reasons are, but you can look at them and judge for yourself.

I haven't yet had a chance to go through the latest drafts (other
deadlines) so this is coming from a slightly ignorant perspective, but I
would ask that the IDNA team re-evaluate their position on this matter.

First of all, those code-points should not be universally prohibited,
since they are absolutely legitimate in STD13 domain names. ANY octet
value is allowed. If you are going to be moving SOME of the prohibited
characters from nameprep to the IDNA hostname processing, then you need to
move ALL of them at that stage.

However, this is not the approach I would recommend. Instead, I would
recommend that a series of nameprep-like documents be prepared under the
stringprep umbrella, with one document for each of the known data-types.
For example, there should be a document for i18n hostnames, there should
be another document for STD13 hostnames (to act as an IDNA output filter),
another document for current RFC 2822 email addresses, and so forth. Each
of these documents can then be used as data-type inputs. Or to put it in
another perspective, each of them can be treated somewhat like Unicode
"property" tables, with certain types of output only being allowed to
contain characters from the relevant property.

I'm sure that somebody will say something about this being too late, but
there you have it. At the very least, you should consolidate the
prohibited characters into IDNA, as the prohibited characters which appear
to be in nameprep are in fact valid for STD13 domain names.

I will try to read the last-call drafts and make more informed commentary
tomorrow or Friday.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Wed Feb  6 22:58: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 WAA10807
	for ; Wed, 6 Feb 2002 22:58:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YfZL-000Ojg-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:49:55 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YfZK-000OjN-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:49:54 -0800
Received: from iis.sinica.edu.tw (dhcp067 [140.109.21.74])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g173iZT15610;
	Thu, 7 Feb 2002 11:44:35 +0800 (CST)
Message-ID: <3C61F9C1.4AA744A1@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 11:51:29 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Dave Crocker 
CC: "idn@ops.ietf.org" , "iesg@ietf.org" ,
        IAB , "fred@cisco.com" ,
        Scott Bradner ,
        "htk@eecs.harvard.edu" ,
        Xiang Deng , Erin Chen 
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC)
Content-Type: multipart/mixed;
 boundary="------------ED1B9E33C8105B407BCAFAF9"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

3o,O MIME .f&!*:&h,q&!6l%s!C
--------------ED1B9E33C8105B407BCAFAF9
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit



--------------ED1B9E33C8105B407BCAFAF9
Content-Type: message/rfc822
Content-Disposition: inline

Received: from iiserv.iis.sinica.edu.tw (iiserv [140.109.20.250])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g173ZFT12661
	for ; Thu, 7 Feb 2002 11:35:15 +0800 (CST)
Received: from mail.iis.sinica.edu.tw (mail [140.109.20.50])
	by iiserv.iis.sinica.edu.tw (8.11.1/8.11.1) with ESMTP id g173il216509
	for ; Thu, 7 Feb 2002 11:44:47 +0800 (CST)
Received: from localhost (localhost)
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) id g173MSt08462;
	Thu, 7 Feb 2002 11:35:11 +0800 (CST)
Date: Thu, 7 Feb 2002 11:35:11 +0800 (CST)
From: Mail Delivery Subsystem 
Message-Id: <200202070335.g173MSt08462@mail.iis.sinica.edu.tw>
To: 
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
	boundary="g173MSt08462.1013052911/mail.iis.sinica.edu.tw"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
X-Mozilla-Status2: 00000000

This is a MIME-encapsulated message

--g173MSt08462.1013052911/mail.iis.sinica.edu.tw

The original message was received at Thu, 7 Feb 2002 11:22:14 +0800 (CST)
from dhcp067 [140.109.21.74]

   ----- The following addresses had permanent fatal errors -----

    (reason: 553 Too many recipients in the mail, should less than 30)

    (reason: 550 Host unknown)

   ----- Transcript of session follows -----
... Deferred: Connection timed out with whale.cnnic.net.cn.
... while talking to public.bta.net.cn.:
>>> DATA
<<< 553 Too many recipients in the mail, should less than 30
554 5.0.0 ... Service unavailable
... Deferred: Connection timed out with mail-gw.cmc.gov.my.
550 5.1.2 ... Host unknown (Name server: cnnnic.net.cn: host not found)

--g173MSt08462.1013052911/mail.iis.sinica.edu.tw
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.iis.sinica.edu.tw
Arrival-Date: Thu, 7 Feb 2002 11:22:14 +0800 (CST)

Final-Recipient: RFC822; qhhu@public.bta.net.cn
Action: failed
Status: 5.1.0
Remote-MTA: DNS; public.bta.net.cn
Diagnostic-Code: SMTP; 553 Too many recipients in the mail, should less than 30
Last-Attempt-Date: Thu, 7 Feb 2002 11:30:46 +0800 (CST)

Final-Recipient: RFC822; whzhang@cnnnic.net.cn
Action: failed
Status: 5.1.2
Remote-MTA: DNS; cnnnic.net.cn
Diagnostic-Code: SMTP; 550 Host unknown
Last-Attempt-Date: Thu, 7 Feb 2002 11:35:05 +0800 (CST)

--g173MSt08462.1013052911/mail.iis.sinica.edu.tw
Content-Type: message/rfc822

Return-Path: 
Received: from iis.sinica.edu.tw (dhcp067 [140.109.21.74])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g173MET08374;
	Thu, 7 Feb 2002 11:22:14 +0800 (CST)
Message-ID: <3C61F486.FFD1D701@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 11:29:10 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Dave Crocker 
CC: Elisabeth Porteneuve ,
   deng@cnnic.net.cn, erin@twnic.net.tw, mclaughlin@pobox.com,
   Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, alanysho@hkdnr.net.hk,
   christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@alvestrand.no,
   hlqian@cnnic.net.cn, htk@eecs.harvard.edu, huangk@alum.sinica.edu,
   iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org, jasonho@umac.mo,
   jet-member@nic.ad.jp, jseng@pobox.org.sg, klensin@jck.com,
   lee@whale.cnnic.net.cn, lynn@icann.org, mao@cnnic.net.cn, mkatoh@mkatoh.net,
   mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com,
   phoffman@imc.org, qhhu@public.bta.net.cn, sharil@cmc.gov.my,
   shkyong@kgsm.kaist.ac.kr, snw@twnic.net.tw, sstseng@twnic.net.tw,
   tsenglm@cc.ncu.edu.tw, vcerf@mci.net, whzhang@cnnnic.net.cn,
   wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit


Dear Dave,

Two comments:

1. The TC/SC problem or variant problem comes from Unicode and the
decision
   to adopt Unicode as the basis to develop IDN technology. If the
working
   group chooses to use Unicode as basis, then it becomes a partial
solution 
   to the "global" IDN problem because of this side-effect.
2. We do not want to delay your process either. Please refer to the
draft
   "Phased Implementation of Internationalized Domain Names in
Applications" 
   for more details.

-- Janming

Dave Crocker gJG

> At 03:35 AM 2/6/2002 -0800, Elisabeth Porteneuve wrote:
> >Why this proposal cannot be taken into account by IETF IDN WG?
>
> Elisabeth,
>
> This entire topic, and all its proposals, have very much been taken into
> account by the IDN working group.  They have been taken into account at the
> cost of many months of delay, although this topic is actually outside the
> scope of the working group.
>
> The topic calls for an algorithm that equates portions of different
> scripts.  This goes beyond the model of equating upper/lower case WITHIN a
> script.
>
> In fact, this topic is an open research question with no generally accepted
> practise.  So even if the topic were within scope the solution would, at
> best, be very, very risky.
>
> The risk is exacerbated by the fact that this technical approach does not
> scale well.  As soon as an approach like the TC/SC proposal is added, then
> we must find mappings for many, many other multi-script equivalences.  That
> effort will probably take years.
>
> d/
>
> ----------
> Dave Crocker  
> Brandenburg InternetWorking  
> tel +1.408.246.8253;  fax +1.408.273.6464

--g173MSt08462.1013052911/mail.iis.sinica.edu.tw--



--------------ED1B9E33C8105B407BCAFAF9--




From owner-idn@ops.ietf.org  Wed Feb  6 23:03: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 XAA10875
	for ; Wed, 6 Feb 2002 23:03:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yfgp-000P0w-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:57:39 -0800
To: hoho 
From: Dave Crocker 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Cc: Erin Chen , IESG , IAB@psg.com
Message-Id: 
Date: Wed, 06 Feb 2002 19:57:39 -0800

,
        IETF IDN WG 
In-Reply-To: <3C61F493.FAA13198@iis.sinica.edu.tw>
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Note: header field too long; To & Cc field trim - JS]

At 11:29 AM 2/7/2002 +0800, hoho wrote:
>I understand that you are only interested in extending the range of
>domain
>names beyond ASCII and are not interested in solving either TC/SC or
the
>CJK variants problem. We are not asking you to do that either.

1.  This is not a matter of personal desires.  You do not help
discussion
by phrasing things as a matter of personal preference.

2.  This is a technical topic needing technical work.

3.  The technical work must be limited in scope or it will never finish.

4.  As I have said a number of times, the topic that you are interested
in
solving is very much an important topic.  Hence I would appreciate your
refraining from implying that I think it is not important.

However solutions are not readily available, and solving this topic is
not
required for making domain names support a broad range of characters.  I
am
assuming that you do want domain names to be useful for the entire
global
community, yes?


>In other words, what you called an IDN WG solution is a partial
>solution.

All interesting technical work is a partial solution.  That does not
make
the work useless, merely limited.


>It works for a portion of the world but not the whole.

It works for nearly all of the world, including those using Han.  The
concern you have is that it does not work as well for Han as you wish.
It
is fine that you wish the solution to be better, but that is quite
different from it not working at all.

d/

----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464






From owner-idn@ops.ietf.org  Wed Feb  6 23:05: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 XAA10897
	for ; Wed, 6 Feb 2002 23:05:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YfgE-000Oyc-00
	for idn-data@psg.com; Wed, 06 Feb 2002 19:57:02 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YfgC-000OyI-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 19:57:01 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP id 8D8E9FFC16
	for ; Thu,  7 Feb 2002 11:55:59 +0800 (SGT)
Message-ID: <023e01c1af8b$7c248e50$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: 
Subject: [idn] vote and protest
Date: Thu, 7 Feb 2002 11:56: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 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: 7bit

Some personal opinion:

1. Vote

This is not an election - We dont vote in IETF. Telling all your friends
to support your ideas does not work in IETF. It have to stand up to the
technical scrutiny of the wg.

2. Protest

Protest will always be noted. But this is IETF, not ICANN. We prefer
solution over critics. Learn the culture first.

Personally, I hold iis.sinica.edu.tw in comtempt.

The first time iis.sinica.edu.tw have organised such massive spam is on
the strawpoll for reordering and create an appearance of support when
there is none. The current protest is a second series.

It certainly does not project an appropriate image for such an
well-established research academy in Taiwan.

Note: There are about ~17 non-member (16 from iss.sinica.edu.tw) mails
stuck in my mailbox as of writing this. I am in discussion with the ADs
on the next step so please give me a while to sort it out.

-James Seng




From owner-idn@ops.ietf.org  Wed Feb  6 23:15: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 XAA11002
	for ; Wed, 6 Feb 2002 23:15:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yfqj-000PMO-00
	for idn-data@psg.com; Wed, 06 Feb 2002 20:07:53 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yfqi-000PMG-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 20:07:52 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g1747c317322;
	Wed, 6 Feb 2002 20:07:38 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <3C61F486.FFD1D701@iis.sinica.edu.tw>
References: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1>
 <3C61F486.FFD1D701@iis.sinica.edu.tw>
Date: Wed, 6 Feb 2002 20:07:29 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Cc: Elisabeth.Porteneuve@cetp.ipsl.fr, deng@cnnic.net.cn, erin@twnic.net.tw,
        mclaughlin@pobox.com, Marc.Blanchet@viagenie.qc.ca, ajm@icann.org,
        alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, fred@cisco.com,
        harald@alvestrand.no, hlqian@cnnic.net.cn, htk@eecs.harvard.edu,
        huangk@alum.sinica.edu, iab@isi.edu, idn@ops.ietf.org, iesg@ietf.org,
        jasonho@umac.mo, jet-member@nic.ad.jp, jseng@pobox.org.sg,
        klensin@jck.com, lee@whale.cnnic.net.cn, lynn@icann.org,
        mao@cnnic.net.cn, mkatoh@mkatoh.net, mouhamet@next.sn,
        narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com,
        qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw,
        vcerf@mci.net, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,
        wuch@gate.sinica.edu.tw, yktham@umac.mo
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 11:29 AM +0800 2/7/02, hoho wrote:
>1. The TC/SC problem or variant problem comes from Unicode and the
>decision
>    to adopt Unicode as the basis to develop IDN technology. If the
>working
>    group chooses to use Unicode as basis, then it becomes a partial
>solution
>    to the "global" IDN problem because of this side-effect.

This is exactly wrong. The decision to use the ISO/IEC 10646 
(Unicode) character repertoire was made to make IDN a global 
solution. Maybe I missed it, but what other solution has been 
proposed that is more global than using 10646? We already discussed 
this in detail on the mailing list many times, and no one came up 
with anything more global.

>2. We do not want to delay your process either. Please refer to the
>draft
>    "Phased Implementation of Internationalized Domain Names in
>Applications"
>    for more details.

The "phased implementation" draft is sure to cause a great deal more delay.

- The draft has serious technical errors: the list in section 1 does 
not even vaguely match the list given in Appendix B.

- As the draft admits, adopting the draft would have a very serious 
negative consequence on Japan and Korea. It is very insulting to say 
to people of other countries "because we have problems we cannot 
solve with our script, you will be reduced to using phonetic spelling 
of your names until we come up with a solution, even though we have 
failed numerous times in the past trying to do this". Discussing the 
political ramifications of this consequence could take years.

- The draft is open-ended about what code points would be prohibited. 
Discussing whether to also prohibit additional code points will 
certainly delay IDN. If you are going to make this draft actually 
represent all of the scripts for which IDN is not perfect, the list 
will be huge, and it will probably affect many billions more people.

If you feel that the IDN WG can deal with all those problems without 
delaying IDN, you have not been paying attention to the way this WG 
moves. :-)

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Wed Feb  6 23:19: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 XAA11040
	for ; Wed, 6 Feb 2002 23:19:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yfw8-000PYN-00
	for idn-data@psg.com; Wed, 06 Feb 2002 20:13:28 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yfw8-000PYH-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 20:13:28 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id UAA03413
	for ; Wed, 6 Feb 2002 20:13:16 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id UAA05295
	for ; Wed, 6 Feb 2002 20:13:26 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id UAA05277;
	Wed, 6 Feb 2002 20:13:25 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id UAA05489;
	Wed, 6 Feb 2002 20:12:24 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id UAA01752;
	Wed, 6 Feb 2002 20:13:22 -0800 (PST)
Date: Wed, 6 Feb 2002 20:13:22 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202070413.UAA01752@birdie.sybase.com>
To: hoho@iis.sinica.edu.tw
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Cc: idn@ops.ietf.org, jenkins@apple.com
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Janming said:

> Two comments:
> 
> 1. The TC/SC problem or variant problem comes from Unicode 

It does not.

"The TC/SC problem" derives from 50 years of political history in
China, where the PRC engaged in an orthographic revision of
the writing system that Taiwan (and Hong Kong) did not, during
the same time span that information technology was developed and
rolled out on both sides of that political chasm. The result was
the development of incompatible character encodings and
input method editors tailored either for the "simplified" Chinese
of the PRC or the "traditional" Chinese of Taiwan and Hong Kong.

This was not a "problem" to end users before the Internet, because
never the twain did meet, and computer technology generally
didn't have to support both, but only one choice at any one
site. Furthermore, traditional IME's didn't support entry of
simplified characters, even if the traditional character encodings
(like CNS) nominally had them in the list; and vice versa.

Now it *is* a problem to end users, because the Internet and
the web, and changed political conditions, and globalization
mean that everybody has to deal with all of the characters in
one context or another.

I would accept a reformulation that:

  A. The availability of Unicode-enabled systems, such as
     Windows 2000, with IME's that can support either traditional
     or simplified characters, and fonts that display both,
     has made the preexisting TC/SC problem acutely visible
     to end users on their computers.

  B. The move to Unicode implementations means that mingling
     of traditional and simplified orthographies is easier.
     In effect, users now have the rope to hang themselves,
     if they so desire. Whereas, before, the constraints of
     the deployment of IME's and fonts generally meant that
     you couldn't easily mix SC/TC, even when the code page 
     nominally supported it.

> and the
> decision
>    to adopt Unicode as the basis to develop IDN technology.

And the alternative is ... ?

What character encoding alternative at this point in history
would not have the exact same problem? Certainly no choice
of a current national character encoding out of China itself
would avoid the exact same problems you attribute to Unicode.

But you are going to have to pick *some* encoding for the
characters you represent in domain names. If not Unicode,
then what?

> If the
> working
>    group chooses to use Unicode as basis, then it becomes a partial
> solution 
>    to the "global" IDN problem because of this side-effect.
> 2. We do not want to delay your process either. Please refer to the
> draft
>    "Phased Implementation of Internationalized Domain Names in
> Applications" 
>    for more details.

I have looked at that draft in detail, and see no solution
offered -- but only denial and vain hope. In short, a proposal
to simply exclude *all* the Chinese characters from IDN, with
a vague promise that someday someone will figure it all out
and decide which of 20,902 characters are o.k. to let back in
and which are only variants of the "good" ones. That promise
will be dashed on the rocks of the reality of complexity in
Chinese character variation -- and no code point based solution,
Unicode or otherwise, is going to fix it.

And in the meantime, the Phased Implementation proposal merely 
exports the Chinese SC/TC "problem" in a way that also disables 
IDN for Japan. I don't think that is acceptable.

--Ken





From owner-idn@ops.ietf.org  Wed Feb  6 23:36: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 XAA11598
	for ; Wed, 6 Feb 2002 23:36:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YgD3-00007q-00
	for idn-data@psg.com; Wed, 06 Feb 2002 20:30:57 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YgD2-00007j-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 20:30:56 -0800
Received: from MASTER ([210.217.27.236])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g174UGR30506;
	Thu, 7 Feb 2002 13:30:17 +0900
Message-ID: <020601c1af90$25e105a0$ec1bd9d2@temp>
From: "Soobok Lee" 
To: , "Paul Hoffman / IMC" 
Cc: , ,
        , ,
        , ,
        , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , , ,
        , ,
        , 
References: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1> <3C61F486.FFD1D701@iis.sinica.edu.tw> 
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Date: Thu, 7 Feb 2002 13:30:00 +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" 


> At 11:29 AM +0800 2/7/02, hoho wrote:
> >1. The TC/SC problem or variant problem comes from Unicode and the
> >decision
> >    to adopt Unicode as the basis to develop IDN technology. If the
> >working
> >    group chooses to use Unicode as basis, then it becomes a partial
> >solution
> >    to the "global" IDN problem because of this side-effect.
> 
> This is exactly wrong. The decision to use the ISO/IEC 10646 
> (Unicode) character repertoire was made to make IDN a global 
> solution. Maybe I missed it, but what other solution has been 
> proposed that is more global than using 10646? We already discussed 
> this in detail on the mailing list many times, and no one came up 
> with anything more global.


Unicode is not designed for identifiers use but rather for
display or printing devices,  from the beginning. But,
Unicode is ever evolving to expand its application areass.
It's astonishing Unicode has not yet any concrete lists of 
TC/SC 1:1 and 1:n equivalences.
I admit UNicode is the best solution as for now , but not the sufficienly
mature solution  enough to serve the global language communities,
especially chinese. IDN deployment is not a reversible process.


> 
> >2. We do not want to delay your process either. Please refer to the
> >draft
> >    "Phased Implementation of Internationalized Domain Names in
> >Applications"
> >    for more details.
> 
> The "phased implementation" draft is sure to cause a great deal more delay.
> 
> - The draft has serious technical errors: the list in section 1 does 
> not even vaguely match the list given in Appendix B.
> 
> - As the draft admits, adopting the draft would have a very serious 
> negative consequence on Japan and Korea. It is very insulting to say 
> to people of other countries "because we have problems we cannot 
> solve with our script, you will be reduced to using phonetic spelling 
> of your names until we come up with a solution, even though we have 
> failed numerous times in the past trying to do this". Discussing the 
> political ramifications of this consequence could take years.
 
Then, you should also admit that the opposite position (taken by this WG now)is also 
very insulting to chinese communities.

Soobok Lee




From owner-idn@ops.ietf.org  Wed Feb  6 23:42: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 XAA11674
	for ; Wed, 6 Feb 2002 23:42:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YgJ5-0000LH-00
	for idn-data@psg.com; Wed, 06 Feb 2002 20:37:11 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YgJ4-0000L9-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 20:37:10 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16YgJ1-0001w6-00; Wed, 06 Feb 2002 20:37:07 -0800
Date: Thu, 7 Feb 2002 04:37:07 +0000
From: "Adam M. Costello" 
To: "Eric A. Hall" 
Cc: IETF idn working group 
Subject: Re: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Message-ID: <20020207043706.GA7193@nicemice.net>
Reply-To: IETF idn working group 
References: <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>  <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com> <20020207030125.GC5125@nicemice.net> <3C61F87E.6B7CBD83@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C61F87E.6B7CBD83@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> If you are going to be moving SOME of the prohibited characters from
> nameprep to the IDNA hostname processing, then you need to move ALL of
> them at that stage.

There are some code points that should be prohibited in all
internationalized textual domain names.  The private use code points,
noncharacter code points, surrogate codes, and left-to-right mark are
some of the best examples of such code points.  These prohibitions do
indeed belong in nameprep.

There are some code points that are prohibited in host names, but not in
all textual domain names.  The underscore is the best example.  These
prohibitions belong in ToASCII.

It's not always clear which side of the line particular code points fall
on.  The least clear-cut are the ASCII prohibitions: 0..20 and 7F.  Feel
free to offer some arguments.

> At the very least, you should consolidate the prohibited characters
> into IDNA, as the prohibited characters which appear to be in nameprep
> are in fact valid for STD13 domain names.

In the broadest sense a STD13 domain name can contain arbitrary binary
data.  Nameprep is not intended for domain names in this broadest sense.
It is intended for domain names composed of internationalized *text*.
It is appropriate for nameprep to prohibit things that are difficult to
interpret as text.

Therefore, the prohibition of ASCII control characters doesn't worry me
much.  The prohibition of ASCII space worries me a little.  Notice that
nameprep doesn't prohibit dots in domain labels, even though dots are
usually used to delimit labels, are are therefore tricky to put into
labels.  In fact RFC 1035 shows how to get dots into labels for the
purpose of representing email addresses that contain dots in the local
part.  If nameprep doesn't prohibit dots, why should it prohibit spaces,
which are also allowed in email address local parts?

I support the prohibition of all other whitespace characters, because
it would be nasty to distinguish between different kinds of whitespace,
but I'm not so confident about the prohibition of ASCII space.  That one
could stand some more scrutiny.

AMC



From owner-idn@ops.ietf.org  Thu Feb  7 00:31: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 AAA12170
	for ; Thu, 7 Feb 2002 00:31:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yh4V-0001nH-00
	for idn-data@psg.com; Wed, 06 Feb 2002 21:26:11 -0800
Received: from friendly.realnames.com ([63.251.238.102])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Yh4U-0001nB-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 21:26:10 -0800
Received: (qmail 1228 invoked by uid 104); 7 Feb 2002 05:26:09 -0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.828838 secs); 07 Feb 2002 05:26:09 -0000
Received: from heaven.internal.realnames.com (10.1.5.39)
  by friendly.realnames.com with SMTP; 7 Feb 2002 05:26:08 -0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:2457]) by heaven.internal.realnames.com
	Mail essentials (server 2.422) with SMTP id: <254547@heaven.internal.realnames.com>
	 for ; Wed, 6 Feb 2002 9:21:27 PM -0800
	smtpmailfrom  
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 6 Feb 2002 21:25:36 -0800
Message-ID: <7FC3066C236FD511BC5900508BAC86FE919688@trestles.internal.realnames.com>
From: Yves Arrouye 
To: "'IETF idn working group'" ,
        "Eric A. Hall"
	 
Subject: RE: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Date: Wed, 6 Feb 2002 21:22:56 -0800 
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

> "Eric A. Hall"  wrote:
> 
> > If you are going to be moving SOME of the prohibited characters from
> > nameprep to the IDNA hostname processing, then you need to 
> move ALL of
> > them at that stage.
> 
> There are some code points that should be prohibited in all
> internationalized textual domain names.  The private use code points,
> noncharacter code points, surrogate codes, and left-to-right mark are
> some of the best examples of such code points.  These prohibitions do
> indeed belong in nameprep.

My understanding is that Eric was talking about the octet values? I.e.
0000..00FF only since these are the ones which already have an
interpretation (i.e. LDH only plus the hyphen rule for hostnames, but any
octet for STD 13, ...).

And I agree with Adam about the need to scrutinize the other ASCII
codepoints that are still prohibited.

YA



From owner-idn@ops.ietf.org  Thu Feb  7 00:31: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 AAA12178
	for ; Thu, 7 Feb 2002 00:31:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yh3y-0001mM-00
	for idn-data@psg.com; Wed, 06 Feb 2002 21:25:38 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yh3x-0001m0-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 21:25:37 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id VAA08550
	for ; Wed, 6 Feb 2002 21:25:25 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id VAA27218
	for ; Wed, 6 Feb 2002 21:25:36 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id VAA27208;
	Wed, 6 Feb 2002 21:25:34 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id VAA09578;
	Wed, 6 Feb 2002 21:24:34 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id VAA01767;
	Wed, 6 Feb 2002 21:25:31 -0800 (PST)
Date: Wed, 6 Feb 2002 21:25:31 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202070525.VAA01767@birdie.sybase.com>
To: lsb@postel.co.kr
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Cc: idn@ops.ietf.org, jenkins@apple.com
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Soobok Lee stated:

> Unicode is not designed for identifiers use but rather for
> display or printing devices,  from the beginning. 

This is manifestly untrue. Unicode 1.0, published in 1991
specifically talks about "comparing text in operations such
as determining sort order of two strings, or filtering or
matching strings." And the earliest implementations of
Unicode, which were in development as early as 1990, were
already making use of Unicode strings as identifiers and
object labels. I know, because I was directly involved in
one such implementation.

It is true, however, that the Unicode Standard itself didn't
get around to making recommendations about how to deal
with Unicode identifiers until Unicode 2.0 in 1996. So
I can see how people might be confused about the design
intent.

> But,
> Unicode is ever evolving to expand its application areass.

The way I would put that is that more and more application
areas are coming to grips with the implications of working
with the Universal Character Set.

> It's astonishing Unicode has not yet any concrete lists of 
> TC/SC 1:1 and 1:n equivalences.

Partial lists have been available since Unicode 2.0, with the
first publication of Unihan.txt. And with each major or minor
version of Unicode, tremendous effort has been expended for
further refining and adding to the immense amount of information
provided in Unihan.txt about all the Han characters, their
sources, and variants. Unicode 3.2 will see another significant
step forward in the refinement of that information.

But the only thing "astonishing" here is that you find it
astonishing that no simple, complete TC/SC listing has yet been
compiled. The Unicoders in this discussion have been asserting
that the issue of "simplified" and "traditional" variants in
Han is enormously complex, and is not amenable to simple,
uncontextualized lists. Why then are you astonished that we
have not produced a simple, uncontextualized list?

You want a published list? Go buy Sanseido's Unicode Kanji
Information Dictionary. (ISBN 4-385-13690-4) Then look at
all the crossreferences (of distinct types) and the annotations
of simplified forms (kantaiji) and variant forms (itaiji).
Then tell me how long you think it would take to digest that
down to a consensus list that would be acceptable for IDN
use and which would provide user-tested "acceptability" for
both Chinese and Japanese users.

> I admit UNicode is the best solution as for now , but not the sufficienly
> mature solution  enough to serve the global language communities,
> especially chinese.

This is not an opinion apparently shared by the Chinese
government, which has recently mandated the use and implementation
of their latest national standard, GB 18030-2000, which contains
the exact same repertoire of Han characters as in Unicode 3.0
(and ISO/IEC 10646-1:2000), with all the same warts and variant
idiosyncrasies that you you claim renders Unicode an insufficiently
mature solution to serve the Chinese language community.
Who's right here?

> IDN deployment is not a reversible process.

That much I agree with. ;-)

--Ken




From owner-idn@ops.ietf.org  Thu Feb  7 00:48: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 AAA12393
	for ; Thu, 7 Feb 2002 00:48:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YhIm-0002HP-00
	for idn-data@psg.com; Wed, 06 Feb 2002 21:40:56 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YhIl-0002HJ-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 21:40:55 -0800
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 VAA24948
	for ; Wed, 6 Feb 2002 21:40:54 -0800
Message-Id: <5.1.0.14.2.20020206213440.0304d4f0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Feb 2002 21:40:38 -0800
To: idn@ops.ietf.org
From: Dave Crocker 
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
In-Reply-To: <200202070525.VAA01767@birdie.sybase.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 09:25 PM 2/6/2002 -0800, Kenneth Whistler wrote:
>Soobok Lee stated:
>
> > Unicode is not designed for identifiers use but rather for
> > display or printing devices,  from the beginning.
>
>This is manifestly untrue. Unicode 1.0, published in 1991
>specifically talks about "comparing text in operations such
>as determining sort order of two strings, or filtering or
>matching strings."

After an IETF working group thoroughly explores a problem and its solution, 
the only effect that comes from re-hashing old issues is delay of the 
working group effort.

A desire to be polite and diligent has turned into a denial of service 
attack on this important technical effort.

There have been no new technical criticisms of the IDN specifications and 
the criticisms that are being raised pertain to matters that are beyond the 
scope of the working group and, indeed, pertain to an open research topic.

Hence it is time to close discussion and advance the specifications.

It certainly is time for polite, diligent people to stop responding to 
ofte-rrepeated, very old criticisms of the IDN work.  Those making the 
challenges are interested in solving an important problem that is beyond 
the scope of the IDN effort.  They should be encourage to continue their 
efforts, but not in the IDN working group.  Continued discussion of their 
concerns validates their belief that the IDN working group must focus on 
this topic.

Please folks, let's end this unproductive debate.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Feb  7 00:56: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 AAA12563
	for ; Thu, 7 Feb 2002 00:56:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YhTB-0002c7-00
	for idn-data@psg.com; Wed, 06 Feb 2002 21:51:41 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YhTA-0002bo-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 21:51:40 -0800
Received: from MASTER ([210.217.27.236])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g175pUR31311;
	Thu, 7 Feb 2002 14:51:30 +0900
Message-ID: <026f01c1af9b$74963fc0$ec1bd9d2@temp>
From: "Soobok Lee" 
To: "Kenneth Whistler" 
Cc: , 
References: <200202070525.VAA01767@birdie.sybase.com>
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Date: Thu, 7 Feb 2002 14:51:14 +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


----- Original Message ----- 
From: "Kenneth Whistler" 
 > 
> > I admit UNicode is the best solution as for now , but not the sufficienly
> > mature solution  enough to serve the global language communities,
> > especially chinese.

I missed "in the identifier context".

> 
> This is not an opinion apparently shared by the Chinese
> government, which has recently mandated the use and implementation
> of their latest national standard, GB 18030-2000, which contains
> the exact same repertoire of Han characters as in Unicode 3.0
> (and ISO/IEC 10646-1:2000), with all the same warts and variant
> idiosyncrasies that you you claim renders Unicode an insufficiently
> mature solution to serve the Chinese language community.
> Who's right here?

Both are right. :-)


Soobok Lee




From owner-idn@ops.ietf.org  Thu Feb  7 01:11: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 BAA12721
	for ; Thu, 7 Feb 2002 01:11:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YhfN-0002yb-00
	for idn-data@psg.com; Wed, 06 Feb 2002 22:04:17 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YhfM-0002yV-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 22:04:16 -0800
Received: from iis.sinica.edu.tw (dhcp001 [140.109.18.221])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g175xPT25163;
	Thu, 7 Feb 2002 13:59:25 +0800 (CST)
Message-ID: <3C62195C.A6144C8@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 14:06:20 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Kenneth Whistler 
CC: idn@ops.ietf.org, jenkins@apple.com
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
References: <200202070413.UAA01752@birdie.sybase.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit



Kenneth Whistler gJG

> Janming said:
>
> > Two comments:
> >
> > 1. The TC/SC problem or variant problem comes from Unicode
>
> It does not.
>
> "The TC/SC problem" derives from 50 years of political history in
> China, where the PRC engaged in an orthographic revision of
> the writing system that Taiwan (and Hong Kong) did not, during
> the same time span that information technology was developed and
> rolled out on both sides of that political chasm. The result was
> the development of incompatible character encodings and
> input method editors tailored either for the "simplified" Chinese
> of the PRC or the "traditional" Chinese of Taiwan and Hong Kong.

This is true for TC/SC problem. But, the variant problem roots in the
long history of Han characters. You might be interested in taking a
peek at the problem at one of the Chinese or Japanese dictionaries on
Han variants.

> This was not a "problem" to end users before the Internet, because
> never the twain did meet, and computer technology generally
> didn't have to support both, but only one choice at any one
> site. Furthermore, traditional IME's didn't support entry of
> simplified characters, even if the traditional character encodings
> (like CNS) nominally had them in the list; and vice versa.
>
> Now it *is* a problem to end users, because the Internet and
> the web, and changed political conditions, and globalization
> mean that everybody has to deal with all of the characters in
> one context or another.
>

Try Windows 2000 by yourself. You could use their IME to input
TC, SC and even Japanese Han characters. Thanks to Unicode 2.0.

>
> I would accept a reformulation that:
>
>   A. The availability of Unicode-enabled systems, such as
>      Windows 2000, with IME's that can support either traditional
>      or simplified characters, and fonts that display both,
>      has made the preexisting TC/SC problem acutely visible
>      to end users on their computers.
>
>   B. The move to Unicode implementations means that mingling
>      of traditional and simplified orthographies is easier.
>      In effect, users now have the rope to hang themselves,
>      if they so desire. Whereas, before, the constraints of
>      the deployment of IME's and fonts generally meant that
>      you couldn't easily mix SC/TC, even when the code page
>      nominally supported it.
>

I would accept A with minor modification as follows. B is not true.

A. The availability of Unicode-enabled systems, such as
     Windows 2000, with IME's that can support BOTH traditional
     or simplified characters, and fonts that display both,
     has made the preexisting TC/SC problem acutely visible
     to end users on their computers.


>
> > and the
> > decision
> >    to adopt Unicode as the basis to develop IDN technology.
>
> And the alternative is ... ?
>
> What character encoding alternative at this point in history
> would not have the exact same problem? Certainly no choice
> of a current national character encoding out of China itself
> would avoid the exact same problems you attribute to Unicode.
>
> But you are going to have to pick *some* encoding for the
> characters you represent in domain names. If not Unicode,
> then what?

My personal opinion after consulting several experts in Han characters
is to find an international organization, e.g., Unicode Consortium, to
host the standardization of variants. They are also willing to
 collaborate
with  CJK experts from other countries and regions. Some of their
suggestions are described in the "phased implementation" draft.

>
>
> > If the
> > working
> >    group chooses to use Unicode as basis, then it becomes a partial
> > solution
> >    to the "global" IDN problem because of this side-effect.
> > 2. We do not want to delay your process either. Please refer to the
> > draft
> >    "Phased Implementation of Internationalized Domain Names in
> > Applications"
> >    for more details.
>
> I have looked at that draft in detail, and see no solution
> offered -- but only denial and vain hope. In short, a proposal
> to simply exclude *all* the Chinese characters from IDN, with
> a vague promise that someday someone will figure it all out
> and decide which of 20,902 characters are o.k. to let back in
> and which are only variants of the "good" ones. That promise
> will be dashed on the rocks of the reality of complexity in
> Chinese character variation -- and no code point based solution,
> Unicode or otherwise, is going to fix it.

Without a internationalized dictionary for Han variants, the current
IDN proposals are bringing side-effects to users and holders of
domain names of Han characters.

>
>
> And in the meantime, the Phased Implementation proposal merely
> exports the Chinese SC/TC "problem" in a way that also disables
> IDN for Japan. I don't think that is acceptable.
>
> --Ken

I appreciate your loving for Japanese. But, if you do care about
Japanese, why did you ignore Chinese and Taiwanese, and perhaps
even more silent Japanese and Korean out there?




From owner-idn@ops.ietf.org  Thu Feb  7 01:36: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 BAA12987
	for ; Thu, 7 Feb 2002 01:36:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yi2L-0003lg-00
	for idn-data@psg.com; Wed, 06 Feb 2002 22:28:01 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yi2K-0003la-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 22:28:00 -0800
Received: from [68.52.224.13] (account ehall HELO buffalo)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 54445 for idn@ops.ietf.org; Thu, 07 Feb 2002 00:27:21 -0600
Message-ID: <001101c1afa0$8d2dc620$5a0aa8c0@labs.ntrg.com>
From: "Eric A. Hall" 
To: "IETF idn working group" 
References: <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>  <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com> <20020207030125.GC5125@nicemice.net> <3C61F87E.6B7CBD83@ehsco.com> <20020207043706.GA7193@nicemice.net>
Subject: Re: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Date: Thu, 7 Feb 2002 00:27:42 -0600
Organization: EHS Company
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


"Adam M. Costello" wrote:

> There are some code points that are prohibited in host names, but not
> in all textual domain names.

These include the octet values to which I was referring. Jut as a domain
name can include underscore and period, it can also include the
codepoint values for NUL, BS, CRLF, or any other value in the range of
0x00-0xFF.

> I support the prohibition of all other whitespace characters, because
> it would be nasty to distinguish between different kinds of
whitespace,
> but I'm not so confident about the prohibition of ASCII space.  That
one
> could stand some more scrutiny.

Unless you are planning to update STD13, all octet values need to be
passed
for non-hostname domain names.





From owner-idn@ops.ietf.org  Thu Feb  7 03:11: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 DAA22259
	for ; Thu, 7 Feb 2002 03:11:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YjOH-0006Rp-00
	for idn-data@psg.com; Wed, 06 Feb 2002 23:54:45 -0800
Received: from law2-f75.hotmail.com ([216.32.181.75] helo=hotmail.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YjOG-0006Rj-00
	for idn@ops.ietf.org; Wed, 06 Feb 2002 23:54:44 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 6 Feb 2002 23:54:44 -0800
Received: from 68.80.0.130 by lw2fd.hotmail.msn.com with HTTP;
	Thu, 07 Feb 2002 07:54:44 GMT
X-Originating-IP: [68.80.0.130]
From: "Ric Johnson" 
To: phoffman@imc.org
Cc: idn@ops.ietf.org
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Date: Thu, 07 Feb 2002 02:54:44 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 07 Feb 2002 07:54:44.0429 (UTC) FILETIME=[B4B82FD0:01C1AFAC]
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Mr. Hoffman,

It it possible to set up a seperate mailing list for these types of 
discussions? I joined this list to work on DEVELOPMENT, and it seems to me 
that several members are abusing this forum.

My suggestion is that if anyone wants to continue to beat this dead horse, 
they should do it off THIS list, and anyone that does not understand this 
simple request should be BOUNCED.

Thanks for all your hard work!
Ric Johnson




>From: Paul Hoffman / IMC 
>To: idn@ops.ietf.org
>CC: Elisabeth.Porteneuve@cetp.ipsl.fr, deng@cnnic.net.cn, 
>erin@twnic.net.tw,   mclaughlin@pobox.com, Marc.Blanchet@viagenie.qc.ca, 
>ajm@icann.org,   alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, 
>fred@cisco.com,   harald@alvestrand.no, hlqian@cnnic.net.cn, 
>htk@eecs.harvard.edu,   huangk@alum.sinica.edu, iab@isi.edu, 
>idn@ops.ietf.org, iesg@ietf.org,   jasonho@umac.mo, jet-member@nic.ad.jp, 
>jseng@pobox.org.sg, klensin@jck.com,   lee@whale.cnnic.net.cn, 
>lynn@icann.org, mao@cnnic.net.cn, mkatoh@mkatoh.net,   mouhamet@next.sn, 
>narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com,   
>qhhu@public.bta.net.cn, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,   
>snw@twnic.net.tw, sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw,   
>vcerf@mci.net, whzhang@cnnnic.net.cn, wschen@twnic.net.tw,   
>wuch@gate.sinica.edu.tw, yktham@umac.mo
>Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
>Date: Wed, 6 Feb 2002 20:07:29 -0800
>
>At 11:29 AM +0800 2/7/02, hoho wrote:
>>1. The TC/SC problem or variant problem comes from Unicode and the
>>decision
>>    to adopt Unicode as the basis to develop IDN technology. If the
>>working
>>    group chooses to use Unicode as basis, then it becomes a partial
>>solution
>>    to the "global" IDN problem because of this side-effect.
>
>This is exactly wrong. The decision to use the ISO/IEC 10646
>(Unicode) character repertoire was made to make IDN a global
>solution. Maybe I missed it, but what other solution has been
>proposed that is more global than using 10646? We already discussed
>this in detail on the mailing list many times, and no one came up
>with anything more global.
>
>>2. We do not want to delay your process either. Please refer to the
>>draft
>>    "Phased Implementation of Internationalized Domain Names in
>>Applications"
>>    for more details.
>
>The "phased implementation" draft is sure to cause a great deal more delay.
>
>- The draft has serious technical errors: the list in section 1 does
>not even vaguely match the list given in Appendix B.
>
>- As the draft admits, adopting the draft would have a very serious
>negative consequence on Japan and Korea. It is very insulting to say
>to people of other countries "because we have problems we cannot
>solve with our script, you will be reduced to using phonetic spelling
>of your names until we come up with a solution, even though we have
>failed numerous times in the past trying to do this". Discussing the
>political ramifications of this consequence could take years.
>
>- The draft is open-ended about what code points would be prohibited.
>Discussing whether to also prohibit additional code points will
>certainly delay IDN. If you are going to make this draft actually
>represent all of the scripts for which IDN is not perfect, the list
>will be huge, and it will probably affect many billions more people.
>
>If you feel that the IDN WG can deal with all those problems without
>delaying IDN, you have not been paying attention to the way this WG
>moves. :-)
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.




From owner-idn@ops.ietf.org  Thu Feb  7 09:14: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 JAA27320
	for ; Thu, 7 Feb 2002 09:14:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yp3d-000IMj-00
	for idn-data@psg.com; Thu, 07 Feb 2002 05:57:49 -0800
Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yp3d-000IMY-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 05:57:49 -0800
Received: from maila.telia.se (localhost [127.0.0.1])
	by maila.telia.se (8.11.6/8.11.6) with ESMTP id g17Dvkc11022
	for ; Thu, 7 Feb 2002 14:57:46 +0100 (MET)
Received: from trab.se (terra.malmo.trab.se [131.115.48.22])
	by maila.telia.se (8.11.6/8.11.6) with ESMTP id g17Dvgx10959;
	Thu, 7 Feb 2002 14:57:46 +0100 (MET)
Message-ID: <3C6287AD.3E48446B@trab.se>
Date: Thu, 07 Feb 2002 14:57:01 +0100
From: Dan Oscarsson 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org, djb@cr.yp.to
Subject: Re: [idn] Alpha Online
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dan Bernstein wrote:
>

>Case insensitivity is quite a bit of added work for implementors, and it
>dramatically expands the number of opportunities for visual confusion,
>as well as the severity of the confusion. The only counterargument is
>the unjustified speculation that users are too stupid to handle a world
>of case-sensitive names---even though URLs are already case-sensitive,
>specifically in path names.

I have had case insensitivity in my software from the beginning. It is
not
hard work. Very easy.
My web server is case insensitive in the URL path names. Much easier for
the user that way. The URLs can use mixed case to make the easier
to read, but the user can enter them in any way.

Case sensitivity does increase confusion for the user. When you speak
the case of letters are not heard so the user do not know what to type.
Many use mixed case to enhance readability, but when search for a match,
case should be ignored. An example on the case sensitive confusion:
in Unix the file names are case sensitive, and you can have a Makefile
and a makefile. And both two will be searched by make which selects
one before the other. Depending on how you sort your filenames, you
might not even see that you have two makefiles and therefore not
understand why things do not work because the wrong one is used
by make.

   Dan



From owner-idn@ops.ietf.org  Thu Feb  7 11:28: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 LAA01364
	for ; Thu, 7 Feb 2002 11:28:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YrHk-000Nes-00
	for idn-data@psg.com; Thu, 07 Feb 2002 08:20:32 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YrHk-000Nel-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 08:20:32 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Thu, 7 Feb 2002 08:36:16 -0800
Message-ID: <00cd01c1aff4$b36c8840$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "Kenneth Whistler" 
Cc: , 
References: <200202070302.TAA01733@birdie.sybase.com>
Subject: Re: [idn] Internet Draft - Phased Implementation for IDNA
Date: Thu, 7 Feb 2002 11:30:04 -0500
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

Hi Kenneth,

> And I think the answer is clearly no.
>
> The problem, of course, is that the very term "Simplified Chinese
> code point" is unclearly defined.

The term "Simplified Chinese code point" need *not* be clearly defined
as this stage.  At this stage, we are simply leaving the door open by
prohibiting some code point and letting as much as possible move
forward.  Most likely that will get more support from this WG then
prohibiting *all* the HanZi.

> But don't get me started on gui1,
> as I might have to start talking about turtles... ;-)
>

No...no..., please do not start the turtle thing...
(For those who are not fimiliar with the Chinese language, a Chinese
word that starts with turtle is a very very bad word.)

Thanks,
Ben





From owner-idn@ops.ietf.org  Thu Feb  7 13:01: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 NAA03819
	for ; Thu, 7 Feb 2002 13:01:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ysin-0001Ci-00
	for idn-data@psg.com; Thu, 07 Feb 2002 09:52:33 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Ysim-0001Cc-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 09:52:32 -0800
Received: (qmail 10043 invoked by uid 1001); 7 Feb 2002 17:49:28 -0000
Date: 7 Feb 2002 17:49:28 -0000
Message-ID: <20020207174928.10933.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Alpha Online
References: <3C6287AD.3E48446B@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dan Oscarsson writes:
> I have had case insensitivity in my software from the beginning. It is
> not hard work. Very easy.

We're not talking about folding A-Z into a-z. We're talking about case
insensitivity for _Unicode_. Case insensitivity for _internationalized_
domain names requires quite a bit of extra code in many programs.

Consider, for example, a system administrator telling his MTA ``accept
mail for pi.cr.yp.to'' with a Greek pi. Case insensitivity for IDNs
means that the MTA also has to accept mail for Pi.cr.yp.to.

(Of course, Costello is still denying that MTAs, DNS servers, etc. are
affected by IDNA at all, because Costello refuses to acknowledge that
these programs have user interfaces.)

Interoperability requires that we continue folding A-Z into a-z inside
domain names. But it doesn't require insensitivity for non-ASCII names.

> When you speak
> the case of letters are not heard so the user do not know what to type.

``Capital T, lowercase e, capital X.''

Typical users avoid all these hassles by consistently using lowercase,
contrary to the claims made by certain people on this mailing list. For
example, someone here said that we needed uppercase because the World
Health Organization was ``much easier to recognize'' as WHO.org than as
who.org; but the WHO web site consistently uses lowercase who.int.

Anyway, (1) your notion of speakability is contrary to the entire
concept of IDNs, and (2) I don't see you telling the standardization
groups for UNIX, URLs, French, etc. that you demand insensitivity.

---Dan



From owner-idn@ops.ietf.org  Thu Feb  7 16:18: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 QAA10117
	for ; Thu, 7 Feb 2002 16:18:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvio-0008sT-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:04:46 -0800
To: Elliotte Rusty Harold 
From: John Hudson 
Subject: [idn] Re: Unicode and Security
Cc: unicode@unicode.org, idn@ops.ietf.org
In-Reply-To: 
References: <20020207175333.GA1632@x8b4e53d6.dhcp.okstate.edu>
 
 
 <20020207175333.GA1632@x8b4e53d6.dhcp.okstate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Date: Thu, 07 Feb 2002 13:04:46 -0800

At 10:21 2/7/2002, Elliotte Rusty Harold wrote:

>I'm not sure Unicode can be fixed at this point. The flaws may be too
>deeply embedded.

What flaws? The fact that glyphs in different scripts may be similar or
identical in some typefaces, and misrepresentation is possible because
Unicode separately encodes these glyphs as distinct characters? I'm
sorry,
but that is the nature of writing systems, and Unicode's encoding of
these
characters is inherited from existing standard character sets. Is this a
flaw? Is this as great a flaw as glyph-based encoding would have been?
Is
it as great a flaw as hampering backwards compatibility with other
encodings would have been?

In your examples, you seem to ignore two things:

1. The software industry has already devised mechanisms to protect
against
e-mail forgery, e.g. private-public key encryption.

2. What you describe is criminal fraud and there are laws to protect
against such 'spoofing' and to punish those who perpetrate it.

John Hudson

Tiro Typeworks www.tiro.com
Vancouver, BC tiro@tiro.com

>... es ist ein unwiederbringliches Bild der Vergangenheit,
das mit jeder Gegenwart zu verschwinden droht, die sich
nicht in ihm gemeint erkannte.

>... every image of the past that is not recognized by the
present as one of its own concerns threatens to disappear
irretrievably.
                                               Walter Benjamin






From owner-idn@ops.ietf.org  Thu Feb  7 16:19: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 QAA10146
	for ; Thu, 7 Feb 2002 16:19:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvmv-00094o-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:09:01 -0800
From: David Starner 
To: Elliotte Rusty Harold 
Cc: Unicode List , idn@ops.ietf.org,
        schneier@counterpane.com
Subject: [idn] Re: Unicode and Security
Message-ID: <20020207180928.GA1770@x8b4e53d6.dhcp.okstate.edu>
References: 
   
   
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
Date: Thu, 07 Feb 2002 13:09:01 -0800

On Thu, Feb 07, 2002 at 12:22:18PM -0500, Elliotte Rusty Harold wrote:
> Interestingly, my attack works with a single character representation
> (Unicode). It is not dependent on multiple charsets.

It also works with EUC-JP (and other Japanese charsets), all 8-bit
Russian representations, all 8-bit Greek representations . . .

>  The problem needs to be fixed closer to the source.

How about a solution that doesn't involve the destruction of Unicode as
a useful tool? The fact that MD5 sums matching doesn't prove that the
files match is not a bug in MD5 sums. Likewise, the fact that glyphs may
look alike in a _character_ is not a bug in the character encoding.

--
David Starner - starner@okstate.edu, dvdeug/jabber.com (Jabber)
Pointless website: http://dvdeug.dhis.org
What we've got is a blue-light special on truth. It's the hottest thing
with the youth. -- Information Society, "Peace and Love, Inc."





From owner-idn@ops.ietf.org  Thu Feb  7 16:21: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 QAA10204
	for ; Thu, 7 Feb 2002 16:21:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YvnD-00095A-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:09:19 -0800
Date: Thu, 07 Feb 2002 10:16:26 -0800
To: Elliotte Rusty Harold ,
        Unicode List 
From: Barry Caplan 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org, schneier@counterpane.com
In-Reply-To: 
References: 
 
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote:
>I've been thinking about security issues in Unicode, and I've come up
with
>one that's quite scary and worse than any I've heard before. It uses
only
>plaintext, no fonts involved, doesn't require buggy software, and works
>over e-mail instead of the Web. All it requires added to the existing
>infrastructure is internationalized domain names. So in the hope that
this
>becomes a self-defeating prophecy, here's the scenario:
>
>"Can you please update me on your budget?" Bob, noticing that the
>e-mail appears to come from Alice, whom he knows and trusts, fires off
a
>reply with his confidential information. Only it doesn't go to Alice.
It
>goes to me. I can then reply to Bob, asking for clarification or more
>details. I can ask him to attach the latest build of his software. I
can
>carry on a conversation in which Bob believes me to be Alice and spills
>his guts. This is very, very bad.


This is precisely the problem digital signing is meant to solve. Signing
means that Alice has encrypted the message with her private key before
sending to Bob. Bob then unencrypts the message using Alice's public
key.
If the message does not unencrypt, then Bob should not trust that the
message is from Alice. This algorithm works independent of transport
mechanism (email, etc.), or domains. Alice's key stays with Alice,not
with
the domain. Of course, how you exchange trusted keys in the first place
is
another matter, but I am sure this is all covered on a security FAQ
somewhere.


>E-mail forgery has been a problem for a long time, but it's always been
>one-way. You couldn't trick somebody into sending you a reply because
>doing so required using a different e-mail address than the one they
>expected, thus revealing the message as forged.

There are many many ways to get a response from someone via email, even
if
the address is not recognized or forged. Most involve social engineering
approaches more than anything else. My mailbox filled with spam will
attest
the that!


>With a Unicode enabled mailer, that's no longer true. If the fonts Bob
>(not me, but Bob) chooses for his e-mail program do not make a clear
>distinction between an o and an omicron, this works. There are lots of
>other attacks. The Cyrillic and Greek alphabets provide lots of options
>for replacing single letters in Latin domain names.


Unless all messages are signed (technically feasible) , then there is no
trust at all. When Outlook/Exchange supports, in fact requires, messages
to
be signed, then this problem will start to dwindle away, at least in the
email realm.

Of course if there is a method to judge the level of trust for properly
signed messages that arrive from folks you don't know (a human
failability), then knowing the origin of the message might not help much
either. My inbound spam can be verifiably signed, but it is still spam.

>In other words, it's not our fault. Blame the client software. Sounds
>distressingly like the Unicode Consortium's approach to these issues.
>Interestingly, my attack works with a single character representation
>(Unicode).


Your attack is only a social engineering attack, not a technical
weakness
inherent in any protocol, or character set (even though there may be
such
issues)

Barry






From owner-idn@ops.ietf.org  Thu Feb  7 16:21: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 QAA10228
	for ; Thu, 7 Feb 2002 16:21:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvm4-00091o-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:08:08 -0800
Date: Thu, 7 Feb 2002 12:22:18 -0500
To: Unicode List 
From: Elliotte Rusty Harold 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org, schneier@counterpane.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

I've been thinking about security issues in Unicode, and I've come up
with one that's quite scary and worse than any I've heard before. It
uses only plaintext, no fonts involved, doesn't require buggy
software, and works over e-mail instead of the Web. All it requires
added to the existing infrastructure is internationalized domain
names. So in the hope that this becomes a self-defeating prophecy,
here's the scenario:

I as a reporter or industrial spy or detective working on a divorce
case, have learned the identities and internal e-mail addresses of
two people, call them Alice and Bob, at Microsoft (or just about any
other large company). I've somehow communicated with these people
personally, for instance on an e-mail list completely unrelated to
work but for which they use their work e-mail so I'm familiar with
their style and signature files. Or perhaps, I've communicated with
them on work related matters before. In any case, it's not hard to
get two people who know each other at a large company to send you
e-mail. Of course, they would presumably be careful not to give me
secret company information since they know they're talking to an
outsider.

For the sake of argument, let's call the company they work at
Microsoft, but this attack could hit most companies with a .com
address. Let's say I register microsoft.com, only the fifth letter
isn't a lower-case Latin o. It's actually a lower case Greek omicron.
I then forge a believable letter from alice@microsoft.com to
bob@microsoft.com saying "Can you please update me on your budget?"
Bob, noticing that the e-mail appears to come from Alice, whom he
knows and trusts, fires off a reply with his confidential
information. Only it doesn't go to Alice. It goes to me. I can then
reply to Bob, asking for clarification or more details. I can ask him
to attach the latest build of his software. I can carry on a
conversation in which Bob believes me to be Alice and spills his
guts. This is very, very bad.

E-mail forgery has been a problem for a long time, but it's always
been one-way. You couldn't trick somebody into sending you a reply
because doing so required using a different e-mail address than the
one they expected, thus revealing the message as forged. With a
Unicode enabled mailer, that's no longer true. If the fonts Bob (not
me, but Bob) chooses for his e-mail program do not make a clear
distinction between an o and an omicron, this works. There are lots
of other attacks. The Cyrillic and Greek alphabets provide lots of
options for replacing single letters in Latin domain names.

I'm not sure whether or not the internationalized domain names
working group has fully grokked this or not. Like Unicode, they seem
to be trying to pass the buck. In particular, they state

:

Specifying requirements for internationalized domain names does not
itself raise any new security issues. However, any change to the DNS
MAY affect the security of any protocol that relies on the DNS or on
DNS names. A thorough evaluation of those protocols for security
concerns will be needed when they are developed. In particular, IDNs
MUST be compatible with DNSSEC and, if multiple charsets or
representation forms are permitted, the implications of this
name-spoof MUST be throughly understood.

In other words, it's not our fault. Blame the client software. Sounds
distressingly like the Unicode Consortium's approach to these issues.
Interestingly, my attack works with a single character representation
(Unicode). It is not dependent on multiple charsets. I don't know if
the IDN working group has thought of this problem. I hope they have,
and consider it their responsibility to prevent. I also hope the
Unicode consortium and vendors of client software think about these
problems. But I don't think we can count on client software getting
this right. (Hell, Microsoft, can't even stop e-mail from running
scripts.)  The problem needs to be fixed closer to the source.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+





From owner-idn@ops.ietf.org  Thu Feb  7 16:21: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 QAA10240
	for ; Thu, 7 Feb 2002 16:21:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YvmT-00092K-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:08:33 -0800
Date: Thu, 7 Feb 2002 10:28:18 -0700
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v480)
Cc: Kenneth Whistler , idn@ops.ietf.org
To: hoho 
From: "John H. Jenkins" 
In-Reply-To: <3C62195C.A6144C8@iis.sinica.edu.tw>
Message-Id: <13B4233A-1BF0-11D6-B3E1-003065F9CD7C@apple.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.480)
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


On Wednesday, February 6, 2002, at 11:06 PM, hoho wrote:

>
> This is true for TC/SC problem. But, the variant problem roots in the
> long history of Han characters. You might be interested in taking a
> peek at the problem at one of the Chinese or Japanese dictionaries on
> Han variants.
>

As Ken well knows.  It's a nasty, nasty problem in general, and one
which
Unicode is trying to address.  At its last meeting the UTC agreed to
request that the IRG start to work on definitive variant data for the
CJK
repertoire of Unicode/10646.

If there is any body in the IT standardization community which should
own
the problem, it's the IRG.  It's international, multilingual, and has
the
longest and best experience with the characters involved.

>>
>>   B. The move to Unicode implementations means that mingling
>>      of traditional and simplified orthographies is easier.
>>      In effect, users now have the rope to hang themselves,
>>      if they so desire. Whereas, before, the constraints of
>>      the deployment of IME's and fonts generally meant that
>>      you couldn't easily mix SC/TC, even when the code page
>>      nominally supported it.
>>
>
> I would accept A with minor modification as follows. B is not true.
>

I would disagree here.  As you point out, Windows 2000 has the ability
to
mingle traditional and simplified orthographies because of Unicode 2.0.
Mac OS X now has the problem, too, because of Unicode 3.1.  In the past
on
the Mac, if you wanted to do Japanese you used the Japanese "code page,"
if you wanted to do traditional Chinese, you did the traditional Chinese
"code page," and if you wanted to do simplified Chinese, you used the
simplified Chinese "code page."  This inherent link between code page
and
nuanced version of a script was something Unicode intended to break.  In
the past, one had to deliberately work to mix the two, and the mixture
was
generally obvious.  This isn't true now.

>
> My personal opinion after consulting several experts in Han characters
> is to find an international organization, e.g., Unicode Consortium, to
> host the standardization of variants. They are also willing to
>  collaborate
> with  CJK experts from other countries and regions. Some of their
> suggestions are described in the "phased implementation" draft.

Again, this is really the IRG's job.  The main problem with handing it
off
to the IRG is that they are not the fastest-moving standards body in
history.

Another part of the problem is that the data *is* out there.  Ken
mentions
the Sanseido dictionary.  I've got a CD of data from Taiwan on Chinese
variants, and the HKSAR government has a Web page.  I know that MS has
data they're sitting on which is used in Office.  Unicode's data has
been
derived in the past by character set analysis, but we are currently
working on incorporating data from a commercial product, Wenlin, which
has
been donated to us.

Unfortunately, most of the people who have spent the time and energy to
develop this data don't want to contribute it to the public gratis,
which
is what would happen if it went into Unicode.  Even if we simply said
that
we wanted to take over the data from an authoritative source (Sanseido,
the Hanyu Da Zidian), we'd probably have to get legal permission to do
so.

And there's the additional problem that nobody has a clear model, at
least
that I've seen, that captures the full plethora of variant "types" with
a
reasonable taxonomy and sufficient clarity that it can be used in
simple,
algorithm-generated, lexical-analysis-free situations.

> Without a internationalized dictionary for Han variants, the current
> IDN proposals are bringing side-effects to users and holders of
> domain names of Han characters.
>

I agree with Ken that it's not clear how *anything* could both include
hanzi in IDN *and* be free from unpleasant side effects.

>
> I appreciate your loving for Japanese. But, if you do care about
> Japanese, why did you ignore Chinese and Taiwanese, and perhaps
> even more silent Japanese and Korean out there?
>

I'm sure it wasn't intentional.  I believe that Ken's point is that you
can't do a Chinese-only solution here.  (And I'll naturally bring up the
Cantonese speaking population of the world, as just adding to the mess.)

==========
John H. Jenkins
jenkins@apple.com
jenkins@mac.com
http://homepage.mac.com/jenkins/






From owner-idn@ops.ietf.org  Thu Feb  7 16:22: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 QAA10262
	for ; Thu, 7 Feb 2002 16:22:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvnr-00097l-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:09:59 -0800
From: David Starner 
To: Elliotte Rusty Harold 
Cc: Unicode List , idn@ops.ietf.org,
        schneier@counterpane.com
Subject: [idn] Re: Unicode and Security
Message-ID: <20020207180928.GA1770@x8b4e53d6.dhcp.okstate.edu>
References: 
   
   
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
Date: Thu, 07 Feb 2002 13:09:59 -0800

On Thu, Feb 07, 2002 at 12:22:18PM -0500, Elliotte Rusty Harold wrote:
> Interestingly, my attack works with a single character representation
> (Unicode). It is not dependent on multiple charsets.

It also works with EUC-JP (and other Japanese charsets), all 8-bit
Russian representations, all 8-bit Greek representations . . .

>  The problem needs to be fixed closer to the source.

How about a solution that doesn't involve the destruction of Unicode as
a useful tool? The fact that MD5 sums matching doesn't prove that the
files match is not a bug in MD5 sums. Likewise, the fact that glyphs may
look alike in a _character_ is not a bug in the character encoding.

--
David Starner - starner@okstate.edu, dvdeug/jabber.com (Jabber)
Pointless website: http://dvdeug.dhis.org
What we've got is a blue-light special on truth. It's the hottest thing
with the youth. -- Information Society, "Peace and Love, Inc."






From owner-idn@ops.ietf.org  Thu Feb  7 16:22: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 QAA10274
	for ; Thu, 7 Feb 2002 16:22:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvny-00098W-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:10:06 -0800
Date: Thu, 7 Feb 2002 13:21:29 -0500
To: unicode@unicode.org
From: Elliotte Rusty Harold 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

>On Thu, Feb 07, 2002 at 10:34:20AM -0500, Elliotte Rusty Harold wrote:


>Unicode is a character encoding, not a glyph encoding. Furthermore,
it's
>a superset of a number of preexisting character sets, so that it was
>possible for those users to move to Unicode without problems. Since
>important preexisting character sets seperated Greek, Cyrillic and
Latin
>scripts, Unicode had to. Had Unicode not chosen to follow these
>principles, ISO 10646 would have, and it would have become the dominant
>character set, with the same problems.
>

I know why these choices were made. That has nothing to do with the
question of whether the finished product will or will not cause
security breaches.

>In any case, what is your solution? When the American Mathematical
>Society says "We need a SMALL CIRCLE for the mathematical texts", do
you
>say "no, we already have the unified LATGRKCRY SMALL O"? After they
show
>you that the two are distinct characters in their texts, do you still
>refuse because "someone might get confused"? The Universal Character
Set
>can't afford to not encode characters like that.
>

I'm not sure Unicode can be fixed at this point. The flaws may be too
deeply embedded. The real solution may involve waiting until
companies and people start losing significant amounts of money as a
result of the flaws in Unicode, and then throwing it away and
replacing it with something else. I don't like that solution, but not
liking it doesn't mean it ain't gonna happen as soon as Exxon loses a
few billion dollars because somebody spoofed them and thereby gained
access to their bidding plans for oil leases. Don't be surprised when
some large companies start issuing memos forbidding the use of
Unicode, or blocking all non-ASCII domain names at their firewall.

One possible solution at the domain name system level might be to
limit domain names to a single Unicode block or group. For instance,
Greek domain names could be allowed but not domain names that mix
Greek with Latin. Similarly, you couldn't mix Latin with Cyrillic or
Cyrillic with Greek. That would at least vastly reduce the
possibility for domain spoofing, if not eliminate it entirely.

Interesting tidbit: app1e.com (not APPLE.COM but APP1E.COM) is in
fact already registered. This attack may not be as theoretical as I
initially thought.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+






From owner-idn@ops.ietf.org  Thu Feb  7 16:23: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 QAA10310
	for ; Thu, 7 Feb 2002 16:23:06 -0500 (EST)
From: owner-idn@ops.ietf.org
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvpf-0009Et-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:11:51 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: [idn] RE: Unicode and Security
Date: Thu, 7 Feb 2002 13:47:35 -0500
To: idn-data@psg.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10310


From: 
To: , 
Cc: 
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> I'm not sure Unicode can be fixed at this point. The flaws may be
too 
> deeply embedded. The real solution may involve waiting until 
> companies and people start losing significant amounts of money as a 
> result of the flaws in Unicode, and then throwing it away and 
> replacing it with something else. I don't like that solution, but
not 
> liking it doesn't mean it ain't gonna happen as soon as Exxon loses
a 
> few billion dollars because somebody spoofed them and thereby
gained 
> access to their bidding plans for oil leases. Don't be surprised
when 
> some large companies start issuing memos forbidding the use of 
> Unicode, or blocking all non-ASCII domain names at their firewall.

"Doom!  Doom!  Doom!  End is nigh, repent ye sinners!"

> Interesting tidbit: app1e.com (not APPLE.COM but APP1E.COM) is in 
> fact already registered. This attack may not be as theoretical as I 
> initially thought.

Interestingly enough, I find this (and whitehouse.com and whitehouse.org,
and micros0ft.com, and ...) a good example for Unicode being largely irrelevant.
Sure, Unicode gives more possibilities for abuse, but I fail to see how
a character
encoding standard can stop people from being stupid and not using public
keys or
some other means of trust in cases where it matters.  Analogously, people will
keep opening executable attachments promising sex, regardless of whether
the
's', 'e', and 'x' are Latin letters or not.






From owner-idn@ops.ietf.org  Thu Feb  7 16: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 QAA10323
	for ; Thu, 7 Feb 2002 16:23:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvps-0009Fv-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:12:04 -0800
To: Unicode List 
From: Asmus Freytag 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org, schneier@counterpane.com
In-Reply-To: <5.1.0.14.2.20020207100223.02d54710@i18n.com>
References: 
 
 
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Date: Thu, 07 Feb 2002 13:12:04 -0800


>>At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote:
>>In other words, it's not our fault. Blame the client software. Sounds
>>distressingly like the Unicode Consortium's approach to these issues.
>>Interestingly, my attack works with a single character representation
>>(Unicode).

Substituting Greek for Latin works just as well with 8859-7 as with
Unicode. And (as I have argued separately) it will have to work with any
workable multilingual character set.

For the record it's worth noting that Unicode as a rule requires
additional
and strong justification before encoding characters that duplicate the
appearance of an existing character (but may have a different function).
The reason for that is not security, but the fact that such duplication
always carries with it the risk of unintentional misidentification and
therefore corrupt data. Such risk is mitigated for the characters from
different scripts (or different alphabets) since data entry methods
(keyboards) would normally allow access for only the proper character.
(If
I set my keyboard to Greek, I won't get the Latin "A" by accident).

Exceptions are found in some areas of punctuation. But good editing
software can make the distinction visible.
A security conscious browser could alert users to mixed Latin/Greek URLs
in
precisely the same way.

A./





From owner-idn@ops.ietf.org  Thu Feb  7 16:23: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 QAA10335
	for ; Thu, 7 Feb 2002 16:23:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvom-0009Bf-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:10:56 -0800
Reply-To: 
From: 
To: 
Subject: [idn] A question...
Date: Fri, 8 Feb 2002 02:31:35 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Content-Transfer-Encoding: 8bit

Dear all IDN members:

I'm a student at CSIE, National Taiwan University. I've recently heard
the
news for the
last call of IDN WG.

According the drafts,  my school should register 8 domain names
    ACE(U+53F0,U+6E7E,U+5927,U+5B66)
    ACE(U+53F0,U+6E7E,U+5927,U+5B78)
    ACE(U+53F0,U+7063,U+5927,U+5B66)
    ACE(U+53F0,U+7063,U+5927,U+5B78)
    ACE(U+81FA,U+6E7E,U+5927,U+5B66)
    ACE(U+81FA,U+6E7E,U+5927,U+5B78)
    ACE(U+81FA,U+7063,U+5927,U+5B66)
    ACE(U+81FA,U+7063,U+5927,U+5B78)
to let user to access my school (NTU, "xWj" in Big5) without
worrying
if he or she keys in right character.

and under each domain, we have to create 4 sub-domains for my
institite(CSIE,
"Tt" in BIG5),
    ACE(U+8D44,U+8BAF,U+7CFB)
    ACE(U+8D44,U+8A0A,U+7CFB)
    ACE(U+8CC7,U+8BAF,U+7CFB)
    ACE(U+8CC7,U+8A0A,U+7CFB)

and under each of 8*4=32 sub-domains, create 4 records for a web
server(web,
""
in BIG5)
    ACE(U+7DB2,U+9801)
    ACE(U+7DB2,U+9875)
    ACE(U+7F51,U+9801)
    ACE(U+7F51,U+9875)

And finally, i have to set all 8*4*4=128 domain names at the
configuration
files to
prevent error messages such as "host not found", or "page not found"
even if
i have
correctly set my DNS server.

If it is true, please do not pass these drafts!! It's too terrible,
there
are many Web servers,
mail servers, and other severs.....

If I'm wrong, please correct me, and please forgive my poor English.




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Thu Feb  7 16:26: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 QAA10395
	for ; Thu, 7 Feb 2002 16:26:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yvso-0009RG-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:15:06 -0800
Received: from smtp23.singnet.com.sg ([165.21.101.203])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yvsn-0009R0-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 13:15:05 -0800
Received: from jamessonyvaio (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp23.singnet.com.sg (8.12.2/8.12.2) with SMTP id g17LF3iI004106;
	Fri, 8 Feb 2002 05:15:03 +0800
Message-ID: <015701c1b01c$9490e060$0f01000a@jamessonyvaio>
From: "James Seng/Personal" 
To: , "Marc Blanchet" 
Subject: [idn] protest email
Date: Fri, 8 Feb 2002 05:15:33 +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 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: 7bit

After discussion with the ADs, instead of letting all the mails go
through, we will stop all the protest mails.

We will then summaries all the mails we have on 11th Feb 2002 to the
list.
The sender will be informed of this action.

-James Seng




From owner-idn@ops.ietf.org  Thu Feb  7 16:34: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 QAA10579
	for ; Thu, 7 Feb 2002 16:34:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yw2d-0009ys-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:25:15 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yw2c-0009yj-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 13:25:14 -0800
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 NAA25267;
	Thu, 7 Feb 2002 13:25:08 -0800
Message-Id: <5.1.0.14.2.20020207132412.0268db40@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Feb 2002 13:24:46 -0800
To: "James Seng/Personal" 
From: Dave Crocker 
Subject: Re: [idn] protest email
Cc: , "Marc Blanchet" 
In-Reply-To: <015701c1b01c$9490e060$0f01000a@jamessonyvaio>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 05:15 AM 2/8/2002 +0800, James Seng/Personal wrote:
>After discussion with the ADs, instead of letting all the mails go
>through, we will stop all the protest mails.
>
>We will then summaries all the mails we have on 11th Feb 2002 to the list.
>The sender will be informed of this action. thank you for doing this.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Feb  7 16:34: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 QAA10591
	for ; Thu, 7 Feb 2002 16:34:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yw5k-000A8p-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:28:28 -0800
Date: Thu, 7 Feb 2002 15:53:45 -0500
To: idn@ops.ietf.org
From: Elliotte Rusty Harold 
Subject: [idn] Re: Unicode and Security
Cc: unicode@unicode.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

At 2:10 PM -0600 2/7/02, David Starner wrote:

>What else?

ASCII, ISO-Latin-1. Not great solutions to be sure, but if it stops
the engineers from accidentally giving away the company jewels then
IT will impose them.

>As we keep pointing out, almost every character in Unicode
>that normally has the same glyph as another is in Unicode with good
>reason. To change that to something that would fit your goals will cost
>billions right now just for the change, and then you end with a
>character set that can't round trip all the others in common use, and
>that is more painful to use for Greeks and Russian, and completely
>unusable for mathematicians. I seriously doubt the world would go to a
>massively inferior character set because of the security holes you're
>talking about.

For text files, probably not. But for the domain name system the
world very well might. Indeed, maybe it should unless this problem
can be dealt with. I suspect it can be dealt with by prohibiting
script mixing in domain names (e.g. each component of the name must
be entirely Greek or entirely Cyrillic or entirely Latin etc. Note:
something_Cyrillic.something_greek.com is OK.)  Does anybody really
need mixed Latin and Greek domain names?

Still, this would just fix the problem for domain names. This is an
use-case I suspect wasn't even considered back in the mid-80s when
Unicode got rolling. I wouldn't be surprised if in another ten years
we find similar problems in some as yet unnoticed and unconsidered
area. Technology's nasty like that.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+





From owner-idn@ops.ietf.org  Thu Feb  7 16:35: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 QAA10612
	for ; Thu, 7 Feb 2002 16:35:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yw33-0009zk-00
	for idn-data@psg.com; Thu, 07 Feb 2002 13:25:41 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yw31-0009zT-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 13:25:40 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16Yw2s-000MyU-00; Thu, 07 Feb 2002 21:25:30 +0000
Date: Thu, 07 Feb 2002 16:25:13 -0500
From: John C Klensin 
To: Elliotte Rusty Harold 
cc: Unicode List , idn@ops.ietf.org,
        schneier@counterpane.com
Subject: Re: [idn] Re: Unicode and Security
Message-ID: <12761365.1013099113@localhost>
In-Reply-To: 
References:  
X-Mailer: Mulberry/2.2.0b1 (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

Hi.

This is _really_ old news, old enough that some companies have
mail gateways set up to trap and reject outgoing mail that uses
spoofed variations on the company's name.  And, as has been
pointed out on the IDN WG's list, versions of the problem occur
even in ASCII.  I.e., whether you can tell MICROSOFT from
MICR0S0FT depends on your choice of fonts.

There is, incidentally, a much nastier attack capability
resulting from the tendencies of some mail clients to
automatically add names and addresses to address books and then
suppress the addresses entirely from the user display.

There are some interesting issues here.  The solution to them,
along with the rest of the large catalog of ways to spoof email,
is signed and encrypted mail.  Please don't waste the time of
this Working Group with it.

    thanks,
      john


--On Thursday, 07 February, 2002 12:22 -0500 Elliotte Rusty
Harold  wrote:

> I've been thinking about security issues in Unicode, and I've
> come up with one that's quite scary and worse than any I've
> heard before. It uses only plaintext, no fonts involved,
> doesn't require buggy software, and works over e-mail instead
> of the Web. All it requires added to the existing
> infrastructure is internationalized domain names. So in the
> hope that this becomes a self-defeating prophecy, here's the
> scenario:
> 
> I as a reporter or industrial spy or detective working on a
> divorce case, have learned the identities and internal e-mail
> addresses of two people, call them Alice and Bob, at Microsoft
> (or just about any other large company). I've somehow
> communicated with these people personally, for instance on an
> e-mail list completely unrelated to work but for which they
> use their work e-mail so I'm familiar with their style and
> signature files. Or perhaps, I've communicated with them on
> work related matters before. In any case, it's not hard to get
> two people who know each other at a large company to send you
> e-mail. Of course, they would presumably be careful not to
> give me secret company information since they know they're
> talking to an outsider.
> 
> For the sake of argument, let's call the company they work at
> Microsoft, but this attack could hit most companies with a .com
> address. Let's say I register microsoft.com, only the fifth
> letter isn't a lower-case Latin o. It's actually a lower case
> Greek omicron. I then forge a believable letter from
> alice@microsoft.com to bob@microsoft.com saying "Can you
> please update me on your budget?" Bob, noticing that the
> e-mail appears to come from Alice, whom he knows and trusts,
> fires off a reply with his confidential information. Only it
> doesn't go to Alice. It goes to me. I can then reply to Bob,
> asking for clarification or more details. I can ask him to
> attach the latest build of his software. I can carry on a
> conversation in which Bob believes me to be Alice and spills
> his guts. This is very, very bad.
> 
> E-mail forgery has been a problem for a long time, but it's
> always been one-way. You couldn't trick somebody into sending
> you a reply because doing so required using a different e-mail
> address than the one they expected, thus revealing the message
> as forged. With a Unicode enabled mailer, that's no longer
> true. If the fonts Bob (not me, but Bob) chooses for his
> e-mail program do not make a clear distinction between an o
> and an omicron, this works. There are lots of other attacks.
> The Cyrillic and Greek alphabets provide lots of options for
> replacing single letters in Latin domain names.
> 
> I'm not sure whether or not the internationalized domain names
> working group has fully grokked this or not. Like Unicode,
> they seem to be trying to pass the buck. In particular, they
> state
>  ts-09.txt> :
> 
> Specifying requirements for internationalized domain names
> does not itself raise any new security issues. However, any
> change to the DNS MAY affect the security of any protocol that
> relies on the DNS or on DNS names. A thorough evaluation of
> those protocols for security concerns will be needed when they
> are developed. In particular, IDNs MUST be compatible with
> DNSSEC and, if multiple charsets or representation forms are
> permitted, the implications of this name-spoof MUST be
> throughly understood.
> 
> In other words, it's not our fault. Blame the client software.
> Sounds distressingly like the Unicode Consortium's approach to
> these issues. Interestingly, my attack works with a single
> character representation (Unicode). It is not dependent on
> multiple charsets. I don't know if the IDN working group has
> thought of this problem. I hope they have, and consider it
> their responsibility to prevent. I also hope the Unicode
> consortium and vendors of client software think about these
> problems. But I don't think we can count on client software
> getting this right. (Hell, Microsoft, can't even stop e-mail
> from running scripts.)  The problem needs to be fixed closer
> to the source. --
> 

> +-----------------------+------------------------+------------
> -------+
>| Elliotte Rusty Harold | elharo@metalab.unc.edu |
>| Writer/Programmer |
> +-----------------------+------------------------+------------
> -------+
>|          The XML Bible, 2nd Edition (Hungry Minds, 2001)
>|          | http://www.ibiblio.org/xml/books/bible2/
>|              |
>|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulai
>|   tA/   |
> +----------------------------------+--------------------------
> -------+
>|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/
>|  | Read Cafe con Leche for XML News:
>|  http://www.ibiblio.org/xml/     |
> +----------------------------------+--------------------------
> -------+
> 
> 
> 
> 
>  





From owner-idn@ops.ietf.org  Thu Feb  7 17:30: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 RAA11570
	for ; Thu, 7 Feb 2002 17:30:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YwxB-000CzL-00
	for idn-data@psg.com; Thu, 07 Feb 2002 14:23:41 -0800
Received: from smtp22.singnet.com.sg ([165.21.101.202])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YwxA-000CzF-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 14:23:40 -0800
Received: from jamessonyvaio (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g17MNcQr026214;
	Fri, 8 Feb 2002 06:23:38 +0800
Message-ID: <029f01c1b026$2920dd30$0f01000a@jamessonyvaio>
From: "James Seng/Personal" 
To: , 
References: 
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 06:24:08 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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

U+53F0 could either be SC or TC depending how it is been used.

In (U+53F0 U+6E7E) "taiwan", it is a simplified chinese.
In (U+53F0 U+7063) "taiwan", it is traditional chinese.
Another variant of traditional chinese of taiwan is (U+81FA U+7063).

For University, (U+5927 U+5B66) is a simplified chinese and (U+5927
U+5B78) is a traditonal chinese.

For "taiwan university" you get the following variants:

Simplified Chinese: (U+53F0 U+6E7E U+5927 U+5B66)
Traditional Chinese: (U+53F0 U+7063 U+5927 U+5B78)
    or (U+81FA U+7063 U+5926 U+5B78)

Therefore, in practice, you may like to have 3 names.

ps: For those who argue TC/SC can be done 1 to 1, this is an excellent
example why it cannot be done 1 to 1. Note I do TC/SC conversion in
pairs of Han ideographs, not one by one character.

-James Seng

> According the drafts,  my school should register 8 domain names
>     ACE(U+53F0,U+6E7E,U+5927,U+5B66)
>     ACE(U+53F0,U+6E7E,U+5927,U+5B78)
>     ACE(U+53F0,U+7063,U+5927,U+5B66)
>     ACE(U+53F0,U+7063,U+5927,U+5B78)
>     ACE(U+81FA,U+6E7E,U+5927,U+5B66)
>     ACE(U+81FA,U+6E7E,U+5927,U+5B78)
>     ACE(U+81FA,U+7063,U+5927,U+5B66)
>     ACE(U+81FA,U+7063,U+5927,U+5B78)
> to let user to access my school (NTU, "xWj" in Big5) without
> worrying
> if he or she keys in right character.
>
> and under each domain, we have to create 4 sub-domains for my
> institite(CSIE,
> "Tt" in BIG5),
>     ACE(U+8D44,U+8BAF,U+7CFB)
>     ACE(U+8D44,U+8A0A,U+7CFB)
>     ACE(U+8CC7,U+8BAF,U+7CFB)
>     ACE(U+8CC7,U+8A0A,U+7CFB)
>
> and under each of 8*4=32 sub-domains, create 4 records for a web
> server(web,
> ""
> in BIG5)
>     ACE(U+7DB2,U+9801)
>     ACE(U+7DB2,U+9875)
>     ACE(U+7F51,U+9801)
>     ACE(U+7F51,U+9875)
>
> And finally, i have to set all 8*4*4=128 domain names at the
> configuration
> files to
> prevent error messages such as "host not found", or "page not found"
> even if
> i have
> correctly set my DNS server.
>
> If it is true, please do not pass these drafts!! It's too terrible,
> there
> are many Web servers,
> mail servers, and other severs.....
>
> If I'm wrong, please correct me, and please forgive my poor English.
>
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
>




From owner-idn@ops.ietf.org  Thu Feb  7 17:32: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 RAA11611
	for ; Thu, 7 Feb 2002 17:32:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yx0W-000D9i-00
	for idn-data@psg.com; Thu, 07 Feb 2002 14:27:08 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yx0V-000D9c-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 14:27:07 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16Yx0R-0002Hh-00
	for ; Thu, 07 Feb 2002 14:27:03 -0800
Date: Thu, 7 Feb 2002 22:27:03 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Message-ID: <20020207222703.GF7074@nicemice.net>
Reply-To: IETF idn working group 
References: <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com>  <7FC3066C236FD511BC5900508BAC86FE919677@trestles.internal.realnames.com> <20020207030125.GC5125@nicemice.net> <3C61F87E.6B7CBD83@ehsco.com> <20020207043706.GA7193@nicemice.net> <001101c1afa0$8d2dc620$5a0aa8c0@labs.ntrg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001101c1afa0$8d2dc620$5a0aa8c0@labs.ntrg.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

I wrote:

> There are some code points that are prohibited in host names, but not
> in all textual domain names.

"Eric A. Hall"  replied:

> These include the octet values to which I was referring.  Just as a
> domain name can include underscore and period, it can also include the
> codepoint values for NUL, BS, CRLF, or any other value in the range of
> 0x00-0xFF.
>
> Unless you are planning to update STD13, all octet values need to be
> passed for non-hostname domain names.

Let's not confuse code points with octets.  Nameprep does not input or
output octets.  It inputs code points and outputs code points.

STD13 says that domain labels, in the broadest sense, are sequences
of octets, each of which can have any of the 256 possible values for
octets.  Domain labels in this broadest sense may or may not be text;
the octets can, in theory, be used to represent anything.

Depending on what the domain labels are being used for, some of those
256 possible octet values might not get used, even though STD13 allows
them.  For example, when domain labels are used as host labels, only 63
of the possible 256 values get used (the ones corresponding to the LDH
characters).

Similarly, when domain labels are used as IDNA internationalized text
labels, not all 256 octet values get used.  Only the values that can
be output by ToASCII get used.  Clearly, the values 80..FF can never
be output by ToASCII.  Furthermore, because of the prohibitions in
nameprep, the values 7F and 0..20 also cannot be output by ToASCII.

Even though ToASCII never outputs the values 80..FF which are allowed
by STD13, that obviously doesn't mean that ToASCII is broken.  Avoiding
80..FF is the entire point of ToASCII!  Similarly, even though ToASCII
never outputs the values 7F or 0..20 which are allowed by STD13, that
doesn't mean ToASCII (or nameprep) is broken.  IDNA simply doesn't need
those values in order to represent the things it's designed to represent
(internationalized text labels).

If you want to argue that nameprep shouldn't prohibit some of the
code points it's currently prohibiting, you'll need to come up with a
different argument.  Invoking STD13 doesn't help.

AMC



From owner-idn@ops.ietf.org  Thu Feb  7 17:49: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 RAA11939
	for ; Thu, 7 Feb 2002 17:49:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YxF1-000DpG-00
	for idn-data@psg.com; Thu, 07 Feb 2002 14:42:07 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YxF0-000DpA-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 14:42:06 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16YxF0-0002KO-00
	for ; Thu, 07 Feb 2002 14:42:06 -0800
Date: Thu, 7 Feb 2002 22:42:06 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] A question...
Message-ID: <20020207224205.GG7074@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.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

jw-lin@yahoo.com.tw wrote:

> According the drafts, my school should register 8 domain names to let
> user to access my school without worrying if he or she keys in right
> character.
>
> and under each domain, we have to create 4 sub-domains for my
> institite
>
> and under each of 8*4=32 sub-domains, create 4 records for a web
> server
>
> And finally, i have to set all 8*4*4=128 domain names at the
> configuration files...

I don't think any of the drafts recommend this.  In fact, I think there
are plans to add language to the IDNA draft warning registrars about the
pitfalls of registering any and all names without any policies.

For example, although there may be 8 different ways to represent
your school name, there are probably only two ways that are most
common/convenient (call them X and Y), and the other six ways are much
less common/convenient.  Suppose the registrar prohibited anyone from
registering those six ways?

Furthermore, while there may be 4 ways to represent your institute,
there is probably one of them that is most common/convenient when used
with X, and one of them that is most common/convenient when used with Y.
And so on, for the remaining labels.

If the registrars imposed sensible prohibitions, your 128 names could
be reduced down to 2.  The other 126 would be prohibited by the
registrars, so you wouldn't need to worry about getting spoofed.  Users
who accidentally type one of the non-existent 126 ways might get a
host-not-found error, but that should be fairly rare (because those 126
ways were deliberately chosen to be the less common/convenient ways),
and enhanced application software that knows some of the registrars'
policies could auto-generate suggestions for other names more likely to
be in the DNS.

AMC



From owner-idn@ops.ietf.org  Thu Feb  7 18:08: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 SAA12343
	for ; Thu, 7 Feb 2002 18:08:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YxZi-000Erm-00
	for idn-data@psg.com; Thu, 07 Feb 2002 15:03:30 -0800
Received: from lobo.nic.cc ([206.253.214.247] helo=mail.enic.cc)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YxZh-000Erg-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 15:03:30 -0800
Received: from algernon.lan.enic.cc (tailback [206.253.214.252])
	by mail.enic.cc (Postfix) with ESMTP id A062A6A908
	for ; Thu,  7 Feb 2002 15:03:29 -0800 (PST)
Subject: Re: [idn] A question...
From: Dan Ebert 
To: IETF idn working group 
In-Reply-To: <20020207224205.GG7074@nicemice.net>
References:  
	<20020207224205.GG7074@nicemice.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.2 
Date: 07 Feb 2002 15:03:34 -0800
Message-Id: <1013123014.4908.38.camel@algernon.lan.enic.cc>
Mime-Version: 1.0
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Thu, 2002-02-07 at 14:42, Adam M. Costello wrote:
> jw-lin@yahoo.com.tw wrote:
> 
> > According the drafts, my school should register 8 domain names to let
> > user to access my school without worrying if he or she keys in right
> > character.
> >
> > and under each domain, we have to create 4 sub-domains for my
> > institite
> >
> > and under each of 8*4=32 sub-domains, create 4 records for a web
> > server
> >
> > And finally, i have to set all 8*4*4=128 domain names at the
> > configuration files...
> 
> I don't think any of the drafts recommend this.  In fact, I think there
> are plans to add language to the IDNA draft warning registrars about the
> pitfalls of registering any and all names without any policies.
> 
> For example, although there may be 8 different ways to represent
> your school name, there are probably only two ways that are most
> common/convenient (call them X and Y), and the other six ways are much
> less common/convenient.  Suppose the registrar prohibited anyone from
> registering those six ways?
> 

It may not be realistic to expect registrars to do this.  (Would each
registrar have to check for the existence of a domain 'variation' every
time someone wants to register a name?)

If this prohibition is to occur would it be better achived at the
registry level?

Dan Ebert.

> Furthermore, while there may be 4 ways to represent your institute,
> there is probably one of them that is most common/convenient when used
> with X, and one of them that is most common/convenient when used with Y.
> And so on, for the remaining labels.
> 
> If the registrars imposed sensible prohibitions, your 128 names could
> be reduced down to 2.  The other 126 would be prohibited by the
> registrars, so you wouldn't need to worry about getting spoofed.  Users
> who accidentally type one of the non-existent 126 ways might get a
> host-not-found error, but that should be fairly rare (because those 126
> ways were deliberately chosen to be the less common/convenient ways),
> and enhanced application software that knows some of the registrars'
> policies could auto-generate suggestions for other names more likely to
> be in the DNS.
> 
> AMC
> 





From owner-idn@ops.ietf.org  Thu Feb  7 18:34: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 SAA12974
	for ; Thu, 7 Feb 2002 18:34:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YxxF-000Fz5-00
	for idn-data@psg.com; Thu, 07 Feb 2002 15:27:49 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YxxE-000FyE-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 15:27:48 -0800
Received: from chalmers95a69n (dynamic-193-207.dialup.chalmers.se [129.16.193.207])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g17NRih28324
	for ; Fri, 8 Feb 2002 00:27:44 +0100 (MET)
From: "Kent Karlsson" 
To: 
Subject: [idn] Comments on IDNA/stringprep/nameprep
Date: Fri, 8 Feb 2002 00:25:25 +0100
Message-ID: <000201c1b02e$b9b7cfe0$cfc11081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12974

	Comments on IDNA/stringprep/nameprep



1. stringprep and nameprep should be rejoined to a
hostnameprep. They are only about host name preparation,
not any other name preparation.  Similar preparations
may still take advantage of the hostnameprep document,
by declaring "deltas", small changes that may be needed
for other (Internet, DNS) names.  That would likely
minimise the size of the "reuse" documents.


2. hostnameprep should be applied to the *entire*
hostname; i.e. the entire name should be 'mapped'
in the same way *before* it is parsed into parts.


3. Various FULL STOPs should be mapped to FULL STOP,
which must be allowed. Some of this is accomplished via
NFKC, but some mappings need be added specially for
hostnameprep, e.g. IDEOGRAPHIC FULL STOP. (Note that
parsing into parts should come after the mapping and
prohibition steps.)


4. Various Pd (punctuation dash) should be mapped to
HYPHEN-MINUS by hostnameprep.  Future keyboards may
generate HYPHEN rather HYPHEN-MINUS (except perhaps
in "programming language mode", which few will use).
At least, hostnameprep should not prevent such a development.


5. Symbols/punctuation/dingbats (except the hyphen-like
dashes) should not be allowed by hostnameprep; and
all of that prohibition should be in hostnameprep,
not some of them handled differently elsewhere.
Punctuatuation in particular, in contexts where hostnames
are embedded, may in future syntaxes use non-ASCII
punctuation adjacent to the hostname. At the very least
such a development should not be prevented by hostnameprep.
Symbols are at present excluded, and should remain so also
for non-ASCII symbols, for the same reason as punctuation
should be excluded.


6. Hangul syllables (with conjoining characters, not
non-conjoining compatiblity characters) that represent
the same syllable must be mapped to the same representation.
Due to unfortunate historic reasons, this does no longer
happen automatically with NFKC (though for drafts for
NFKC it did).  Mappings should be added so that "syllabically"
equivalent Hangul conjoning characters are mapped to a common
representation.  Hangul compatibility letters should be
prohibited though.  Correctly mapping those is more complicated
than can be expressed in the (current form of) (host)nameprep
mappings. Hangul compatibility letters should instead be
prohibited. (Mapping table for Jamos, and prohibition table for
Hangul compatibility characters, are available upon request.)
Future keyboard, e.g., input may generate only single letter
Jamos, rather than any "cluster letter" Jamos or precomposed
Hangul syllable characters.  At the very least, hostnameprep
should not prevent such a development.


7. No document associated with hostnameprep should make any
further restrictions on domain/host names than hostnameprep
itself. (In addition, duplicating some of the restrictions
elsewhere is confusing and should not be done.)


8. Note: The SC/TC issue cannot be solved at a near-impossible-
to-change (once deployed) technical level, but should instead
be solved at a policy level (which may employ software with
relatively easy to change mappings).


9. User interfaces that encounter mixed script hostname *parts*
should be recommended to "flag" them (ballon warning, color
differentiate, make blinking, bounce automatic registratations, ...).


		/Kent Karlsson





From owner-idn@ops.ietf.org  Thu Feb  7 18:52: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 SAA13340
	for ; Thu, 7 Feb 2002 18:52:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16YyCI-000GgL-00
	for idn-data@psg.com; Thu, 07 Feb 2002 15:43:22 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16YyCG-000GgA-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 15:43:20 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g17NhER12474
	for ; Fri, 8 Feb 2002 08:43:14 +0900
Message-ID: <023601c1b031$2a80ba50$2b19fea9@temp>
From: "Soobok Lee" 
To: "IETF idn working group" 
References:  <20020207224205.GG7074@nicemice.net>
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 08:40:04 +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


----- Original Message -----
From: "Adam M. Costello" 
>
> If the registrars imposed sensible prohibitions, your 128 names could
> be reduced down to 2.  The other 126 would be prohibited by the
> registrars, so you wouldn't need to worry about getting spoofed.  Users
> who accidentally type one of the non-existent 126 ways might get a
> host-not-found error, but that should be fairly rare (because those 126
> ways were deliberately chosen to be the less common/convenient ways),
> and enhanced application software that knows some of the registrars'
> policies could auto-generate suggestions for other names more likely to
> be in the DNS.


Adam, you may have missed the point Tseng and et al raised.

In the case of LDH domains,  aPPLe.com would seldom be entered by end users.
But, in chinese letters, TC/SC distinctions are not as clear as
lower/uppercase distinctions of Latin  alphabets. Not all chinese
people are font/letter variant experts.

Even for me, the subtle difference between U+6DF8 and U+6E05 would not be noticed
without careful inspection. The same for U+654E and U+6559. It will be
very difficult for ordinary chinese people to have as complete  knowledge as
IRG/Han experts  to whom the distinction may be very very very clear though.

I feel that in many aspects, TC/SC distintions are like the distinction
between 'A' in times roman font  and  'A' in script font, rather than
one between 'A' and 'a' in the same font set.

In short, TC/SC equivalence can be put somewhere between
simpified font variants relations and bicameral relations.

To repeat one more time, non CJK people should try to understand and learn  :
  TC/SC distinction may not be so clear as between 'A' and 'a'  in chinese culture
  and How often TC and SC letters are used interchangeably in everyday life of chinese.

Just having 2 registrations of one TC and one SC label  from 8 candiates may be not sufficient for
ordinary chinese end users. More attention, please!

(from Tseng's example in UTF8)

淸眞敎 U+6DF8 U+771E U+654E
淸眞教 U+6DF8 U+771E U+6559
淸真敎 U+6DF8 U+771F U+654E
淸真教 U+6DF8 U+771F U+6559
清眞敎 U+6E05 U+771E U+654E
清眞教 U+6E05 U+771E U+6559
清真敎 U+6E05 U+771F U+654E
清真教 U+6E05 U+771F U+6559

Soobok Lee






From owner-idn@ops.ietf.org  Thu Feb  7 20:27: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 UAA15054
	for ; Thu, 7 Feb 2002 20:27:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yzi4-000L9q-00
	for idn-data@psg.com; Thu, 07 Feb 2002 17:20:16 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yzi4-000L9j-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 17:20:16 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16Yzi3-0002or-00
	for ; Thu, 07 Feb 2002 17:20:15 -0800
Date: Fri, 8 Feb 2002 01:20:15 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] A question...
Message-ID: <20020208012015.GA10534@nicemice.net>
Reply-To: IETF idn working group 
References:  <20020207224205.GG7074@nicemice.net> <1013123014.4908.38.camel@algernon.lan.enic.cc>  <20020207224205.GG7074@nicemice.net> <023601c1b031$2a80ba50$2b19fea9@temp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1013123014.4908.38.camel@algernon.lan.enic.cc> <023601c1b031$2a80ba50$2b19fea9@temp>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Soobok Lee  wrote:

> Not all chinese people are font/letter variant experts.
>
> Even for me, the subtle difference between U+6DF8 and U+6E05 would not
> be noticed without careful inspection.

For the purposes of my proposal, it doesn't matter whether you can see
the difference.  When you sit down at a keyboard with a domain name
in your mind and type it in, how many distinct strings have a good
chance of being produced?  There may be 2^n possibilities, but the
vast majority would require deliberate extra effort to type, and have
virtually no chance of being produced accidentally.  I'm hypothesizing
that usually only a very few of the many possible strings actually have
a good chance of getting typed in by a naive user.

Dan Ebert  wrote:

> > For example, although there may be 8 different ways to represent
> > your school name, there are probably only two ways that are most
> > common/convenient (call them X and Y), and the other six ways are
> > much less common/convenient.  Suppose the registrar prohibited
> > anyone from registering those six ways?
>
> It may not be realistic to expect registrars to do this.  (Would each
> registrar have to check for the existence of a domain 'variation'
> every time someone wants to register a name?)

I am not proposing that the registrar allow an arbitrary pair of the
128 variants to be registered, whichever two are requested first.  I am
proposing that the registrar adopt an algorithmic policy for deciding
whether a given string is admissible (regardless of what else may or may
not be registered).  Once the algorithm has decided that the string is
admissible, the registrar would check whether it's already registered
(as usual).

If the requested string is inadmissible, the registrar would probably
offer some suggestions for "nearby" admissible unregistered strings,
just as registrars today offer suggestions when the requested string is
already registered.

> If this prohibition is to occur would it be better achived at the
> registry level?

Maybe.  In this discussion I have not been thinking about the
distinction between registrars and registries.

AMC



From owner-idn@ops.ietf.org  Thu Feb  7 20:29: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 UAA15068
	for ; Thu, 7 Feb 2002 20:29:00 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Yzfu-000L7Q-00
	for idn-data@psg.com; Thu, 07 Feb 2002 17:18:02 -0800
Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Yzfr-000L6h-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 17:18:00 -0800
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 g181Hrv20553;
	Fri, 8 Feb 2002 04:47:53 +0330
Received: from localhost (roozbeh@localhost)
	by bamdad.org (8.11.6/8.11.6) with ESMTP id g181OjP06492;
	Fri, 8 Feb 2002 04:54:45 +0330
X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs
Date: Fri, 8 Feb 2002 04:54:45 +0330 (IRT)
From: Roozbeh Pournader 
X-X-Sender: roozbeh@gilas.bamdad.org
To: bidi@unicode.org, IDN 
Subject: [idn] END OF AYAH vs NAMEPREP
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


I was wondering about our (Unicode bidi committee's) suggested change to
the character category of U+06DD ARABIC END OF AYAH to a formatting 
character ("Cf" instead of "Me"), and how that could affect nameprep. 
Section 5.2 of the latest nameprep document marks all formatting 
characters prohibited, and this character may become a formatting 
character very soon...

roozbeh

-- 
Note: If you want me to read a message, please make sure you include my
address in "To" or "CC" fields. I may not be able to follow all the
discussions on the mailing lists I subscribe. Sorry. (No, there's no problem
to receive duplicates.)
kl;klkl




From owner-idn@ops.ietf.org  Thu Feb  7 21:50: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 VAA17426
	for ; Thu, 7 Feb 2002 21:50:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z0rV-000OYD-00
	for idn-data@psg.com; Thu, 07 Feb 2002 18:34:05 -0800
Received: from rwcrmhc54.attbi.com ([216.148.227.87])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Z0rU-000OY7-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 18:34:04 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc54.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020208023403.RSAO1214.rwcrmhc54.attbi.com@c1340594a>;
          Fri, 8 Feb 2002 02:34:03 +0000
Message-ID: <007b01c1b049$644bb970$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "Kent Karlsson" , 
References: <000201c1b02e$b9b7cfe0$cfc11081@chalmers95a69n>
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Date: Thu, 7 Feb 2002 18:36:20 -0800
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

Ken, you are coming in very late in this process. A lot of this was
debated back and forth early in the process, both on mail and in
personal contact. I suggest for a start that you review all of the
archives so that you don't simply retread issues.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Kent Karlsson" 
To: 
Sent: Thursday, February 07, 2002 15:25
Subject: [idn] Comments on IDNA/stringprep/nameprep


Comments on IDNA/stringprep/nameprep



1. stringprep and nameprep should be rejoined to a
hostnameprep. They are only about host name preparation,
not any other name preparation.  Similar preparations
may still take advantage of the hostnameprep document,
by declaring "deltas", small changes that may be needed
for other (Internet, DNS) names.  That would likely
minimise the size of the "reuse" documents.


2. hostnameprep should be applied to the *entire*
hostname; i.e. the entire name should be 'mapped'
in the same way *before* it is parsed into parts.


3. Various FULL STOPs should be mapped to FULL STOP,
which must be allowed. Some of this is accomplished via
NFKC, but some mappings need be added specially for
hostnameprep, e.g. IDEOGRAPHIC FULL STOP. (Note that
parsing into parts should come after the mapping and
prohibition steps.)


4. Various Pd (punctuation dash) should be mapped to
HYPHEN-MINUS by hostnameprep.  Future keyboards may
generate HYPHEN rather HYPHEN-MINUS (except perhaps
in "programming language mode", which few will use).
At least, hostnameprep should not prevent such a development.


5. Symbols/punctuation/dingbats (except the hyphen-like
dashes) should not be allowed by hostnameprep; and
all of that prohibition should be in hostnameprep,
not some of them handled differently elsewhere.
Punctuatuation in particular, in contexts where hostnames
are embedded, may in future syntaxes use non-ASCII
punctuation adjacent to the hostname. At the very least
such a development should not be prevented by hostnameprep.
Symbols are at present excluded, and should remain so also
for non-ASCII symbols, for the same reason as punctuation
should be excluded.


6. Hangul syllables (with conjoining characters, not
non-conjoining compatiblity characters) that represent
the same syllable must be mapped to the same representation.
Due to unfortunate historic reasons, this does no longer
happen automatically with NFKC (though for drafts for
NFKC it did).  Mappings should be added so that "syllabically"
equivalent Hangul conjoning characters are mapped to a common
representation.  Hangul compatibility letters should be
prohibited though.  Correctly mapping those is more complicated
than can be expressed in the (current form of) (host)nameprep
mappings. Hangul compatibility letters should instead be
prohibited. (Mapping table for Jamos, and prohibition table for
Hangul compatibility characters, are available upon request.)
Future keyboard, e.g., input may generate only single letter
Jamos, rather than any "cluster letter" Jamos or precomposed
Hangul syllable characters.  At the very least, hostnameprep
should not prevent such a development.


7. No document associated with hostnameprep should make any
further restrictions on domain/host names than hostnameprep
itself. (In addition, duplicating some of the restrictions
elsewhere is confusing and should not be done.)


8. Note: The SC/TC issue cannot be solved at a near-impossible-
to-change (once deployed) technical level, but should instead
be solved at a policy level (which may employ software with
relatively easy to change mappings).


9. User interfaces that encounter mixed script hostname *parts*
should be recommended to "flag" them (ballon warning, color
differentiate, make blinking, bounce automatic registratations, ...).


/Kent Karlsson








From owner-idn@ops.ietf.org  Thu Feb  7 22:11: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 WAA17739
	for ; Thu, 7 Feb 2002 22:11:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z1Mh-000Pzs-00
	for idn-data@psg.com; Thu, 07 Feb 2002 19:06:19 -0800
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Message-ID: <20020208020008.GB10534@nicemice.net>
References: <000201c1b02e$b9b7cfe0$cfc11081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000201c1b02e$b9b7cfe0$cfc11081@chalmers95a69n>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Date: Thu, 07 Feb 2002 19:06:19 -0800

Kent Karlsson  wrote:

> 1. stringprep and nameprep should be rejoined to a hostnameprep. They
> are only about host name preparation, not any other name preparation.

I think they are about domain name preparation.  Some domain names are
textual but not host names, and don't obey the host name syntax rules.
For example, _ldap._tcp.foo.net (see RFC 2782 about SRV records).  I see
no reason why IDNA should restrict its attention to host names when it
can work perfectly well for all textual domain names.

That said, there could still be arguments for recombining the stringprep
and nameprep documents.  But you haven't yet presented any.

> 2. hostnameprep should be applied to the *entire* hostname; i.e. the
> entire name should be 'mapped' in the same way *before* it is parsed
> into parts.

Can you present any arguments favoring that approach?  I can think of a
few problems with it:

Sometimes programs count the number of dots in a name.  Nameprep can
change the number of dots (see the "Co." character, for example).  This
would be asking for trouble.

After running nameprep on the whole string, then splitting into labels,
individual labels might be invalid Unicode strings.  For example, a
label might start with a combining character.  So you'd have to do
another round of checking on the individual labels anyway.

In general, software often operates on labels individually, splitting
names, joining names, comparing labels, etc.  If IDNA were to do
anything to create interdependencies and interactions between labels, it
would be asking for trouble.

> 3. Various FULL STOPs should be mapped to FULL STOP

This is motivated by the previous suggestion, so we can put it aside for
now.

> 4. Various Pd (punctuation dash) should be mapped to HYPHEN-MINUS by
> hostnameprep.

Presumably this is to avoid visual ambiguity.  But there are many many
visual ambiguities created by the addition of the Unicode repertoire
(for example, several characters that look exactly like B).  Does this
one really warrant special treatment?  Why?

> 5. Symbols/punctuation/dingbats (except the hyphen-like dashes) should
> not be allowed [in host names]...  Punctuatuation in particular, in
> contexts where hostnames are embedded, may in future syntaxes use
> non-ASCII punctuation adjacent to the hostname.

That's a reasonable argument.  I argued something similar myself long
ago, but I didn't persuade the group.  Maybe it's too late now.

> 6. Hangul syllables (with conjoining characters, not non-conjoining
> compatiblity characters) that represent the same syllable must be
> mapped to the same representation.  Due to unfortunate historic
> reasons, this does no longer happen automatically with NFKC (though
> for drafts for NFKC it did).  Mappings should be added so that
> "syllabically" equivalent Hangul conjoning characters are mapped to a
> common representation.

I know nothing about this issue, but it sounds like you want the IETF to
redo Unicode work.  The Unicode folks know more about characters than we
do; I'm skeptical that we could do a better job on that sort of thing.

> 7. No document associated with hostnameprep should make any further
> restrictions on domain/host names than hostnameprep itself.

That's simply impossible.  Nameprep has no way of knowing whether the
name is too long.  You can't know that until after Punycode has been
applied.  Also, nameprep is not designed to apply special rules at the
beginning/end of the string, like prohibiting leading/trailing hyphens,
or prohibiting the IDNA prefix.  Those checks are better left where they
are now, in ToASCII.

> 8. Note: The SC/TC issue cannot be solved at a near-impossible-
> to-change (once deployed) technical level, but should instead be
> solved at a policy level

I tend to agree.

> 9. User interfaces that encounter mixed script hostname *parts* should
> be recommended to "flag" them (ballon warning, color differentiate,
> make blinking, bounce automatic registratations, ...).

Generally a good idea, although some scripts might be mixed often.
Maybe just talk about "labels containing combinations of characters
likely to be misleading", and give a couple of examples, and leave it to
the software developers to figure out what in general is misleading and
what isn't.

AMC





From owner-idn@ops.ietf.org  Thu Feb  7 22:15: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 WAA17795
	for ; Thu, 7 Feb 2002 22:15:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z1Lu-000PxA-00
	for idn-data@psg.com; Thu, 07 Feb 2002 19:05:30 -0800
Date: Thu, 07 Feb 2002 16:28:30 -0800
To: unicode@unicode.org
From: Asmus Freytag 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org
In-Reply-To: 
References: <20020207175333.GA1632@x8b4e53d6.dhcp.okstate.edu>
 
 
 <20020207175333.GA1632@x8b4e53d6.dhcp.okstate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

At 01:21 PM 2/7/02 -0500, Elliotte Rusty Harold wrote:

>I'm not sure Unicode can be fixed at this point. The flaws may be too
>deeply embedded. The real solution may involve waiting until companies
and
>people start losing significant amounts of money as a result of the
flaws
>in Unicode, and then throwing it away and replacing it with something
else.

This sounds nice and dramatic, but misses the point that the kinds of
issues you highlighted are absolutely common to *all* character sets
containing Latin and Greek, or Latin and Cyrillic characters, suggesting
that you are simply grandstanding here, instead of trying to find real
solutions to your problem.

Earlier, you accused Unicode of being in denial about security issues:
It
is you who is in denial about some underlying realities, among which is
that there are security issues that cannot be "fixed" by designing a
'better' character set. You remind me of the people who keep on
designing
perpetual motion devices, even after the laws of thermodynamics proved
the
futility of such efforts.

If you are interested in advancing security you would stop from barking
up
this blind alley and focus your energy on attacking the problems with
other
means. Plenty of suggestions have been made in this space over the last
few
days. Some of all of these should be explored.  But if we learned
anything
useful in this exchange, it is that no security scheme should be
designed
so that it is dependent on the character encoding as primary defense
against spoofing. Doing so would burden the character encoding with a
task
it will never be capable of fulfilling, since it would mean seriously
compromising support for the tasks for which it was created in the first
place.

A./







From owner-idn@ops.ietf.org  Thu Feb  7 23:19: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 XAA19369
	for ; Thu, 7 Feb 2002 23:19:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z2P7-000353-00
	for idn-data@psg.com; Thu, 07 Feb 2002 20:12:53 -0800
From: 
To: "James Seng/Personal" , 
References: 
            <029f01c1b026$2920dd30$0f01000a@jamessonyvaio>
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 12:06:53 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Content-Transfer-Encoding: 8bit


----- Original Message -----
From: "James Seng/Personal" 
To: ; 
Sent: Friday, February 08, 2002 6:24 AM
Subject: Re: [idn] A question...


> U+53F0 could either be SC or TC depending how it is been used.
>
> In (U+53F0 U+6E7E) "taiwan", it is a simplified chinese.
> In (U+53F0 U+7063) "taiwan", it is traditional chinese.
> Another variant of traditional chinese of taiwan is (U+81FA U+7063).
>
> For University, (U+5927 U+5B66) is a simplified chinese and (U+5927
> U+5B78) is a traditonal chinese.
>
> For "taiwan university" you get the following variants:
>
> Simplified Chinese: (U+53F0 U+6E7E U+5927 U+5B66)
> Traditional Chinese: (U+53F0 U+7063 U+5927 U+5B78)
>     or (U+81FA U+7063 U+5926 U+5B78)
>
> Therefore, in practice, you may like to have 3 names.

It is not ture. I think, maybe you are not familiar how Chinese
characters
are used in our daily work. But the other 5 cases are often written
(not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
preferrd because they are less-strokes.
What you said are in a restricit environment, like Windows 98, on which
you can not input those characters on some limited IME. However,
Windows 2000 will change the user behavior.

>
> ps: For those who argue TC/SC can be done 1 to 1, this is an excellent
> example why it cannot be done 1 to 1. Note I do TC/SC conversion in
> pairs of Han ideographs, not one by one character.
>
> -James Seng
>
> > According the drafts,  my school should register 8 domain names
> >     ACE(U+53F0,U+6E7E,U+5927,U+5B66)
> >     ACE(U+53F0,U+6E7E,U+5927,U+5B78)
> >     ACE(U+53F0,U+7063,U+5927,U+5B66)
> >     ACE(U+53F0,U+7063,U+5927,U+5B78)
> >     ACE(U+81FA,U+6E7E,U+5927,U+5B66)
> >     ACE(U+81FA,U+6E7E,U+5927,U+5B78)
> >     ACE(U+81FA,U+7063,U+5927,U+5B66)
> >     ACE(U+81FA,U+7063,U+5927,U+5B78)
> > to let user to access my school (NTU, "xWj" in Big5) without
> > worrying
> > if he or she keys in right character.
> >
> > and under each domain, we have to create 4 sub-domains for my
> > institite(CSIE,
> > "Tt" in BIG5),
> >     ACE(U+8D44,U+8BAF,U+7CFB)
> >     ACE(U+8D44,U+8A0A,U+7CFB)
> >     ACE(U+8CC7,U+8BAF,U+7CFB)
> >     ACE(U+8CC7,U+8A0A,U+7CFB)
> >
> > and under each of 8*4=32 sub-domains, create 4 records for a web
> > server(web,
> > ""
> > in BIG5)
> >     ACE(U+7DB2,U+9801)
> >     ACE(U+7DB2,U+9875)
> >     ACE(U+7F51,U+9801)
> >     ACE(U+7F51,U+9875)
> >
> > And finally, i have to set all 8*4*4=128 domain names at the
> > configuration
> > files to
> > prevent error messages such as "host not found", or "page not found"
> > even if
> > i have
> > correctly set my DNS server.
> >
> > If it is true, please do not pass these drafts!! It's too terrible,
> > there
> > are many Web servers,
> > mail servers, and other severs.....
> >
> > If I'm wrong, please correct me, and please forgive my poor English.
> >
> >
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> >
> >


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Thu Feb  7 23:30: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 XAA19576
	for ; Thu, 7 Feb 2002 23:30:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z2ZN-0003Xo-00
	for idn-data@psg.com; Thu, 07 Feb 2002 20:23:29 -0800
Received: from smtp22.singnet.com.sg ([165.21.101.202])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Z2ZM-0003Xh-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 20:23:28 -0800
Received: from jamessonyvaio (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp22.singnet.com.sg (8.12.2/8.12.2) with SMTP id g184NQQr028556;
	Fri, 8 Feb 2002 12:23:26 +0800
Message-ID: <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio>
From: "James Seng/Personal" 
To: , 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603>
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 12:23:55 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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

> It is not ture. I think, maybe you are not familiar how Chinese
characters
> are used in our daily work.

Perhaps you are not be aware I am possibly a Chinese myself too and I
use Chinese in my daily live, both traditional (in Malaysia) and
simplified (Singapore).  And I work with many Chinese linguists in the
last 2 years and the many of them are not Chinese.

> But the other 5 cases are often written
> (not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
> preferrd because they are less-strokes.

Thanks. Then we have no problem.

> What you said are in a restricit environment, like Windows 98, on
which
> you can not input those characters on some limited IME. However,
> Windows 2000 will change the user behavior.

By default, TC or SC will be output depending which IME you use. Of
course, you *could* manually scroll down the list to get the characters
or you could toggle the input method to do so.

The user behavior education about domain names should be that domain
names are identifier, not names. They should enter into the computer
exactly as they seen it or reference it.

Anyhow, you are raising issues which have been debated in the list
before, one which the wg is quite well aware of. So unless you have a
TC/SC solution which you willing to contributed to the group, I consider
this discussion closed.

And if you do have a TC/SC solution, one which have not be considered by
the group and UTC and IRG, I would definately love to hear your idea.

-James Seng

> > ps: For those who argue TC/SC can be done 1 to 1, this is an
excellent
> > example why it cannot be done 1 to 1. Note I do TC/SC conversion in
> > pairs of Han ideographs, not one by one character.
> >
> > -James Seng
> >
> > > According the drafts,  my school should register 8 domain names
> > >     ACE(U+53F0,U+6E7E,U+5927,U+5B66)
> > >     ACE(U+53F0,U+6E7E,U+5927,U+5B78)
> > >     ACE(U+53F0,U+7063,U+5927,U+5B66)
> > >     ACE(U+53F0,U+7063,U+5927,U+5B78)
> > >     ACE(U+81FA,U+6E7E,U+5927,U+5B66)
> > >     ACE(U+81FA,U+6E7E,U+5927,U+5B78)
> > >     ACE(U+81FA,U+7063,U+5927,U+5B66)
> > >     ACE(U+81FA,U+7063,U+5927,U+5B78)
> > > to let user to access my school (NTU, "xWj" in Big5) without
> > > worrying
> > > if he or she keys in right character.
> > >
> > > and under each domain, we have to create 4 sub-domains for my
> > > institite(CSIE,
> > > "Tt" in BIG5),
> > >     ACE(U+8D44,U+8BAF,U+7CFB)
> > >     ACE(U+8D44,U+8A0A,U+7CFB)
> > >     ACE(U+8CC7,U+8BAF,U+7CFB)
> > >     ACE(U+8CC7,U+8A0A,U+7CFB)
> > >
> > > and under each of 8*4=32 sub-domains, create 4 records for a web
> > > server(web,
> > > ""
> > > in BIG5)
> > >     ACE(U+7DB2,U+9801)
> > >     ACE(U+7DB2,U+9875)
> > >     ACE(U+7F51,U+9801)
> > >     ACE(U+7F51,U+9875)
> > >
> > > And finally, i have to set all 8*4*4=128 domain names at the
> > > configuration
> > > files to
> > > prevent error messages such as "host not found", or "page not
found"
> > > even if
> > > i have
> > > correctly set my DNS server.
> > >
> > > If it is true, please do not pass these drafts!! It's too
terrible,
> > > there
> > > are many Web servers,
> > > mail servers, and other severs.....
> > >
> > > If I'm wrong, please correct me, and please forgive my poor
English.
> > >
> > >
> > >
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > >
> > >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>




From owner-idn@ops.ietf.org  Fri Feb  8 01:05: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 BAA21088
	for ; Fri, 8 Feb 2002 01:05:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z41G-0007oE-00
	for idn-data@psg.com; Thu, 07 Feb 2002 21:56:22 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16Z41F-0007o7-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 21:56:21 -0800
Received: (qmail 7573 invoked by uid 1001); 8 Feb 2002 05:48:27 -0000
Date: 8 Feb 2002 05:48:27 -0000
Message-ID: <20020208054827.27337.qmail@cr.yp.to>
Mail-Followup-To: schneier@counterpane.com,
  unicode@unicode.org,
  idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: unicode@unicode.org, idn@ops.ietf.org
Cc: schneier@counterpane.com
Subject: Re: [idn] Re: Unicode and Security
References:  <12761365.1013099113@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This discussion is being sent to two mailing lists, the IDN list and the
Unicode list. Some Unicode people don't know about IDNs, so I'll give a
brief introduction. At the end I'll address Klensin's comments.

IDNs are ``internationalized domain names.'' Imagine, for example, a
Greek pi in http://pi.cr.yp.to.

IETF created the IDN working group and the IDN mailing list---allegedly
open to the public, but the group chair sometimes censors objections---
to try to make IDNs work. The group chair has been pushing a specific
proposal, called IDNA; he has recently issued a Last Call for IDNA
despite objections to IDNA from many group participants.

There are three big issues surrounding IDNs:

   (1) How should characters be encoded?

       The obvious choice is UTF-8. Many existing programs already work
       with UTF-8 domain names. See http://pi.cr.yp.to for a discussion
       of what works and what has to be fixed.

       The IDNA proposal uses a new special-purpose 7-bit character
       encoding. The proponents claim that adding this new encoding to a
       huge number of programs will be less expensive than fixing the
       programs that have trouble with UTF-8.

   (2) Should two strings be treated separately as domain names if they
       are visually indistinguishable? For example, should someone be
       allowed to register aol.com, with o replaced by a Greek omicron?

       An answer of ``yes'' would introduce many new errors into common
       uses of domain names. Domain names are not hidden inside the
       computer; they are displayed for users, so that users can
       recognize known names. Visually indistinguishable domain names
       would make this function inherently unreliable.

       The IDNA proposal ignores this problem. The proponents observe
       that we're already faced with digit 0 and capital O, and digit 1
       and lowercase l; they then leap to the incredible conclusion that
       there's no harm in adding a bunch of new characters whose glyphs
       are similar or even identical.

       (On the other hand, IDNA prohibits all characters that look like
       hyphens, periods, etc.)

       The conservative approach, familiar in security contexts, is to
       have all new characters prohibited by default. The domain-name
       registries will then allow selected characters that have been
       carefully reviewed for problems.

   (3) Should two strings be treated identically as domain names if
       they are visually different but semantically similar? For
       example, should uppercase Pi.cr.yp.to, with a Greek Pi, be
       treated the same way as lowercase pi.cr.yp.to?

       The only existing semantic-similarity rule is that uppercase
       ASCII is treated the same way as lowercase ASCII. We're forced to
       continue treating uppercase ASCII the same way as lowercase ASCII
       for interoperability. But should there be more rules?

       There are several reasons to say no. First, new rules would have
       to be added to a huge number of programs that handle domain
       names. Second, new rules would make issue #2 substantially more
       difficult to solve: for example, if Greek lowercase alpha is
       treated the same way as uppercase Alpha, then alpha ol.com will
       conflict with aol.com, because Alpha OL.COM is visually identical
       to AOL.COM. Third, semantic similarity depends on the reader: for
       example, lowercase delta and uppercase Delta are semantically
       similar in Greece, but not in the United States. Fourth, semantic
       similarity is not transitive: for example, I see signs in France
       using capital E as a capitalization of e-accent-egu, and signs
       using capital E as a capitalization of e without an accent, but
       omitting the accent from e-accent-egu would be a misspelling.

       The IDNA proposal imposes a global set of uppercase-lowercase
       conversions. The proponents claim that, if we don't allow
       uppercase, we'll be flooded with complaints from users who tried
       typing domain names in uppercase. They don't respond when it is
       pointed out that users already handle case-sensitive lowercase
       URLs without trouble: blah.html works and BLAH.HTML doesn't.

       (It's funny how the IDNA proponents express such concern about
       the accuracy of users _typing_ domain names, but completely
       ignore the accuracy of users _reading_ domain names. See issue
       #2. Has it occurred to them that the domain names typed are, in
       almost all cases, copies of domain names previously read?)

       Meanwhile, the IDNA proposal ignores other questions of semantic
       similarity. There have already been a huge number of complaints
       about this from Chinese users. The IDNA proponents say that the
       complaints ``don't count.''

       The conservative---and cost-effective---approach is to start
       without any new rules, and have the registries prohibit
       characters that may be affected by new rules. Then new rules can
       be safely added later _if_ that turns out to be a good idea. For
       example, uppercase non-ASCII letters won't be treated the same
       way as lowercase, but they also won't be allowed in
       registrations,

Now, back to the current thread. The ``Unicode and Security'' message
explained one way that visually indistinguishable characters can be
exploited by attackers. This isn't a flaw in Unicode; it is a flaw in
careless protocol designs such as IDNA.

John C Klensin writes:
> This is _really_ old news, old enough that some companies have
> mail gateways set up to trap and reject outgoing mail that uses
> spoofed variations on the company's name.

Here Klensin is admitting that IDNA will let attackers breach security.
These gateways are---unless modified in the last few months by an IDNA
proponent to use visual-similarity tables that the IDNA proponents say
don't exist---unaware of IDNA, and therefore unable to stop the attack
described in the ``Unicode and Security'' message.

> The solution to them, along with the rest of the large catalog of ways
> to spoof email, is signed and encrypted mail.

Speaking as a cryptographer: I find this ``cryptography solves all
security problems'' attitude to be astonishingly naive.

The problem here is not message forgery. The computer has accurately
identified the name of the sender. A cryptographic guarantee of
authenticity would do nothing to stop the attack.

The problem is in the design of the name system itself: how names are
assigned and used. The attacker was, as a matter of policy, allowed to
use a name visually indistinguishable from the target name. The name was
displayed on a computer screen. The display was read by the victim, and
used to authorize access.

One long-term solution is to drop all reliance on global name displays
in favor of local name displays (address books) defined entirely by the
user. In the short term, however, recipients will continue to use global
name displays to recognize known senders.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Fri Feb  8 01:06: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 BAA21108
	for ; Fri, 8 Feb 2002 01:06:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z45R-00082B-00
	for idn-data@psg.com; Thu, 07 Feb 2002 22:00:41 -0800
Received: from imo-d02.mx.aol.com ([205.188.157.34])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Z45Q-000825-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 22:00:40 -0800
Received: from DougEwell2@cs.com
	by imo-d02.mx.aol.com (mail_out_v32.5.) id i.136.8a4dd13 (25510);
	Fri, 8 Feb 2002 01:00:33 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <136.8a4dd13.2994c381@cs.com>
Date: Fri, 8 Feb 2002 01:00:33 EST
Subject: Re: [idn] A question...
To: idn@ops.ietf.org
CC: jseng@pobox.org.sg, jw-lin@yahoo.com.tw
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-07 20:32:44 Pacific Standard Time, 
jseng@pobox.org.sg writes:

> The user behavior education about domain names should be that domain
> names are identifier, not names. They should enter into the computer
> exactly as they seen it or reference it.

Gee, what a concept.  Just what we've been saying all along.

You know what happens today when someone tries to type in a misspelled domain 
name or e-mail address, or a case-sensitive URL using the wrong case?  It 
fails.  The user gets a 404, or his mail bounces or something.  Then he says, 
"Aw, shucks" (or something stronger) and types the identifier again, this 
time EXACTLY as he was told to, and the web page appears or the mail gets 
sent.  And the user eventually learns when it is important to be 
case-sensitive and when it is not so important.

The same, exact thing will happen with Han logographs.  If # and & are TC and 
SC characters (respectively) that have the same meaning, and the user types # 
when he should have typed & (or vice versa), under the proposed IDN system 
the name will not match.  The user will get a 404, mutter "aw, shucks," and 
type it again, VERBATIM, and the page will appear.  And the user will learn 
that it is important to type the EXACT characters that appear on the business 
card, or billboard, or wherever the name came from.

Yes, I know TC and SC pairs are pronounced the same, so *speaking* a CJK 
domain name would not guarantee that the listener would be able to type it 
with the correct combination of TC and/or SC characters.  Guess what?  This 
too is already true with ASCII.

Did you know there is a very large number called a "googol"?  I believe it's 
10 to the 600th power, or something like that.  I first heard about that 
number decades ago.  Now we are in the Web age, and there is an important and 
powerful search engine called "Google."  (Note the different spelling.)  If I 
had never heard of Google the search engine, and somebody told me to type it 
in, I probably would start with my prior knowledge of this identically 
pronounced word, and type "www.googol.com."  Of course, it would fail (or 
maybe it would take me to a totally different site).  I would then inquire, 
and the person would apologize (maybe) and tell me the ONE TRUE correct 
spelling.

Did you notice what happened?  More to the point, did you notice what 
*didn't* happen?  Nobody died.  No vast fortunes were made or lost.  Nobody 
lost any business because, for a brief moment, there was some confusion about 
how to spell a domain name.  The problem was solved easily and quickly.

Now, I would like someone to explain to me why this won't work for CJK.  Use 
reason and logic, not emotion.  Use realistic (not hyper-inflated) 
probabilities.  Do not patronize me by simply stating, "Well, CJK is 
different" unless you can explain what is different in THIS case.  And do not 
send me 50 identically worded responses.

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Fri Feb  8 01:46: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 BAA21571
	for ; Fri, 8 Feb 2002 01:46:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z4et-0009o1-00
	for idn-data@psg.com; Thu, 07 Feb 2002 22:37:19 -0800
Received: from imo-d01.mx.aol.com ([205.188.157.33])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Z4es-0009nv-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 22:37:18 -0800
Received: from DougEwell2@cs.com
	by imo-d01.mx.aol.com (mail_out_v32.5.) id i.10d.d164347 (3703);
	Fri, 8 Feb 2002 01:37:10 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <10d.d164347.2994cc16@cs.com>
Date: Fri, 8 Feb 2002 01:37:10 EST
Subject: Re: [idn] RE: Unicode and Security
To: idn@ops.ietf.org, unicode@unicode.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

jarkko.hietaniemi@nokia.com observed:

> Analogously, people will keep opening executable attachments promising sex,
> regardless of whether the 's', 'e', and 'x' are Latin letters or not.

They're not, of course:  U+0455 U+0435 U+0445

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Fri Feb  8 01:55: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 BAA21645
	for ; Fri, 8 Feb 2002 01:55:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Z4q6-000AMe-00
	for idn-data@psg.com; Thu, 07 Feb 2002 22:48:54 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Z4q5-000AM9-00
	for idn@ops.ietf.org; Thu, 07 Feb 2002 22:48:54 -0800
Received: (qmail 19839 invoked by uid 1001); 8 Feb 2002 06:41:39 -0000
Date: 8 Feb 2002 06:41:39 -0000
Message-ID: <20020208064139.14657.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] A question...
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

James Seng/Personal writes:
> The user behavior education about domain names should be that domain
> names are identifier, not names. They should enter into the computer
> exactly as they seen it or reference it.

So why are you demanding that implementors convert uppercase non-ASCII
to lowercase?

---Dan



From owner-idn@ops.ietf.org  Fri Feb  8 08:20: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 IAA05575
	for ; Fri, 8 Feb 2002 08:20:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZAi7-0002pG-00
	for idn-data@psg.com; Fri, 08 Feb 2002 05:05:03 -0800
Received: from mx-out.daemonmail.net ([209.75.5.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZAi5-0002p1-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 05:05:01 -0800
Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1])
	by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id FAA57466;
	Fri, 8 Feb 2002 05:04:58 -0800 (PST)
	(envelope-from rosenne@qsm.co.il)
Received: from qsm3 (qsm3 [212.150.108.15])
	by mail.qsm.co.il with ESMTP id cwE081L2
	Fri, 08 Feb 2002 05:04:52 -0700 (PST)
From: "Jonathan Rosenne" 
To: , 
Cc: , 
Subject: RE: [idn] A question...
Date: Fri, 8 Feb 2002 15:04:30 +0200
Message-ID: <000401c1b0a1$28031b40$eb0110ac@qsm3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <136.8a4dd13.2994c381@cs.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

VERBATIM means "word for word". LITERATIM is "letter by letter". This is
precisely the essence of the problem - you hear a domain name, and spell
it exactly as you hear it, and it should be found. 

Jony


> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] 
> On Behalf Of DougEwell2@cs.com
> Sent: Friday, February 08, 2002 8:01 AM
> To: idn@ops.ietf.org
> Cc: jseng@pobox.org.sg; jw-lin@yahoo.com.tw
> Subject: Re: [idn] A question...
> 
> 
> In a message dated 2002-02-07 20:32:44 Pacific Standard Time, 
> jseng@pobox.org.sg writes:
> 
> > The user behavior education about domain names should be 
> that domain 
> > names are identifier, not names. They should enter into the 
> computer 
> > exactly as they seen it or reference it.
> 
> Gee, what a concept.  Just what we've been saying all along.
> 
> You know what happens today when someone tries to type in a 
> misspelled domain 
> name or e-mail address, or a case-sensitive URL using the 
> wrong case?  It 
> fails.  The user gets a 404, or his mail bounces or 
> something.  Then he says, 
> "Aw, shucks" (or something stronger) and types the identifier 
> again, this 
> time EXACTLY as he was told to, and the web page appears or 
> the mail gets 
> sent.  And the user eventually learns when it is important to be 
> case-sensitive and when it is not so important.
> 
> The same, exact thing will happen with Han logographs.  If # 
> and & are TC and 
> SC characters (respectively) that have the same meaning, and 
> the user types # 
> when he should have typed & (or vice versa), under the 
> proposed IDN system 
> the name will not match.  The user will get a 404, mutter 
> "aw, shucks," and 
> type it again, VERBATIM, and the page will appear.  And the 
> user will learn 
> that it is important to type the EXACT characters that appear 
> on the business 
> card, or billboard, or wherever the name came from.
> 
> Yes, I know TC and SC pairs are pronounced the same, so 
> *speaking* a CJK 
> domain name would not guarantee that the listener would be 
> able to type it 
> with the correct combination of TC and/or SC characters.  
> Guess what?  This 
> too is already true with ASCII.
> 
> Did you know there is a very large number called a "googol"?  
> I believe it's 
> 10 to the 600th power, or something like that.  I first heard 
> about that 
> number decades ago.  Now we are in the Web age, and there is 
> an important and 
> powerful search engine called "Google."  (Note the different 
> spelling.)  If I 
> had never heard of Google the search engine, and somebody 
> told me to type it 
> in, I probably would start with my prior knowledge of this 
> identically 
> pronounced word, and type "www.googol.com."  Of course, it 
> would fail (or 
> maybe it would take me to a totally different site).  I would 
> then inquire, 
> and the person would apologize (maybe) and tell me the ONE 
> TRUE correct 
> spelling.
> 
> Did you notice what happened?  More to the point, did you notice what 
> *didn't* happen?  Nobody died.  No vast fortunes were made or 
> lost.  Nobody 
> lost any business because, for a brief moment, there was some 
> confusion about 
> how to spell a domain name.  The problem was solved easily 
> and quickly.
> 
> Now, I would like someone to explain to me why this won't 
> work for CJK.  Use 
> reason and logic, not emotion.  Use realistic (not hyper-inflated) 
> probabilities.  Do not patronize me by simply stating, "Well, CJK is 
> different" unless you can explain what is different in THIS 
> case.  And do not 
> send me 50 identically worded responses.
> 
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)
> 
> 
> 




From owner-idn@ops.ietf.org  Fri Feb  8 08:26: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 IAA05676
	for ; Fri, 8 Feb 2002 08:26:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZAri-0003JE-00
	for idn-data@psg.com; Fri, 08 Feb 2002 05:14:58 -0800
From: "jw-lin" 
To: 
References: 
Message-Id: 
Date: Fri, 08 Feb 2002 05:14:58 -0800

<20020207224205.GG7074@nicemice.net>
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 16:47:24 +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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Adam:

The world will go in another direction....i think...

Please see the story below. (I've mentioned this to James Seng  in my
reply)

By doing so, i can image that:
The phone in office of the computer center at my school will ring all of
the days, and never stop. The administrators should reply for the
complain
from students, and make reports to the managers who are complained
by professors. And one day, at the meeting for school affair, the
principal
will take care of these complains. He may ask how much does it
cost to register all possible names. And maybe my school is rich, and
doesn't care about money. The principal say "pay it, and register all."
Of course, he won't ask how complicated things are. Because it is the
work of the administrators:-(
And finally, the administrators must register all 128 names, and
configure
these 128 names on each server which will check the "domain name" of
the requests.

You are trying to change the feeling to Chinese characters for Chinese.
I don't think it works. The result is all administrators register all
possible
names if they have enough money, and configure their servers well.
If not, apologize and explain to their customers.

Maybe it is a way to keep all administrators of Chinese domain names
busy.

----- Original Message -----
From: "Adam M. Costello" 
To: 
Sent: Friday, February 08, 2002 6:42 AM
Subject: Re: [idn] A question...


> jw-lin@yahoo.com.tw wrote:
>
> > According the drafts, my school should register 8 domain names to
let
> > user to access my school without worrying if he or she keys in right
> > character.
> >
> > and under each domain, we have to create 4 sub-domains for my
> > institite
> >
> > and under each of 8*4=32 sub-domains, create 4 records for a web
> > server
> >
> > And finally, i have to set all 8*4*4=128 domain names at the
> > configuration files...
>
> I don't think any of the drafts recommend this.  In fact, I think
there
> are plans to add language to the IDNA draft warning registrars about
the
> pitfalls of registering any and all names without any policies.
>
> For example, although there may be 8 different ways to represent
> your school name, there are probably only two ways that are most
> common/convenient (call them X and Y), and the other six ways are much
> less common/convenient.  Suppose the registrar prohibited anyone from
> registering those six ways?
>
> Furthermore, while there may be 4 ways to represent your institute,
> there is probably one of them that is most common/convenient when used
> with X, and one of them that is most common/convenient when used with
Y.
> And so on, for the remaining labels.
>
> If the registrars imposed sensible prohibitions, your 128 names could
> be reduced down to 2.  The other 126 would be prohibited by the
> registrars, so you wouldn't need to worry about getting spoofed.
Users
> who accidentally type one of the non-existent 126 ways might get a
> host-not-found error, but that should be fairly rare (because those
126
> ways were deliberately chosen to be the less common/convenient ways),
> and enhanced application software that knows some of the registrars'
> policies could auto-generate suggestions for other names more likely
to
> be in the DNS.
>
> AMC
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Fri Feb  8 08:26: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 IAA05692
	for ; Fri, 8 Feb 2002 08:26:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZAsj-0003P0-00
	for idn-data@psg.com; Fri, 08 Feb 2002 05:16:01 -0800
Date: Fri, 8 Feb 2002 11:30:35 +0000
To: unicode@unicode.org
From: Michael Everson 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

At 15:53 -0500 2002-02-07, Elliotte Rusty Harold wrote:
>For text files, probably not. But for the domain name system the 
>world very well might. Indeed, maybe it should unless this problem 
>can be dealt with. I suspect it can be dealt with by prohibiting 
>script mixing in domain names (e.g. each component of the name must 
>be entirely Greek or entirely Cyrillic or entirely Latin etc. Note: 
>something_Cyrillic.something_greek.com is OK.)  Does anybody really 
>need mixed Latin and Greek domain names?

Certainly. Some years ago the European Court upheld the right of a 
Belgian man whose father was Belgian and mother was Greek to spell 
his hyphenated last name in both scripts. Why should he not be 
allowed to register a domain based on his own name?

I don't think this has anything to do with Unicode. In Unicode, we 
wish to make all the world's writing system available to everyone. 
Thieves and cheats will use it if they wish, but this detracts not 
one whit from the nobility of our enterprise.
-- 
Michael Everson *** Everson Typography *** http://www.evertype.com





From owner-idn@ops.ietf.org  Fri Feb  8 08: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 IAA05711
	for ; Fri, 8 Feb 2002 08:27:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZArm-0003K2-00
	for idn-data@psg.com; Fri, 08 Feb 2002 05:15:02 -0800
Reply-To: 
From: 
To: "James Seng/Personal" , 
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 14:17:19 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Content-Transfer-Encoding: 8bit

The people are educated to use case-ignored ASCII domain names.
Then, they are requested to use case-sensitive Chinese domain names.

I don't think it is really a good solution.
By doing so, i can image that:
The phone in office of the computer center at my school will ring all of
the days, and never stop. The administrators should reply for the
complain
from students, and make reports to the managers who are complained
by professors. And one day, at the meeting for school affair, the
principal
will take care of these complains. He may ask how much does it
cost to register all possible names. And maybe my school is rich, and
doesn't care about money. The principal say "pay it, and register all."
Of course, he won't ask how complicated things are. Because it is the
work of the administrators:-(
And finally, the administrators must register all 128 names, and
configure
these 128 names on each server which will check the "domain name" of
the requests.

----- Original Message -----
From: "James Seng/Personal" 
To: ; 
Sent: Friday, February 08, 2002 12:23 PM
Subject: Re: [idn] A question...


> > It is not ture. I think, maybe you are not familiar how Chinese
> characters
> > are used in our daily work.
>
> Perhaps you are not be aware I am possibly a Chinese myself too and I
> use Chinese in my daily live, both traditional (in Malaysia) and
> simplified (Singapore).  And I work with many Chinese linguists in the
> last 2 years and the many of them are not Chinese.
>
> > But the other 5 cases are often written
> > (not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
> > preferrd because they are less-strokes.
>
> Thanks. Then we have no problem.
>
> > What you said are in a restricit environment, like Windows 98, on
> which
> > you can not input those characters on some limited IME. However,
> > Windows 2000 will change the user behavior.
>
> By default, TC or SC will be output depending which IME you use. Of
> course, you *could* manually scroll down the list to get the
characters
> or you could toggle the input method to do so.
>
> The user behavior education about domain names should be that domain
> names are identifier, not names. They should enter into the computer
> exactly as they seen it or reference it.
>
> Anyhow, you are raising issues which have been debated in the list
> before, one which the wg is quite well aware of. So unless you have a
> TC/SC solution which you willing to contributed to the group, I
consider
> this discussion closed.
>
> And if you do have a TC/SC solution, one which have not be considered
by
> the group and UTC and IRG, I would definately love to hear your idea.
>
> -James Seng
>
> > > ps: For those who argue TC/SC can be done 1 to 1, this is an
> excellent
> > > example why it cannot be done 1 to 1. Note I do TC/SC conversion
in
> > > pairs of Han ideographs, not one by one character.
> > >
> > > -James Seng
> > >
> > > > According the drafts,  my school should register 8 domain names
> > > >     ACE(U+53F0,U+6E7E,U+5927,U+5B66)
> > > >     ACE(U+53F0,U+6E7E,U+5927,U+5B78)
> > > >     ACE(U+53F0,U+7063,U+5927,U+5B66)
> > > >     ACE(U+53F0,U+7063,U+5927,U+5B78)
> > > >     ACE(U+81FA,U+6E7E,U+5927,U+5B66)
> > > >     ACE(U+81FA,U+6E7E,U+5927,U+5B78)
> > > >     ACE(U+81FA,U+7063,U+5927,U+5B66)
> > > >     ACE(U+81FA,U+7063,U+5927,U+5B78)
> > > > to let user to access my school (NTU, "xWj" in Big5)
without
> > > > worrying
> > > > if he or she keys in right character.
> > > >
> > > > and under each domain, we have to create 4 sub-domains for my
> > > > institite(CSIE,
> > > > "Tt" in BIG5),
> > > >     ACE(U+8D44,U+8BAF,U+7CFB)
> > > >     ACE(U+8D44,U+8A0A,U+7CFB)
> > > >     ACE(U+8CC7,U+8BAF,U+7CFB)
> > > >     ACE(U+8CC7,U+8A0A,U+7CFB)
> > > >
> > > > and under each of 8*4=32 sub-domains, create 4 records for a web
> > > > server(web,
> > > > ""
> > > > in BIG5)
> > > >     ACE(U+7DB2,U+9801)
> > > >     ACE(U+7DB2,U+9875)
> > > >     ACE(U+7F51,U+9801)
> > > >     ACE(U+7F51,U+9875)
> > > >
> > > > And finally, i have to set all 8*4*4=128 domain names at the
> > > > configuration
> > > > files to
> > > > prevent error messages such as "host not found", or "page not
> found"
> > > > even if
> > > > i have
> > > > correctly set my DNS server.
> > > >
> > > > If it is true, please do not pass these drafts!! It's too
> terrible,
> > > > there
> > > > are many Web servers,
> > > > mail servers, and other severs.....
> > > >
> > > > If I'm wrong, please correct me, and please forgive my poor
> English.
> > > >
> > > >
> > > >
> > > >
> > > > _________________________________________________________
> > > > Do You Yahoo!?
> > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > >
> > > >
> > > >
> > > >
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Fri Feb  8 09:44: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 JAA08373
	for ; Fri, 8 Feb 2002 09:44:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZC7d-0007lo-00
	for idn-data@psg.com; Fri, 08 Feb 2002 06:35:29 -0800
Date: Fri, 8 Feb 2002 09:02:18 -0500
To: unicode@unicode.org
From: Elliotte Rusty Harold 
Subject: [idn] Re: Unicode and Security
Cc: idn@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

At 11:30 AM +0000 2/8/02, Michael Everson wrote:

>Certainly. Some years ago the European Court upheld the right of a 
>Belgian man whose father was Belgian and mother was Greek to spell 
>his hyphenated last name in both scripts. Why should he not be 
>allowed to register a domain based on his own name?
>

Interesting. But I would content this is an edge case that need not 
be supported  in DNS if the cost of doing so is far greater than the 
benefit to be achieved. Of course under my proposal he could have 
LatinName.GreekName.com
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+





From owner-idn@ops.ietf.org  Fri Feb  8 10:04: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 KAA09875
	for ; Fri, 8 Feb 2002 10:04:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZCU0-00095s-00
	for idn-data@psg.com; Fri, 08 Feb 2002 06:58:36 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZCTz-00095i-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 06:58:35 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP id DF051FFC01
	for ; Fri,  8 Feb 2002 22:57:49 +0800 (SGT)
Message-ID: <000501c1b0b1$1d69d6a0$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: 
Subject: [idn] Interesting links 
Date: Fri, 8 Feb 2002 22:58:43 +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 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: 7bit

Wondering where all the protest mails come from (there is 120 of them
right now in my mail box)? See these links.

http://isoc.iis.sinica.edu.tw/
http://www.iis.sinica.edu.tw/~hoho/idn/
http://140.109.18.202/RescueCDN/

Unfortunately, it is in Chinese but most will be able to understand the
last link at least. Sorry, I am not in a position to do this
translation.

-James Seng




From owner-idn@ops.ietf.org  Fri Feb  8 10:21: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 KAA10713
	for ; Fri, 8 Feb 2002 10:21:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZCjs-000A49-00
	for idn-data@psg.com; Fri, 08 Feb 2002 07:15:00 -0800
Received: from imo-m01.mx.aol.com ([64.12.136.4])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZCjs-000A43-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 07:15:00 -0800
Received: from DougEwell2@cs.com
	by imo-m01.mx.aol.com (mail_out_v32.5.) id i.13.64091c8 (4560);
	Fri, 8 Feb 2002 10:14:55 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <13.64091c8.2995456f@cs.com>
Date: Fri, 8 Feb 2002 10:14:55 EST
Subject: Re: [idn] A question...
To: idn@ops.ietf.org
CC: rosenne@qsm.co.il, jseng@pobox.org.sg, jw-lin@yahoo.com.tw
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-08 5:05:04 Pacific Standard Time, 
rosenne@qsm.co.il writes:

> VERBATIM means "word for word". LITERATIM is "letter by letter". This is
> precisely the essence of the problem - you hear a domain name, and spell
> it exactly as you hear it, and it should be found. 

www.color.com and www.colour.com are not ever going to match.

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Fri Feb  8 15:16: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 PAA23294
	for ; Fri, 8 Feb 2002 15:16:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZHHu-00017a-00
	for idn-data@psg.com; Fri, 08 Feb 2002 12:06:26 -0800
Received: from friendly.realnames.com ([63.251.238.102])
	by psg.com with smtp (Exim 3.33 #1)
	id 16ZHHt-00017S-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 12:06:25 -0800
Received: (qmail 32733 invoked by uid 104); 8 Feb 2002 20:06:19 -0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.819882 secs); 08 Feb 2002 20:06:19 -0000
Received: from heaven.internal.realnames.com (10.1.5.39)
  by friendly.realnames.com with SMTP; 8 Feb 2002 20:06:18 -0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4726]) by heaven.internal.realnames.com
	Mail essentials (server 2.422) with SMTP id: <261470@heaven.internal.realnames.com>
	 for ; Fri, 8 Feb 2002 12:01:53 PM -0800
	smtpmailfrom  
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 8 Feb 2002 12:06:03 -0800
Message-ID: <7FC3066C236FD511BC5900508BAC86FE9196BC@trestles.internal.realnames.com>
From: Yves Arrouye 
To: "'DougEwell2@cs.com'" , idn@ops.ietf.org
Cc: jseng@pobox.org.sg, jw-lin@yahoo.com.tw
Subject: RE: [idn] A question...
Date: Fri, 8 Feb 2002 12:03:29 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> Did you know there is a very large number called a "googol"?  I believe
> it's
> 10 to the 600th power, or something like that.  I first heard about that
> number decades ago.  Now we are in the Web age, and there is an important
> and
> powerful search engine called "Google."  (Note the different spelling.)
> If I
> had never heard of Google the search engine, and somebody told me to type
> it
> in, I probably would start with my prior knowledge of this identically
> pronounced word, and type "www.googol.com."  Of course, it would fail (or
> maybe it would take me to a totally different site).  I would then
inquire,
> and the person would apologize (maybe) and tell me the ONE TRUE correct
> spelling.

http://www.google.com/corporate/index.html and
http://www.unc.edu/~rowlett/units/large.html

YA




From owner-idn@ops.ietf.org  Fri Feb  8 15:24: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 PAA23668
	for ; Fri, 8 Feb 2002 15:24:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZHQ0-0001ar-00
	for idn-data@psg.com; Fri, 08 Feb 2002 12:14:48 -0800
Received: from mx-out.daemonmail.net ([209.75.5.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZHPz-0001aj-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 12:14:47 -0800
Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1])
	by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id MAA21943;
	Fri, 8 Feb 2002 12:14:43 -0800 (PST)
	(envelope-from rosenne@qsm.co.il)
Received: from qsm3 (qsm3 [212.150.108.238])
	by mail.qsm.co.il with ESMTP id Dh50jlB2
	Fri, 08 Feb 2002 12:14:36 -0700 (PST)
From: "Jonathan Rosenne" 
To: , 
Cc: , 
Subject: RE: [idn] A question...
Date: Fri, 8 Feb 2002 22:14:13 +0200
Message-ID: <000901c1b0dd$30794740$eb0110ac@qsm3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <13.64091c8.2995456f@cs.com>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

So we don't mean VERBATIM.

Jony

> -----Original Message-----
> From: DougEwell2@cs.com [mailto:DougEwell2@cs.com] 
> Sent: Friday, February 08, 2002 5:15 PM
> To: idn@ops.ietf.org
> Cc: rosenne@qsm.co.il; jseng@pobox.org.sg; jw-lin@yahoo.com.tw
> Subject: Re: [idn] A question...
> 
> 
> In a message dated 2002-02-08 5:05:04 Pacific Standard Time, 
> rosenne@qsm.co.il writes:
> 
> > VERBATIM means "word for word". LITERATIM is "letter by 
> letter". This 
> > is precisely the essence of the problem - you hear a domain 
> name, and 
> > spell it exactly as you hear it, and it should be found.
> 
> www.color.com and www.colour.com are not ever going to match.
> 
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)
> 
> 




From owner-idn@ops.ietf.org  Fri Feb  8 16:18: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 QAA25215
	for ; Fri, 8 Feb 2002 16:18:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZIK2-00055A-00
	for idn-data@psg.com; Fri, 08 Feb 2002 13:12:42 -0800
Received: from gate.sinica.edu.tw ([140.109.4.130])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZIJz-000551-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 13:12:40 -0800
Received: from itsnb (i2ot2.iis.sinica.edu.tw [140.109.21.154])
	by gate.sinica.edu.tw (8.11.3/8.11.3) with SMTP id g18LCNs18556;
	Sat, 9 Feb 2002 05:12:24 +0800 (CST)
Message-ID: <021e01c1b0e5$611d15e0$c5e16d8c@itsnb>
From: "Chun-Hsin Wu" 
To: "James Seng/Personal" , 
Cc: 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio>
Subject: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 05:12:49 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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

Dear James,

Adopting your word, please don't try to PAINT yourself as a daily Chinese
computer user. As I know, you did not use Chinese Windows system daily
nor input Chinese characters often in your dialy work. I'm afraid that an
unfamiliar or inexperienced Chinese-system user can not thoroughly realize
what troubles the proposed IDN solution will make to world-wide Chinese
Internet societies. Although we have discussed inputting and using SC/TC
characters in the end of Oct 2001, I still quite doubt whether you really
understand what I try to explain.

### Inputting mixed SC/TC Characters

In http://www.imc.org/idn/mail-archive/msg04520.html, you said it's
difficult to type mixing TC and SC and we need to switch from TC IME
to SC IME repeatively. Followed by Xiang Deng from CNNIC in
http://www.imc.org/idn/mail-archive/msg04521.html, he told you:
    "No, I do can type TC AND SC in a very usual IME without swich."
Besides, in http://www.imc.org/idn/mail-archive/msg04523.html, I also
told you:
    "Most IMEs in Traditional Windows 2000 can support TC and SC
    directly without switching, even they can let the user type in
    Japanese characters without switching.  It is not unusual for one IME
    to support all, or as many as possible, Unicode characters if the system
    supports Unicode.  For examples, the phonetic imput method and the
    Boshimy input method. The former is the default method in all Chinese
    systems and almost every Chinese or Taiwanese who uses computers
    knows how to use it easily. The later is widely used by many people
    who want to have high Chinese input rate, especially for professional
    users."

Two daily native Chinese Windows users have tried to tell you we do
be able to input mixed TC/SC by a single input method software (IME).
However, you still claimed in your response:
http://www.imc.org/idn/mail-archive/msg04524.html
    "On Windows, you install 2 IME, one for TC and the other for SC.
    You toggle between these two while you key in."
Well, how were you so confident? To give you more feeling, in
http://www.imc.org/idn/mail-archive/msg04545.html , I demostrated
two examples that use a single IME to input mixed SC/TC, and told you:
    "So it is clear that we don't need to install TWO IMEs to
    input mixed TC and SC in TC Windows 2000. The user also
    does not need to toggle between TC and SC while input. It
    is natural that one TC input method software aims to make
    the user input as many Unicode characters (and as easy)
    as possible. Indeed, almost every add-on TC input method
    software can support far more HAN characters than those
    defined in Unicode, since some other charsets define more
    characters than Unicode. The market will drive the software
    company to do so, becoming a Uni-input method software
    and supporting as many HAN characters as possible."

Now, in http://www.imc.org/idn/mail-archive/msg05781.html you still
claimed:
    "By default, TC or SC will be output depending which IME you use. Of
    course, you *could* manually scroll down the list to get the characters
    or you could toggle the input method to do so."
Well, well, .... Fine. See:
    http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm
It gives you three examples and respective window snapshots to prove
that one single IME can output TC and SC easily. I believe many IME
softwares have more functions  for multi-lingual inputs than your
understanding. Indeed, IME developers also plan to support inputting
multi-lingual Unicode characters more conveniently in their new
versions. Next time you come to Taiwan, I can help you discuss IME
issues with the developers of top 3 IME softwares in Taiwan, in
Chinese conversation.

By the way, can you easily distinguish the displayed Chinese names in
Example 2 and Example 3: eight combinations for "Islam" in Example 2
and two combinations for "Ministry of the Interior" in Example 3?

If you do check the variants in Unicode AND display them under Chinese
Unicode systems such as Traditional Chinese Windows 2000, you can
find more similar-looking but easy-confusing SC/TC pairs.

### 3-month late or 30-year's pain?

I've been using Chinese computer systems for about twenty years. In
addition to input-method developers, Chinese software developers,
Internet application developers and IDN-related professionals and officers,
these months people from CDNC have also discussed Unicode and IDN
issues with many Chinese linguists, several of them having experiences in
Chinese/Han encoding for more than twenty years. Except for PunnyCode,
I can say none of them agree with passing current proposed IDN WG's
drafts for CDN hastily. It is just like that ALL Chinese participants in
IETF
IDN WG meetings, who use Chinese systems daily, did not agree with the
proposed IDN solution.

Things go worse due to that it's not easy for experienced native Chinese
users to explain the CDN issues to unfamiliar or inexperienced
Chinese-system users fluently in English. That's part of the reasons that
Unicode Consortium/WG2 needed to form IRG to discuss Han ideographs
and it's more easy for JET members (CJKT) to have concrete discussions
and consensus. Within IDN WG, it's clear that most IDN WG members
are unfamiliar or inexperienced Chinese-system users.  It's said that they
are tired and time-stressed. Although they have tried very hard to solve
IDN issues, however, IETF IDN WG seem to stand like that their solution
is also best to CDN and be trying to pass the proposed IDN solution for
CDN, which does not  have the consensus from CDNC and native
Chinese participants in IDN WG meetings. If IDN is really important to
the developement of Internet, I'm afraid that the process of passing current
IDN standards under the above condition would become a bad case and
symbol in the history of Internet.

To be responsible for world-wide and Chinese Internet societies, hope we
all move carefully and responsibly. That's my two-cent point. Hope we have
peaceful and justicial Internet World.

Happy Chinese New Year

Chun-Hsin Wu

----- Original Message -----
From: "James Seng/Personal" 
To: ; 
Sent: Friday, February 08, 2002 12:23 PM
Subject: Re: [idn] A question...


> > It is not ture. I think, maybe you are not familiar how Chinese
> characters
> > are used in our daily work.
>
> Perhaps you are not be aware I am possibly a Chinese myself too and I
> use Chinese in my daily live, both traditional (in Malaysia) and
> simplified (Singapore).  And I work with many Chinese linguists in the
> last 2 years and the many of them are not Chinese.
>
> > But the other 5 cases are often written
> > (not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
> > preferrd because they are less-strokes.
>
> Thanks. Then we have no problem.
>
> > What you said are in a restricit environment, like Windows 98, on
> which
> > you can not input those characters on some limited IME. However,
> > Windows 2000 will change the user behavior.
>
> By default, TC or SC will be output depending which IME you use. Of
> course, you *could* manually scroll down the list to get the characters
> or you could toggle the input method to do so.
>
> The user behavior education about domain names should be that domain
> names are identifier, not names. They should enter into the computer
> exactly as they seen it or reference it.
>
> Anyhow, you are raising issues which have been debated in the list
> before, one which the wg is quite well aware of. So unless you have a
> TC/SC solution which you willing to contributed to the group, I consider
> this discussion closed.
>
> And if you do have a TC/SC solution, one which have not be considered by
> the group and UTC and IRG, I would definately love to hear your idea.
>
> -James Seng





From owner-idn@ops.ietf.org  Fri Feb  8 16:31: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 QAA25576
	for ; Fri, 8 Feb 2002 16:31:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZIX0-0005rJ-00
	for idn-data@psg.com; Fri, 08 Feb 2002 13:26:06 -0800
Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZIWy-0005q9-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 13:26:05 -0800
Received: from bamdad.org (IDENT:root@gilas.bamdad.org [194.225.42.242])
	by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g18LPwv26020;
	Sat, 9 Feb 2002 00:55:58 +0330
Received: from localhost (roozbeh@localhost)
	by bamdad.org (8.11.6/8.11.6) with ESMTP id g18LWvu13771;
	Sat, 9 Feb 2002 01:02:59 +0330
X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs
Date: Sat, 9 Feb 2002 01:02:57 +0330 (IRT)
From: Roozbeh Pournader 
X-X-Sender: roozbeh@gilas.bamdad.org
To: DougEwell2@cs.com
cc: IDN 
Subject: OT - Re: Googol (was Re: [idn] A question...)
In-Reply-To: <136.8a4dd13.2994c381@cs.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Fri, 8 Feb 2002 DougEwell2@cs.com wrote:

> Did you know there is a very large number called a "googol"?  I believe it's 
> 10 to the 600th power, [...]

10 to the 100th power, it is.

roozbeh




From owner-idn@ops.ietf.org  Fri Feb  8 17:39: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 RAA26851
	for ; Fri, 8 Feb 2002 17:39:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZJUZ-0009dT-00
	for idn-data@psg.com; Fri, 08 Feb 2002 14:27:39 -0800
Received: from shell.nominum.com ([128.177.192.160])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZJUY-0009dM-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 14:27:38 -0800
Received: by shell.nominum.com (Postfix, from userid 11089)
	id E1F5A3190C; Fri,  8 Feb 2002 14:27:37 -0800 (PST)
Date: Fri, 8 Feb 2002 14:27:37 -0800
From: Ted Hardie 
To: Chun-Hsin Wu 
Cc: James Seng/Personal , idn@ops.ietf.org,
        jw-lin@yahoo.com.tw
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <20020208142737.A53521@shell.nominum.com>
Reply-To: Ted.Hardie@nominum.com
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <021e01c1b0e5$611d15e0$c5e16d8c@itsnb>; from wuch@gate.sinica.edu.tw on Sat, Feb 09, 2002 at 05:12:49AM +0800
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Chun-Hsin Wu,
	Thank you for your message and your New Year's greetings.
http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm gives a
very visually powerful demonstration of the problem the working group
has debated over these many months, and I have no doubt that is useful
for many members of the working group to see some of the character
mixtures rather than hear them described.  Thank you for your efforts.
	Like others in this forum, I am an "inexperienced"
Chinese-system user (I use an English-language system with two Chinese
language IMEs installed, much like the system James described below).
Even in that context, it has been clear to me, and to many in the
group, that the TC/SC problem and its concomitant issues are very
real.  We do not dispute the problem.
	We are faced, then, with the following situation: after
receiving a great deal of expert advice, the working group has come to
believe that the problem of character equivalence cannot be solved
within the context of this working group.  Based on that belief, we
can do one of two things:

1) stop, and declare that the problem we set out to solve (increasing
the repertoire of available characters) should not be attempted until
the character equivalence problem can be solved.

2) explicitly acknowledge that we have not solved the character
equivalence problem but increase the repertoire of available
characters, allowing others to limit by policy which characters may be
used in specific domains.

	As the chairs and others have repeatedly noted, a solution to
the problem of character equivalence in the context of Unicode and
Unicode's CJK unification is very difficult, and we have no single
entity who is authoritative for Chinese, Japanese, and Korean on whom
to rely.  If we select choice one, we cannot have any firm or
reasonable expectation for the timing of the emergence of a standard.
It would also have to wait for all of the other, similar character
equivalence problems in Unicode to reach resolution.  This means that
the repertoire would remain that of US-ASCII for the foreseeable
future, with all of the drawbacks that implies.

	We have heard significant objections in the last call period
that the work involved in limiting characters by policy will be
onerous and that it will not solve all of the problems of character
equivalence for the Chinese language community.  That is a substantive
objection.  The chairs' response could be expressed as: "given your
objection, can you present a solution for *CJK* character equivalence
*in Unicode* at this time?"  

	Absent a realistic answer to that question, the group seems
likely to adopt some variation of 2) above.  The other choice,
to continue to limit the repertoire to US-ASCII seems untenable.  
That may reflect a bias on the group's part to reach some resolution
to the character repertoire problem, but it also seems like a fairly
reasonable response; given the choice between having eight potential
character groupings for "qingzhenjiao" and zero, it has chosen eight.
If you would prefer zero, with no time horizon for anything better,
than this is the period to make that preference known.

	My apologies to the chairs or the group if I misrepresented
their sense of consensus.
			regards,
				Ted Hardie







On Sat, Feb 09, 2002 at 05:12:49AM +0800, Chun-Hsin Wu wrote:
> Dear James,
> 
> Adopting your word, please don't try to PAINT yourself as a daily Chinese
> computer user. As I know, you did not use Chinese Windows system daily
> nor input Chinese characters often in your dialy work. I'm afraid that an
> unfamiliar or inexperienced Chinese-system user can not thoroughly realize
> what troubles the proposed IDN solution will make to world-wide Chinese
> Internet societies. Although we have discussed inputting and using SC/TC
> characters in the end of Oct 2001, I still quite doubt whether you really
> understand what I try to explain.
> 
> ### Inputting mixed SC/TC Characters
> 
> In http://www.imc.org/idn/mail-archive/msg04520.html, you said it's
> difficult to type mixing TC and SC and we need to switch from TC IME
> to SC IME repeatively. Followed by Xiang Deng from CNNIC in
> http://www.imc.org/idn/mail-archive/msg04521.html, he told you:
>     "No, I do can type TC AND SC in a very usual IME without swich."
> Besides, in http://www.imc.org/idn/mail-archive/msg04523.html, I also
> told you:
>     "Most IMEs in Traditional Windows 2000 can support TC and SC
>     directly without switching, even they can let the user type in
>     Japanese characters without switching.  It is not unusual for one IME
>     to support all, or as many as possible, Unicode characters if the system
>     supports Unicode.  For examples, the phonetic imput method and the
>     Boshimy input method. The former is the default method in all Chinese
>     systems and almost every Chinese or Taiwanese who uses computers
>     knows how to use it easily. The later is widely used by many people
>     who want to have high Chinese input rate, especially for professional
>     users."
> 
> Two daily native Chinese Windows users have tried to tell you we do
> be able to input mixed TC/SC by a single input method software (IME).
> However, you still claimed in your response:
> http://www.imc.org/idn/mail-archive/msg04524.html
>     "On Windows, you install 2 IME, one for TC and the other for SC.
>     You toggle between these two while you key in."
> Well, how were you so confident? To give you more feeling, in
> http://www.imc.org/idn/mail-archive/msg04545.html , I demostrated
> two examples that use a single IME to input mixed SC/TC, and told you:
>     "So it is clear that we don't need to install TWO IMEs to
>     input mixed TC and SC in TC Windows 2000. The user also
>     does not need to toggle between TC and SC while input. It
>     is natural that one TC input method software aims to make
>     the user input as many Unicode characters (and as easy)
>     as possible. Indeed, almost every add-on TC input method
>     software can support far more HAN characters than those
>     defined in Unicode, since some other charsets define more
>     characters than Unicode. The market will drive the software
>     company to do so, becoming a Uni-input method software
>     and supporting as many HAN characters as possible."
> 
> Now, in http://www.imc.org/idn/mail-archive/msg05781.html you still
> claimed:
>     "By default, TC or SC will be output depending which IME you use. Of
>     course, you *could* manually scroll down the list to get the characters
>     or you could toggle the input method to do so."
> Well, well, .... Fine. See:
>     http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm
> It gives you three examples and respective window snapshots to prove
> that one single IME can output TC and SC easily. I believe many IME
> softwares have more functions  for multi-lingual inputs than your
> understanding. Indeed, IME developers also plan to support inputting
> multi-lingual Unicode characters more conveniently in their new
> versions. Next time you come to Taiwan, I can help you discuss IME
> issues with the developers of top 3 IME softwares in Taiwan, in
> Chinese conversation.
> 
> By the way, can you easily distinguish the displayed Chinese names in
> Example 2 and Example 3: eight combinations for "Islam" in Example 2
> and two combinations for "Ministry of the Interior" in Example 3?
> 
> If you do check the variants in Unicode AND display them under Chinese
> Unicode systems such as Traditional Chinese Windows 2000, you can
> find more similar-looking but easy-confusing SC/TC pairs.
> 
> ### 3-month late or 30-year's pain?
> 
> I've been using Chinese computer systems for about twenty years. In
> addition to input-method developers, Chinese software developers,
> Internet application developers and IDN-related professionals and officers,
> these months people from CDNC have also discussed Unicode and IDN
> issues with many Chinese linguists, several of them having experiences in
> Chinese/Han encoding for more than twenty years. Except for PunnyCode,
> I can say none of them agree with passing current proposed IDN WG's
> drafts for CDN hastily. It is just like that ALL Chinese participants in
> IETF
> IDN WG meetings, who use Chinese systems daily, did not agree with the
> proposed IDN solution.
> 
> Things go worse due to that it's not easy for experienced native Chinese
> users to explain the CDN issues to unfamiliar or inexperienced
> Chinese-system users fluently in English. That's part of the reasons that
> Unicode Consortium/WG2 needed to form IRG to discuss Han ideographs
> and it's more easy for JET members (CJKT) to have concrete discussions
> and consensus. Within IDN WG, it's clear that most IDN WG members
> are unfamiliar or inexperienced Chinese-system users.  It's said that they
> are tired and time-stressed. Although they have tried very hard to solve
> IDN issues, however, IETF IDN WG seem to stand like that their solution
> is also best to CDN and be trying to pass the proposed IDN solution for
> CDN, which does not  have the consensus from CDNC and native
> Chinese participants in IDN WG meetings. If IDN is really important to
> the developement of Internet, I'm afraid that the process of passing current
> IDN standards under the above condition would become a bad case and
> symbol in the history of Internet.
> 
> To be responsible for world-wide and Chinese Internet societies, hope we
> all move carefully and responsibly. That's my two-cent point. Hope we have
> peaceful and justicial Internet World.
> 
> Happy Chinese New Year
> 
> Chun-Hsin Wu
> 
> ----- Original Message -----
> From: "James Seng/Personal" 
> To: ; 
> Sent: Friday, February 08, 2002 12:23 PM
> Subject: Re: [idn] A question...
> 
> 
> > > It is not ture. I think, maybe you are not familiar how Chinese
> > characters
> > > are used in our daily work.
> >
> > Perhaps you are not be aware I am possibly a Chinese myself too and I
> > use Chinese in my daily live, both traditional (in Malaysia) and
> > simplified (Singapore).  And I work with many Chinese linguists in the
> > last 2 years and the many of them are not Chinese.
> >
> > > But the other 5 cases are often written
> > > (not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
> > > preferrd because they are less-strokes.
> >
> > Thanks. Then we have no problem.
> >
> > > What you said are in a restricit environment, like Windows 98, on
> > which
> > > you can not input those characters on some limited IME. However,
> > > Windows 2000 will change the user behavior.
> >
> > By default, TC or SC will be output depending which IME you use. Of
> > course, you *could* manually scroll down the list to get the characters
> > or you could toggle the input method to do so.
> >
> > The user behavior education about domain names should be that domain
> > names are identifier, not names. They should enter into the computer
> > exactly as they seen it or reference it.
> >
> > Anyhow, you are raising issues which have been debated in the list
> > before, one which the wg is quite well aware of. So unless you have a
> > TC/SC solution which you willing to contributed to the group, I consider
> > this discussion closed.
> >
> > And if you do have a TC/SC solution, one which have not be considered by
> > the group and UTC and IRG, I would definately love to hear your idea.
> >
> > -James Seng
> 
> 
> 



From owner-idn@ops.ietf.org  Fri Feb  8 19:34: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 TAA28193
	for ; Fri, 8 Feb 2002 19:34:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZLH2-000GSZ-00
	for idn-data@psg.com; Fri, 08 Feb 2002 16:21:48 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZLH0-000GST-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 16:21:47 -0800
Received: from jamessonyvaio (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g190LdZW024722;
	Sat, 9 Feb 2002 08:21:39 +0800
Message-ID: <080b01c1b0ff$cfcd93b0$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: "Chun-Hsin Wu" , 
Cc: 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 08:22:09 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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.4910.0300
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

1. Lets do away with the personal attack on me. It does nothing to help
your arguments.

2. I acknowledge I am weaker in my daily chinese compared to people in
China/Taiwan, this does not mean I do not know the chinese script and
its orthography. And no, I understand you perfectly well. But I doubt
you understand (or hear) me - See note 6.

3. Have you speak to your IRG and SC2 representives lately and ask them
about this problem? What is their unambigitous response?

4. I stand correct in my statement last mail: You can input either TC or
SC by manually scrolling down the system. Your screen shot represent
nothing. Different IME will give you different predictive result
depending on the frequency of a personal usage of the characters.
Therefore, a screen shot on your computer would be totally different
from mine.

5. You have only repeated problems that we already knows. You have not
demonstrated any solution which is technical possible now. This is not a
3 months or 30yrs plan thing. It is about what is technically feasible
and what is not.

6. Maybe working for another 30yrs time, we might come up with an AI
that can do TC/SC, and for all the other language issues. But it appears
you and your colleague continue to ignore (something we been telling you
again and again):
    1. DNS is an identifier system. We deal with scripts, not languages.
    2. Human language is complex. Expect DNS to deal with language
            is technically impossible right now. (Proof me otherwise).

7. . Since TWNIC is so insistent on the solution, I suggest TWNIC (or
anyone else) put a total ban on all chinese characters in the
registration system. That will also solve your so-called "2^n" problem
in your system. Then continue to work with IRNSS (or some other areas)
for a solution you can accept.

8. Some suggestions: If you want other to consider your issues
favourably, then
    1. present your arguments unbiasly.
    2. consider a broader scope of the problem
    3. understand other people issues and willingness to compromise
    4. learn how the process works in IETF
So far, I have seen all otherwise.

-James Seng

----- Original Message -----
From: "Chun-Hsin Wu" 
To: "James Seng/Personal" ; 
Cc: 
Sent: Saturday, February 09, 2002 5:12 AM
Subject: Inputting mixed SC/TC (Re: [idn] A question...)


> Dear James,
>
> Adopting your word, please don't try to PAINT yourself as a daily
Chinese
> computer user. As I know, you did not use Chinese Windows system daily
> nor input Chinese characters often in your dialy work. I'm afraid that
an
> unfamiliar or inexperienced Chinese-system user can not thoroughly
realize
> what troubles the proposed IDN solution will make to world-wide
Chinese
> Internet societies. Although we have discussed inputting and using
SC/TC
> characters in the end of Oct 2001, I still quite doubt whether you
really
> understand what I try to explain.
>
> ### Inputting mixed SC/TC Characters
>
> In http://www.imc.org/idn/mail-archive/msg04520.html, you said it's
> difficult to type mixing TC and SC and we need to switch from TC IME
> to SC IME repeatively. Followed by Xiang Deng from CNNIC in
> http://www.imc.org/idn/mail-archive/msg04521.html, he told you:
>     "No, I do can type TC AND SC in a very usual IME without swich."
> Besides, in http://www.imc.org/idn/mail-archive/msg04523.html, I also
> told you:
>     "Most IMEs in Traditional Windows 2000 can support TC and SC
>     directly without switching, even they can let the user type in
>     Japanese characters without switching.  It is not unusual for one
IME
>     to support all, or as many as possible, Unicode characters if the
system
>     supports Unicode.  For examples, the phonetic imput method and the
>     Boshimy input method. The former is the default method in all
Chinese
>     systems and almost every Chinese or Taiwanese who uses computers
>     knows how to use it easily. The later is widely used by many
people
>     who want to have high Chinese input rate, especially for
professional
>     users."
>
> Two daily native Chinese Windows users have tried to tell you we do
> be able to input mixed TC/SC by a single input method software (IME).
> However, you still claimed in your response:
> http://www.imc.org/idn/mail-archive/msg04524.html
>     "On Windows, you install 2 IME, one for TC and the other for SC.
>     You toggle between these two while you key in."
> Well, how were you so confident? To give you more feeling, in
> http://www.imc.org/idn/mail-archive/msg04545.html , I demostrated
> two examples that use a single IME to input mixed SC/TC, and told you:
>     "So it is clear that we don't need to install TWO IMEs to
>     input mixed TC and SC in TC Windows 2000. The user also
>     does not need to toggle between TC and SC while input. It
>     is natural that one TC input method software aims to make
>     the user input as many Unicode characters (and as easy)
>     as possible. Indeed, almost every add-on TC input method
>     software can support far more HAN characters than those
>     defined in Unicode, since some other charsets define more
>     characters than Unicode. The market will drive the software
>     company to do so, becoming a Uni-input method software
>     and supporting as many HAN characters as possible."
>
> Now, in http://www.imc.org/idn/mail-archive/msg05781.html you still
> claimed:
>     "By default, TC or SC will be output depending which IME you use.
Of
>     course, you *could* manually scroll down the list to get the
characters
>     or you could toggle the input method to do so."
> Well, well, .... Fine. See:
>     http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm
> It gives you three examples and respective window snapshots to prove
> that one single IME can output TC and SC easily. I believe many IME
> softwares have more functions  for multi-lingual inputs than your
> understanding. Indeed, IME developers also plan to support inputting
> multi-lingual Unicode characters more conveniently in their new
> versions. Next time you come to Taiwan, I can help you discuss IME
> issues with the developers of top 3 IME softwares in Taiwan, in
> Chinese conversation.
>
> By the way, can you easily distinguish the displayed Chinese names in
> Example 2 and Example 3: eight combinations for "Islam" in Example 2
> and two combinations for "Ministry of the Interior" in Example 3?
>
> If you do check the variants in Unicode AND display them under Chinese
> Unicode systems such as Traditional Chinese Windows 2000, you can
> find more similar-looking but easy-confusing SC/TC pairs.
>
> ### 3-month late or 30-year's pain?
>
> I've been using Chinese computer systems for about twenty years. In
> addition to input-method developers, Chinese software developers,
> Internet application developers and IDN-related professionals and
officers,
> these months people from CDNC have also discussed Unicode and IDN
> issues with many Chinese linguists, several of them having experiences
in
> Chinese/Han encoding for more than twenty years. Except for PunnyCode,
> I can say none of them agree with passing current proposed IDN WG's
> drafts for CDN hastily. It is just like that ALL Chinese participants
in
> IETF
> IDN WG meetings, who use Chinese systems daily, did not agree with the
> proposed IDN solution.
>
> Things go worse due to that it's not easy for experienced native
Chinese
> users to explain the CDN issues to unfamiliar or inexperienced
> Chinese-system users fluently in English. That's part of the reasons
that
> Unicode Consortium/WG2 needed to form IRG to discuss Han ideographs
> and it's more easy for JET members (CJKT) to have concrete discussions
> and consensus. Within IDN WG, it's clear that most IDN WG members
> are unfamiliar or inexperienced Chinese-system users.  It's said that
they
> are tired and time-stressed. Although they have tried very hard to
solve
> IDN issues, however, IETF IDN WG seem to stand like that their
solution
> is also best to CDN and be trying to pass the proposed IDN solution
for
> CDN, which does not  have the consensus from CDNC and native
> Chinese participants in IDN WG meetings. If IDN is really important to
> the developement of Internet, I'm afraid that the process of passing
current
> IDN standards under the above condition would become a bad case and
> symbol in the history of Internet.
>
> To be responsible for world-wide and Chinese Internet societies, hope
we
> all move carefully and responsibly. That's my two-cent point. Hope we
have
> peaceful and justicial Internet World.
>
> Happy Chinese New Year
>
> Chun-Hsin Wu
>
> ----- Original Message -----
> From: "James Seng/Personal" 
> To: ; 
> Sent: Friday, February 08, 2002 12:23 PM
> Subject: Re: [idn] A question...
>
>
> > > It is not ture. I think, maybe you are not familiar how Chinese
> > characters
> > > are used in our daily work.
> >
> > Perhaps you are not be aware I am possibly a Chinese myself too and
I
> > use Chinese in my daily live, both traditional (in Malaysia) and
> > simplified (Singapore).  And I work with many Chinese linguists in
the
> > last 2 years and the many of them are not Chinese.
> >
> > > But the other 5 cases are often written
> > > (not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
> > > preferrd because they are less-strokes.
> >
> > Thanks. Then we have no problem.
> >
> > > What you said are in a restricit environment, like Windows 98, on
> > which
> > > you can not input those characters on some limited IME. However,
> > > Windows 2000 will change the user behavior.
> >
> > By default, TC or SC will be output depending which IME you use. Of
> > course, you *could* manually scroll down the list to get the
characters
> > or you could toggle the input method to do so.
> >
> > The user behavior education about domain names should be that domain
> > names are identifier, not names. They should enter into the computer
> > exactly as they seen it or reference it.
> >
> > Anyhow, you are raising issues which have been debated in the list
> > before, one which the wg is quite well aware of. So unless you have
a
> > TC/SC solution which you willing to contributed to the group, I
consider
> > this discussion closed.
> >
> > And if you do have a TC/SC solution, one which have not be
considered by
> > the group and UTC and IRG, I would definately love to hear your
idea.
> >
> > -James Seng
>
>
>




From owner-idn@ops.ietf.org  Fri Feb  8 19:36: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 TAA28214
	for ; Fri, 8 Feb 2002 19:36:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZLNM-000GvJ-00
	for idn-data@psg.com; Fri, 08 Feb 2002 16:28:20 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZLNL-000GvD-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 16:28:19 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id QAA05642
	for ; Fri, 8 Feb 2002 16:28:07 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id QAA03685
	for ; Fri, 8 Feb 2002 16:28:18 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id QAA03674;
	Fri, 8 Feb 2002 16:28:17 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id QAA27099;
	Fri, 8 Feb 2002 16:27:17 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id QAA02105;
	Fri, 8 Feb 2002 16:28:15 -0800 (PST)
Date: Fri, 8 Feb 2002 16:28:15 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202090028.QAA02105@birdie.sybase.com>
To: Ted.Hardie@nominum.com
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm gives a
> very visually powerful demonstration of the problem the working group
> has debated over these many months, and I have no doubt that is useful
> for many members of the working group to see some of the character
> mixtures rather than hear them described.  Thank you for your efforts.

Lest those on this list unfamiliar with Chinese be overly impressed
with the "powerful" demonstration posted on that site, the
islam.gif (2nd example) is *not* a valid representation of the
distinctions in characters in question.

The first character shown in all 8 lines is the glyph for U+6DF8
  and *not* the glyph for U+6E05.

The second character shown in all 8 lines is the glyph for U+771E
  and *not* the glyph for U+771F.

The third character shown in all 8 lines is the glyph for U+654E
  and *not* the glyph for U+6559.

So if told to type *exactly* what is shown in each line, the right
answer in all 8 cases would be the same Unicode string:
U+6DF8 U+771E U+654E.

There *are* minute glyph distinctions here in the example, so it is
clear that the font used to display these has a different glyph
for each code position, but the font designer has *chosen* to
make each pair look almost identical, rather than to reflect the
glyph distinctions which underlay the separate character encoding.
Presumably this is to meet some Taiwan-specific market
requirements for font design. But the net effect is to artificially
exaggerate the problem being complained about by those objecting
to the IDNA handling of Chinese characters.

To then advertise these examples as making the problem clear to
those on this list who may be less than conversant with the
Chinese variant problems I consider to verge on misleading.

Those who wish to get an accurate depiction of the differences
between the 3 pairs of characters in question should consult the
standards themselves: ISO/IEC 10646-1:2000 or the online charts
for the Unicode Standard:

http://www.unicode.org/charts/PDF/U4E00.pdf

--Ken

(* O.k., I'll sit back down now. *)




From owner-idn@ops.ietf.org  Fri Feb  8 20: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 UAA28855
	for ; Fri, 8 Feb 2002 20:26:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZM9q-000K0I-00
	for idn-data@psg.com; Fri, 08 Feb 2002 17:18:26 -0800
Received: from smtp13.singnet.com.sg ([165.21.6.33])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZM9p-000K0C-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 17:18:25 -0800
Received: from jamessonyvaio (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp13.singnet.com.sg (8.12.2/8.12.2) with SMTP id g191IINv022570;
	Sat, 9 Feb 2002 09:18:18 +0800
Message-ID: <08a601c1b107$b9727ce0$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: "Chun-Hsin Wu" , 
Cc: 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 09:18:47 +0800
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 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

Btw, do you realise that all W2K Traditional IME have a configuration
called "只顯示BIG5字集" (only show BIG5 characters) which will effectly
elimenate all the confusion you mention here in this mail?

Similar options are available for Simplified IME whereby you can select
between GB2312 and GBK.

-James Seng

----- Original Message -----
From: "Chun-Hsin Wu" 
To: "James Seng/Personal" ; 
Cc: 
Sent: Saturday, February 09, 2002 5:12 AM
Subject: Inputting mixed SC/TC (Re: [idn] A question...)


> Dear James,
>
> Adopting your word, please don't try to PAINT yourself as a daily
Chinese
> computer user. As I know, you did not use Chinese Windows system daily
> nor input Chinese characters often in your dialy work. I'm afraid that
an
> unfamiliar or inexperienced Chinese-system user can not thoroughly
realize
> what troubles the proposed IDN solution will make to world-wide
Chinese
> Internet societies. Although we have discussed inputting and using
SC/TC
> characters in the end of Oct 2001, I still quite doubt whether you
really
> understand what I try to explain.
>
> ### Inputting mixed SC/TC Characters
>
> In http://www.imc.org/idn/mail-archive/msg04520.html, you said it's
> difficult to type mixing TC and SC and we need to switch from TC IME
> to SC IME repeatively. Followed by Xiang Deng from CNNIC in
> http://www.imc.org/idn/mail-archive/msg04521.html, he told you:
>     "No, I do can type TC AND SC in a very usual IME without swich."
> Besides, in http://www.imc.org/idn/mail-archive/msg04523.html, I also
> told you:
>     "Most IMEs in Traditional Windows 2000 can support TC and SC
>     directly without switching, even they can let the user type in
>     Japanese characters without switching.  It is not unusual for one
IME
>     to support all, or as many as possible, Unicode characters if the
system
>     supports Unicode.  For examples, the phonetic imput method and the
>     Boshimy input method. The former is the default method in all
Chinese
>     systems and almost every Chinese or Taiwanese who uses computers
>     knows how to use it easily. The later is widely used by many
people
>     who want to have high Chinese input rate, especially for
professional
>     users."
>
> Two daily native Chinese Windows users have tried to tell you we do
> be able to input mixed TC/SC by a single input method software (IME).
> However, you still claimed in your response:
> http://www.imc.org/idn/mail-archive/msg04524.html
>     "On Windows, you install 2 IME, one for TC and the other for SC.
>     You toggle between these two while you key in."
> Well, how were you so confident? To give you more feeling, in
> http://www.imc.org/idn/mail-archive/msg04545.html , I demostrated
> two examples that use a single IME to input mixed SC/TC, and told you:
>     "So it is clear that we don't need to install TWO IMEs to
>     input mixed TC and SC in TC Windows 2000. The user also
>     does not need to toggle between TC and SC while input. It
>     is natural that one TC input method software aims to make
>     the user input as many Unicode characters (and as easy)
>     as possible. Indeed, almost every add-on TC input method
>     software can support far more HAN characters than those
>     defined in Unicode, since some other charsets define more
>     characters than Unicode. The market will drive the software
>     company to do so, becoming a Uni-input method software
>     and supporting as many HAN characters as possible."
>
> Now, in http://www.imc.org/idn/mail-archive/msg05781.html you still
> claimed:
>     "By default, TC or SC will be output depending which IME you use.
Of
>     course, you *could* manually scroll down the list to get the
characters
>     or you could toggle the input method to do so."
> Well, well, .... Fine. See:
>     http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm
> It gives you three examples and respective window snapshots to prove
> that one single IME can output TC and SC easily. I believe many IME
> softwares have more functions  for multi-lingual inputs than your
> understanding. Indeed, IME developers also plan to support inputting
> multi-lingual Unicode characters more conveniently in their new
> versions. Next time you come to Taiwan, I can help you discuss IME
> issues with the developers of top 3 IME softwares in Taiwan, in
> Chinese conversation.
>
> By the way, can you easily distinguish the displayed Chinese names in
> Example 2 and Example 3: eight combinations for "Islam" in Example 2
> and two combinations for "Ministry of the Interior" in Example 3?
>
> If you do check the variants in Unicode AND display them under Chinese
> Unicode systems such as Traditional Chinese Windows 2000, you can
> find more similar-looking but easy-confusing SC/TC pairs.
>
> ### 3-month late or 30-year's pain?
>
> I've been using Chinese computer systems for about twenty years. In
> addition to input-method developers, Chinese software developers,
> Internet application developers and IDN-related professionals and
officers,
> these months people from CDNC have also discussed Unicode and IDN
> issues with many Chinese linguists, several of them having experiences
in
> Chinese/Han encoding for more than twenty years. Except for PunnyCode,
> I can say none of them agree with passing current proposed IDN WG's
> drafts for CDN hastily. It is just like that ALL Chinese participants
in
> IETF
> IDN WG meetings, who use Chinese systems daily, did not agree with the
> proposed IDN solution.
>
> Things go worse due to that it's not easy for experienced native
Chinese
> users to explain the CDN issues to unfamiliar or inexperienced
> Chinese-system users fluently in English. That's part of the reasons
that
> Unicode Consortium/WG2 needed to form IRG to discuss Han ideographs
> and it's more easy for JET members (CJKT) to have concrete discussions
> and consensus. Within IDN WG, it's clear that most IDN WG members
> are unfamiliar or inexperienced Chinese-system users.  It's said that
they
> are tired and time-stressed. Although they have tried very hard to
solve
> IDN issues, however, IETF IDN WG seem to stand like that their
solution
> is also best to CDN and be trying to pass the proposed IDN solution
for
> CDN, which does not  have the consensus from CDNC and native
> Chinese participants in IDN WG meetings. If IDN is really important to
> the developement of Internet, I'm afraid that the process of passing
current
> IDN standards under the above condition would become a bad case and
> symbol in the history of Internet.
>
> To be responsible for world-wide and Chinese Internet societies, hope
we
> all move carefully and responsibly. That's my two-cent point. Hope we
have
> peaceful and justicial Internet World.
>
> Happy Chinese New Year
>
> Chun-Hsin Wu
>
> ----- Original Message -----
> From: "James Seng/Personal" 
> To: ; 
> Sent: Friday, February 08, 2002 12:23 PM
> Subject: Re: [idn] A question...
>
>
> > > It is not ture. I think, maybe you are not familiar how Chinese
> > characters
> > > are used in our daily work.
> >
> > Perhaps you are not be aware I am possibly a Chinese myself too and
I
> > use Chinese in my daily live, both traditional (in Malaysia) and
> > simplified (Singapore).  And I work with many Chinese linguists in
the
> > last 2 years and the many of them are not Chinese.
> >
> > > But the other 5 cases are often written
> > > (not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
> > > preferrd because they are less-strokes.
> >
> > Thanks. Then we have no problem.
> >
> > > What you said are in a restricit environment, like Windows 98, on
> > which
> > > you can not input those characters on some limited IME. However,
> > > Windows 2000 will change the user behavior.
> >
> > By default, TC or SC will be output depending which IME you use. Of
> > course, you *could* manually scroll down the list to get the
characters
> > or you could toggle the input method to do so.
> >
> > The user behavior education about domain names should be that domain
> > names are identifier, not names. They should enter into the computer
> > exactly as they seen it or reference it.
> >
> > Anyhow, you are raising issues which have been debated in the list
> > before, one which the wg is quite well aware of. So unless you have
a
> > TC/SC solution which you willing to contributed to the group, I
consider
> > this discussion closed.
> >
> > And if you do have a TC/SC solution, one which have not be
considered by
> > the group and UTC and IRG, I would definately love to hear your
idea.
> >
> > -James Seng
>
>
>





From owner-idn@ops.ietf.org  Fri Feb  8 20:55: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 UAA29150
	for ; Fri, 8 Feb 2002 20:55:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZMWT-000LQf-00
	for idn-data@psg.com; Fri, 08 Feb 2002 17:41:49 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZMWS-000LQZ-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 17:41:48 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GR8SR500.J19; Sat,
          9 Feb 2002 09:42:41 +0800 
Message-ID: <005d01c1b109$d7315100$4407e29f@deng>
From: "xiang deng" 
To: , "Chun-Hsin Wu" 
Cc: "James Seng/Personal" , ,
        
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb> <20020208142737.A53521@shell.nominum.com>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 09:33:56 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA29150

Dear Ted,

Thanks for your comment.
Discussion make issue more clearly.

we are clear:
1. Current IDNA is a good solution.
2. IDNA ONLY will be detrimental to Chinese Internet Community.
3. IDN WG chairs' express: it's out of scope. But decision maker is not 
    family with Chinese character and never use Chinese character in daily life.
4. Chinese Internet community object IDNA ONLY solution.
5. Unicode haven't finish the equivalent set of Chinese character.

from 1. we get:  It's based on all member's hard work.
from 2. we get:  IDNA ONLY is not enough to solve Chinese character issue.
from 3. we get:  If IDN WG chairs don't consider the detriment, Chinese.
Internet Community have responsibility to solve it for Chinese Internet future 
and Chinese users before the detriment become true.
from 4. we get:  IDNA ONLY solution lost the basis to be widely applicated.
from 5. we get:  If Unicode begin this work, it'll refer to "A complete set of Chinese
Simplified Character", so it is a good beginning of next step.

Best regards
Deng xiang



From owner-idn@ops.ietf.org  Fri Feb  8 21:08: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 VAA29354
	for ; Fri, 8 Feb 2002 21:08:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZMim-000M6M-00
	for idn-data@psg.com; Fri, 08 Feb 2002 17:54:32 -0800
Received: from smtp13.singnet.com.sg ([165.21.6.33])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZMil-000M6G-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 17:54:31 -0800
Received: from jamessonyvaio (bb-203-125-132-44.singnet.com.sg [203.125.132.44])
	by smtp13.singnet.com.sg (8.12.2/8.12.2) with SMTP id g191rjNv028173;
	Sat, 9 Feb 2002 09:53:45 +0800
Message-ID: <092201c1b10c$ab79e1a0$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: "xiang deng" , ,
        "Chun-Hsin Wu" 
Cc: , 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb> <20020208142737.A53521@shell.nominum.com> <005d01c1b109$d7315100$4407e29f@deng>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 09:54:11 +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 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: 7bit

Same old discussion. Response is already in the archive
http://www.imc.org/idn/mail-archive/msg04621.html

-James Seng

----- Original Message -----
From: "xiang deng" 
To: ; "Chun-Hsin Wu" 
Cc: "James Seng/Personal" ; ;

Sent: Saturday, February 09, 2002 9:33 AM
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)


> Dear Ted,
>
> Thanks for your comment.
> Discussion make issue more clearly.
>
> we are clear:
> 1. Current IDNA is a good solution.
> 2. IDNA ONLY will be detrimental to Chinese Internet Community.
> 3. IDN WG chairs' express: it's out of scope. But decision maker is
not
>     family with Chinese character and never use Chinese character in
daily life.
> 4. Chinese Internet community object IDNA ONLY solution.
> 5. Unicode haven't finish the equivalent set of Chinese character.
>
> from 1. we get:  It's based on all member's hard work.
> from 2. we get:  IDNA ONLY is not enough to solve Chinese character
issue.
> from 3. we get:  If IDN WG chairs don't consider the detriment,
Chinese.
> Internet Community have responsibility to solve it for Chinese
Internet future
> and Chinese users before the detriment become true.
> from 4. we get:  IDNA ONLY solution lost the basis to be widely
applicated.
> from 5. we get:  If Unicode begin this work, it'll refer to "A
complete set of Chinese
> Simplified Character", so it is a good beginning of next step.
>
> Best regards
> Deng xiang
>




From owner-idn@ops.ietf.org  Fri Feb  8 21:10: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 VAA29387
	for ; Fri, 8 Feb 2002 21:10:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZMrF-000MmZ-00
	for idn-data@psg.com; Fri, 08 Feb 2002 18:03:17 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZMrE-000MiE-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 18:03:17 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GR8TQY00.M0V; Sat,
          9 Feb 2002 10:04:10 +0800 
Message-ID: <006401c1b10c$d7abf7e0$4407e29f@deng>
From: "xiang deng" 
To: "James Seng/Personal" ,
        "Chun-Hsin Wu" , 
Cc: 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb> <08a601c1b107$b9727ce0$dd00a8c0@jamessonyvaio>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 09:55:25 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA29387

Hi James,

Maybe you not realize that your following input Chinese string 
is  TC/SC mixed: 
the simplified is "只显示BIG5字集"


the traditional is "隻顯示BIG5字集"


your input is "只顯示BIG5字集"


And, do you mean User will set a cofiguration to forbiden himself to use 
his familiar character? I'm also interested in this cofiguration in MS-IME,
If you can find it.

Regards
Deng xiang 

----- Original Message ----- 
From: "James Seng/Personal" 

Btw, do you realise that all W2K Traditional IME have a configuration
called "只顯示BIG5字集" (only show BIG5 characters) which will effectly
elimenate all the confusion you mention here in this mail?

Similar options are available for Simplified IME whereby you can select
between GB2312 and GBK.

-James Seng




From owner-idn@ops.ietf.org  Fri Feb  8 21:16: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 VAA29429
	for ; Fri, 8 Feb 2002 21:16:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZMyk-000NI0-00
	for idn-data@psg.com; Fri, 08 Feb 2002 18:11:02 -0800
Received: from smtp14.singnet.com.sg ([165.21.6.34])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZMyi-000NHr-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 18:11:01 -0800
Received: from jamessonyvaio (bb-165-21-154-215.singnet.com.sg [165.21.154.215])
	by smtp14.singnet.com.sg (8.12.2/8.12.2) with SMTP id g192AiRH013349;
	Sat, 9 Feb 2002 10:10:44 +0800
Message-ID: <095b01c1b10f$0a9cab70$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: "xiang deng" , "Chun-Hsin Wu" ,
        
Cc: 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb> <08a601c1b107$b9727ce0$dd00a8c0@jamessonyvaio> <006401c1b10c$d7abf7e0$4407e29f@deng>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 10:11:10 +0800
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.4910.0300
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> And, do you mean User will set a cofiguration to forbiden himself to
use
> his familiar character? I'm also interested in this cofiguration in
MS-IME,
> If you can find it.

Go to Start/Setting/Control Panel/Regional Options/Input Locale

Select your IME, then IME Setting.

-James Seng




From owner-idn@ops.ietf.org  Fri Feb  8 21:23: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 VAA29474
	for ; Fri, 8 Feb 2002 21:23:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZN5e-000Nkk-00
	for idn-data@psg.com; Fri, 08 Feb 2002 18:18:10 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZN5d-000NkR-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 18:18:10 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GR8UG300.S1I; Sat,
          9 Feb 2002 10:19:15 +0800 
Message-ID: <008f01c1b10e$f2eef690$4407e29f@deng>
From: "xiang deng" 
To: "James Seng/Personal" , ,
        "Chun-Hsin Wu" 
Cc: , 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb> <20020208142737.A53521@shell.nominum.com> <005d01c1b109$d7315100$4407e29f@deng> <092201c1b10c$ab79e1a0$dd00a8c0@jamessonyvaio>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 10:10:30 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA29474

Chair's responsibily is not to create conflict but to collect all different argument
and coordinate to find a possible solution.

what your reference is not fit your position and duty.

Regards
Deng xiang

----- Original Message ----- 
From: "James Seng/Personal" 

> Same old discussion. Response is already in the archive
> http://www.imc.org/idn/mail-archive/msg04621.html
> 
> -James Seng



From owner-idn@ops.ietf.org  Fri Feb  8 21:30: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 VAA29593
	for ; Fri, 8 Feb 2002 21:30:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZNCp-000OHy-00
	for idn-data@psg.com; Fri, 08 Feb 2002 18:25:35 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZNCo-000OHs-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 18:25:35 -0800
Received: from iis.sinica.edu.tw (i2ot0 [140.109.21.152])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g192K5T21770;
	Sat, 9 Feb 2002 10:20:05 +0800 (CST)
Message-ID: <3C6488F5.F7201F06@iis.sinica.edu.tw>
Date: Sat, 09 Feb 2002 10:27:01 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Paul Hoffman / IMC 
CC: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr, mclaughlin@pobox.com,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, alanysho@hkdnr.net.hk,
        christine.tsang@hkdnr.net.hk, fred@cisco.com, harald@alvestrand.no,
        hlqian@cnnic.net.cn, htk@eecs.harvard.edu, iab@isi.edu, iesg@ietf.org,
        jasonho@umac.mo, jet-member@nic.ad.jp, jseng@pobox.org.sg,
        klensin@jck.com, lynn@icann.org, mao@cnnic.net.cn, mkatoh@mkatoh.net,
        mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com,
        paf@cisco.com, sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr,
        vcerf@mci.net, yktham@umac.mo
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020206075920.036ed5b0@127.0.0.1>
	 <3C61F486.FFD1D701@iis.sinica.edu.tw> 
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Paul Hoffman / IMC gJG

> At 11:29 AM +0800 2/7/02, hoho wrote:
> >1. If the working
> >    group chooses to use Unicode as basis, then it becomes a partial
> >solution
> >    to the "global" IDN problem because of this side-effect.
>
> This is exactly wrong. The decision to use the ISO/IEC 10646
> (Unicode) character repertoire was made to make IDN a global
> solution. Maybe I missed it, but what other solution has been
> proposed that is more global than using 10646? We already discussed
> this in detail on the mailing list many times, and no one came up
> with anything more global.

My reading is that the current IDN is the best among those inferior solutions
although it is not perfect neither. Why don't you just admit that it does
produce
side-effects on Chinese? But, there is a chance for us not to hurt any part of
the global community. People cried for that for more than half a year, why you
guys still shut your ears pretending that this is noting?

>
> >2. We do not want to delay your process either. Please refer to the
> >draft
> >    "Phased Implementation of Internationalized Domain Names in
> >Applications"
> >    for more details.
>
> The "phased implementation" draft is sure to cause a great deal more delay.
>
> - The draft has serious technical errors: the list in section 1 does
> not even vaguely match the list given in Appendix B.

No, we do not suggest to delay the whole thing. We know our limitation.  As for

technical errors in the draft, we are happy to make necessary modifications.

>
> - As the draft admits, adopting the draft would have a very serious
> negative consequence on Japan and Korea. It is very insulting to say
> to people of other countries "because we have problems we cannot
> solve with our script, you will be reduced to using phonetic spelling
> of your names until we come up with a solution, even though we have
> failed numerous times in the past trying to do this". Discussing the
> political ramifications of this consequence could take years.

Unfortunately, Unicode Consortium chose to unify the three languages
together. Well, it seems that we are facing a dilemma here. Either we choose
to damage Chinese Internet community and to make Japanese and Korean
happy, or we choose to make them all wait without damaging anyone. When
you say that, are you sure that Korean and Japanese feel happy for damaging
Chinese people? This is not the usual way how peace are maintained, isn't it?

-- Janming Ho, PhD
Deputy Direction
Institute of Information Science
Academia Sinica




From owner-idn@ops.ietf.org  Fri Feb  8 21:45: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 VAA00663
	for ; Fri, 8 Feb 2002 21:45:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZNO3-000P55-00
	for idn-data@psg.com; Fri, 08 Feb 2002 18:37:11 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZNO2-000P4w-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 18:37:10 -0800
Received: from smtp1.sybase.com (sybgate [10.22.97.84])
	by inergen.sybase.com  with ESMTP id SAA19190
	for ; Fri, 8 Feb 2002 18:36:58 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id SAA13351
	for ; Fri, 8 Feb 2002 18:37:09 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id SAA13304;
	Fri, 8 Feb 2002 18:36:54 -0800 (PST)
Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140])
	by olympus.sybase.com (8.8.8+Sun/8.8.8) with ESMTP id SAA05566;
	Fri, 8 Feb 2002 18:35:53 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id SAA02130;
	Fri, 8 Feb 2002 18:36:51 -0800 (PST)
Date: Fri, 8 Feb 2002 18:36:51 -0800 (PST)
From: Kenneth Whistler 
Message-Id: <200202090236.SAA02130@birdie.sybase.com>
To: deng@cnnic.net.cn
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Cc: idn@ops.ietf.org
X-Sun-Charset: ISO-8859-1
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Mr. Deng,

> Hi James,
> 
> Maybe you not realize that your following input Chinese string 
> is  TC/SC mixed: 
> the simplified is "只显示BIG5字集"
> 
> 
> the traditional is "隻顯示BIG5字集"
> 
> 
> your input is "只顯示BIG5字集"
> 

And perhaps *you* do not realize that U+53EA zhi3 is *also* a
traditional character, and that it contrasts in proper usage
with U+96BB zhi3, and that a normal *traditional* representation
of zhi3xian4 "Only show..." would be U+53EA U+986F.

U+53EA is also one of the 1-n simplifications that screw up the
SC/TC mapping in any case. In PRC orthography, it is not only the
simplification of U+96BB, but also the simplification for U+7947
(and U+7957), which is the proper adverbial particle for "only, merely".

> And, do you mean User will set a cofiguration to forbiden himself to use 
> his familiar character?

U+53EA *is* in Big-5. 0xA575. Do your homework.

This kind of intentionally misleading example and campaign of
ad hominem argumentation directed at the chair is getting
truly tiresome.

--Ken




From owner-idn@ops.ietf.org  Fri Feb  8 22:26: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 WAA01207
	for ; Fri, 8 Feb 2002 22:26:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZO0A-0001kD-00
	for idn-data@psg.com; Fri, 08 Feb 2002 19:16:34 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZO09-0001k6-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 19:16:33 -0800
Received: from iis.sinica.edu.tw (i2ot0 [140.109.21.152])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g193AoT08948;
	Sat, 9 Feb 2002 11:10:51 +0800 (CST)
Message-ID: <3C6494D9.988C9CBA@iis.sinica.edu.tw>
Date: Sat, 09 Feb 2002 11:17:46 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Paul Hoffman / IMC 
CC: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, fred@cisco.com,
        harald@alvestrand.no, htk@eecs.harvard.edu, iab@isi.edu, iesg@ietf.org,
        jet-member@nic.ad.jp, lynn@icann.org, mkatoh@mkatoh.net,
        mkatoh@wdc.fujitsu.com, mouhamet@next.sn, narten@us.ibm.com,
        nordmark@eng.sun.com, paf@cisco.com, sharil@cmc.gov.my,
        shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk,
        christine.tsang@hkdnr.net.hk, hlqian@cnnic.net.cn,
        huangk@alum.sinica.edu, jasonho@umac.mo, yktham@umac.mo,
        "
	=?big5?B?q9ip+iCm8w==?=" 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>
	 <83129960.1012820475@localhost> 
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Paul,

Paul Hoffman / IMC wroteG

> The message from CDNC says that the Traditional-Simplified problem
> for Chinese users cannot be solved by registration policy. This is
> not true, and many of the CDNC members who have come to IETF meetings
> know that.

Interesting question. As we could also noticed,  functions of nameprep,
mapping,
prohibit, and normalization can all be performed by registration policy.
So, what's
the point of asking this question?

Anyway, from our point of view, nameprep mechanism helps to make sure
that all
international registries  follow a global set of rules and it becomes the
core set of
registration policy.

Since the WG insists on a client solution based on Unicode, without on
such technical
solution, we have no way to depend on the courtesy of internationalized
companies
to make registration policies being friendly to language communities
including Chinese
who will be most seriously damaged by the decision of the WG. It would be
a pity
if we could not prevent greedy business from dumping defective domain
name products
into Chinese community. We definitely are positive for your efforts in
bring up a solution
that solves DN problem for many languages. But, please do not force the
Chinese
community to be the victim of the side-effect.

> Of course, CDNC members would like to maximize their
> financial gain in registration, but the concern of the IETF is always
> towards helping users. There is a huge different between "cannot be
> solved" and "it will cost a small number of organizations a lot of
> money".

This is also interesting. As far as I know, TWNIC has their social
responsibily
in our country. There major concern for TWNIC to work with IDN WG is
consumer
protection. The reason why they work on TC/SC, is that we all aware the
lack
of an international standard on Han variants which we could use to
convince the
WG to pay attention. Thus TC/SC becomes the best hope because it's
something
exists for more than 50 years. If the working group could adopt it, then
at least this is
something for all registries to restrict their name space a little bit
and not too make
too much trouble to Chinese community. It's a very humble wish, but
unfortunately, was
rejected by the WG. On the other hand, I can assure you that there is no
way for TWNIC
to make a registration policy without taking the maximum set of Han
variants into account.
As a non-profit organization, consumer protection is beyond the goal of
making a big
profit. Furthermore, dometistic consumer protection groups will not allow
that to
happen either.

I am going back to my family in another city for Chinese New Year now.
I'll respond to
the rest of your questions as soon as possible.

By the way, I have trouble sending a message with a long list of
recipients. Could you
cut your list shorter please? I guess most people on your list is already
on IDN list.
Thanks,

-- Janming Ho, PhD
Deputy Director
Institute of Information Science
Academia Sinica





From owner-idn@ops.ietf.org  Fri Feb  8 22:33: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 WAA02187
	for ; Fri, 8 Feb 2002 22:33:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZO50-00029K-00
	for idn-data@psg.com; Fri, 08 Feb 2002 19:21:34 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZO4y-00029D-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 19:21:33 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GR8XDF00.U1M; Sat,
          9 Feb 2002 11:22:27 +0800 
Message-ID: <001401c1b117$c7570e60$4407e29f@deng>
From: "xiang deng" 
To: "Kenneth Whistler" 
Cc: 
References: <200202090236.SAA02130@birdie.sybase.com>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 11:13:40 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA02187

Mr. Kenneth,

Chinese culuture is so profound,no one can enumerate
all case, neither you nor me. 

The U+53EA is one case of the 1:(n+1) simplifications.
It is simplified character.

All variants of U+53EA are include in GBK GB13000 GB18030
And U+7947 is a TongJiaZhi of U+53EA.

If you decide one character is simplified of traditional 
depend on whether it is been included in BIG5 or GB, you 
don't understand the TC/SC variant issue.

And yes, it's tiresome to keep deny a simple fact.
There are objecting argument, I respect it.
But, I'm not appreciate the way of deny fact.

Regards
Deng xiang

----- Original Message ----- 
From: "Kenneth Whistler" 

> Mr. Deng,
> 
> > Hi James,
> > 
> > Maybe you not realize that your following input Chinese string 
> > is  TC/SC mixed: 
> > the simplified is "只显示BIG5字集"
> > 
> > 
> > the traditional is "隻顯示BIG5字集"
> > 
> > 
> > your input is "只顯示BIG5字集"
> > 
> 
> And perhaps *you* do not realize that U+53EA zhi3 is *also* a
> traditional character, and that it contrasts in proper usage
> with U+96BB zhi3, and that a normal *traditional* representation
> of zhi3xian4 "Only show..." would be U+53EA U+986F.
> 
> U+53EA is also one of the 1-n simplifications that screw up the
> SC/TC mapping in any case. In PRC orthography, it is not only the
> simplification of U+96BB, but also the simplification for U+7947
> (and U+7957), which is the proper adverbial particle for "only, merely".
> 
> > And, do you mean User will set a cofiguration to forbiden himself to use 
> > his familiar character?
> 
> U+53EA *is* in Big-5. 0xA575. Do your homework.
> 
> This kind of intentionally misleading example and campaign of
> ad hominem argumentation directed at the chair is getting
> truly tiresome.
> 
> --Ken
> 
> 


From owner-idn@ops.ietf.org  Fri Feb  8 22:40: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 WAA02243
	for ; Fri, 8 Feb 2002 22:40:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZOIz-00038C-00
	for idn-data@psg.com; Fri, 08 Feb 2002 19:36:01 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZOIy-000385-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 19:36:00 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16ZOIo-0000YE-00; Sat, 09 Feb 2002 03:35:50 +0000
Date: Fri, 08 Feb 2002 22:35:33 -0500
From: John C Klensin 
To: xiang deng 
cc: "James Seng/Personal" , idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <3052129.1013207733@localhost>
In-Reply-To: <008f01c1b10e$f2eef690$4407e29f@deng>
References:  <008f01c1b10e$f2eef690$4407e29f@deng>
X-Mailer: Mulberry/2.2.0b1 (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, 09 February, 2002 10:10 +0800 xiang deng
 wrote:

> Chair's responsibily is not to create conflict but to collect
> all different argument and coordinate to find a possible
> solution.

Under normal IETF procedures, which apply to this Working Group
as well, the Chair's responsibility, at this stage in the
process, is to move work along.  That includes, quite
explicitly, 

	* Discouraging the further discussion of topics on which
	the WG has already reached a conclusion.
	
	* Discouraging discussion of problems that are either
	out of the WG's scope, or for which realistic solutions
	(e.g., solutions that deal with all appropriate cases)
	have not been proposed.

James (and Marc) have, if anything, been more tolerant of
extended discussions of topics the WG can't fix, or has already
reached consensus that it won't try to fix, than is normal in
the IETF.

Since I have started on this, I am very concerned about the very
real and serious problems with TC<->SC.  I am also very
concerned about problems with look-alike characters in
alphabetic character sets.  I am also very concerned about the
implications of non-language characters in Unicode that, from my
point of view, don't belong in the DNS (however coded).  

I have raised those issues with the WG, discovered that the WG
isn't interested in the problems, and gone on to worry about
contexts in which those problems _can_ be solved.   That does
not make me worry less, nor does it mean that I think the
problems are unimportant.  But, until and unless I think I have
new arguments or evidence, I don't bring them up again, and I
would _expect_ James or Marc to tell me that I'm out of order if
I did.  I also don't try to convince the WG that those topics
are important by getting many people --who have not been
participating in the WG's work-- to send identical notes
complaining, nor do I circulate notes to other groups in the
hope that they will somehow overrule the WG.  I avoid doing
those things for two reasons: they are considered in very bad
taste in the IETF and they never convince anyone; instead, they
tend to irritate people enough that they stop listening.

What is strange, to me, about this discussion is that there is a
way to delay CDN deployment without impacting Korean or
Japanese.  It is fairly simple, and does not require that the
IDN WG agree. And I had assumed it would be obvious to everyone.
Specifically, the four NICs simply refuse to register such
names.  You try to convince Singapore and other countries with
large Chinese-speaking populations to join them in that
prohibition.  You expand on Erin's document, some of Prof
Tseng's notes, and other comments and examples which have been
introduced here to provide other registries cautions about the
problems they could cause by registering such names.  And you
try to convince ICANN to prohibit those names in gTLDs.   From
the perspective of this WG, that is a policy move, made in
policy forums.  The fact that the WG provides a _mechanism_ for
encoding CDNs does not imply that any registry need _permit_
CDNs.  And it seems to me that, at this late date and given the
overlapping Japanese and Korean issues, that may be your most
efficient way forward on this particular problem.

regards,
     john




From owner-idn@ops.ietf.org  Fri Feb  8 23:09: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 XAA02590
	for ; Fri, 8 Feb 2002 23:09:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZOkE-0004wg-00
	for idn-data@psg.com; Fri, 08 Feb 2002 20:04:10 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZOkA-0004w0-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 20:04:06 -0800
Received: from jamessonyvaio (bb-165-21-154-215.singnet.com.sg [165.21.154.215])
	by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g19445ZW026228
	for ; Sat, 9 Feb 2002 12:04:05 +0800
Message-ID: <021701c1b11e$e0034350$1001000a@jamessonyvaio>
From: "James Seng/Personal" 
To: 
References: <200202090236.SAA02130@birdie.sybase.com> <001401c1b117$c7570e60$4407e29f@deng>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 12:04:30 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
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

Originally send the following as a private mail to you but heck, lets
open this "profound" topic.

U+53EA is both a TC and a SC, depending how it is use, with two tone,
"zhi1" or "zhi3".

OTOH, U+986F is a TC only character which have only one tone "zhi1".

When you use U+53EA in "1 little bird" in chinese, "һֻС" (SC) "һb
СB" (TC) then U+53EA ("zhi1") is a SC of U+96BB ("zhi1").

In the case when you use to U+53EA to mean 'Only' ("zhi3"), then using
U+96BB ("zhi1") is inappropriate.

In my case, "ֻ@ʾBIG5ּ" is a valid Traditional Chinese sentence.

This is yet another example why TC-SC is not just a simple 1-to-1
mapping.

ps: If chinese is "so profound" that "no one (human) can enumarate",
then should we expect a computer (or DNS) to be able to do so?

-James Seng

----- Original Message -----
From: "xiang deng" 
To: "Kenneth Whistler" 
Cc: 
Sent: Saturday, February 09, 2002 11:13 AM
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)


> Mr. Kenneth,
>
> Chinese culuture is so profound,no one can enumerate
> all case, neither you nor me.
>
> The U+53EA is one case of the 1:(n+1) simplifications.
> It is simplified character.
>
> All variants of U+53EA are include in GBK GB13000 GB18030
> And U+7947 is a TongJiaZhi of U+53EA.
>
> If you decide one character is simplified of traditional
> depend on whether it is been included in BIG5 or GB, you
> don't understand the TC/SC variant issue.
>
> And yes, it's tiresome to keep deny a simple fact.
> There are objecting argument, I respect it.
> But, I'm not appreciate the way of deny fact.
>
> Regards
> Deng xiang
>
> ----- Original Message -----
> From: "Kenneth Whistler" 
>
> > Mr. Deng,
> >
> > > Hi James,
> > >
> > > Maybe you not realize that your following input Chinese string
> > > is  TC/SC mixed:
> > > the simplified is "只显示BIG5字集"
> > > 
> > >
> > > the traditional is "隻顯示BIG5字集"
> > > 
> > >
> > > your input is "只顯示BIG5字集"
> > > 
> >
> > And perhaps *you* do not realize that U+53EA zhi3 is *also* a
> > traditional character, and that it contrasts in proper usage
> > with U+96BB zhi3, and that a normal *traditional* representation
> > of zhi3xian4 "Only show..." would be U+53EA U+986F.
> >
> > U+53EA is also one of the 1-n simplifications that screw up the
> > SC/TC mapping in any case. In PRC orthography, it is not only the
> > simplification of U+96BB, but also the simplification for U+7947
> > (and U+7957), which is the proper adverbial particle for "only,
merely".
> >
> > > And, do you mean User will set a cofiguration to forbiden himself
to use
> > > his familiar character?
> >
> > U+53EA *is* in Big-5. 0xA575. Do your homework.
> >
> > This kind of intentionally misleading example and campaign of
> > ad hominem argumentation directed at the chair is getting
> > truly tiresome.
> >
> > --Ken
> >
> >
>




From owner-idn@ops.ietf.org  Fri Feb  8 23:10: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 XAA02613
	for ; Fri, 8 Feb 2002 23:10:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZOld-00054D-00
	for idn-data@psg.com; Fri, 08 Feb 2002 20:05:37 -0800
Received: from [211.254.82.194] (helo=spsoft.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZOlc-000544-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 20:05:36 -0800
Received: (from newcat@localhost)
	by spsoft.co.kr (8.10.0/8.10.0) id g1945Wv00524;
	Sat, 9 Feb 2002 13:05:32 +0900
Date: Sat, 9 Feb 2002 13:05:32 +0900
From: YangWoo Ko 
To: idn@ops.ietf.org, jet-member@nic.ad.jp
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Message-ID: <20020209130532.E32138@spsoft.co.kr>
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1> <83129960.1012820475@localhost>  <3C6494D9.988C9CBA@iis.sinica.edu.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3C6494D9.988C9CBA@iis.sinica.edu.tw>
User-Agent: Mutt/1.3.23i
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

[I removed most of personal e-mail addresses to make header short.]

On Sat, Feb 09, 2002 at 11:17:46AM +0800, hoho wrote:
> Dear Paul,
> 
> Paul Hoffman / IMC wrote
> 
> > The message from CDNC says that the Traditional-Simplified problem
> > for Chinese users cannot be solved by registration policy. This is
> > not true, and many of the CDNC members who have come to IETF meetings
> > know that.
> 
> Interesting question. As we could also noticed,  functions of nameprep,
> mapping, prohibit, and normalization can all be performed by registration 
> policy. So, what's the point of asking this question?

Dear Paul Hoffman, Janming Ho and others,

Yes. All NAMEPREP things can be handled by registration policy. Even, it
seems easier and more flexible to coordinate registration policies among
registries than just waiting for major software vendors to implement both
NAMEPREP and all localization improvements. If we took future upgrades of
Unicode and their impacts to implementation, I would rather forget whole
NAMEPREP.

For example, in Korea, we are almost finalizing a RFC-KR (RFC for .kr) 
which restricts scope of code points used in hostnames to get around 
inadequacy of current NFKC for Hangeul. I know this method is of no help
for TC/SC issue.

What I am trying to tell is we should consider again "why we began to
come up with NAMEPREP". If current version of NAMEPREP could not satisfy
its goal "in order to increase the likelihood that name input and name 
comparison work in ways that make sense for typical users throughout the 
world" (quote from NAMEPREP-06), this document could not go beyond WG
last call.

Happy New Lunar Calendar Year !

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Sat Feb  9 00:57: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 AAA04058
	for ; Sat, 9 Feb 2002 00:57:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZQNl-000Blg-00
	for idn-data@psg.com; Fri, 08 Feb 2002 21:49:05 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZQNk-000BlV-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 21:49:04 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net for ;
          Fri, 8 Feb 2002 22:04:44 -0800
Message-ID: <005e01c1b12e$e7a44900$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: 
References:  <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 00:59:13 -0500
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

> What is strange, to me, about this discussion is that there is a
> way to delay CDN deployment without impacting Korean or
> Japanese.  It is fairly simple, and does not require that the
> IDN WG agree. And I had assumed it would be obvious to everyone.
> Specifically, the four NICs simply refuse to register such
> names.  You try to convince Singapore and other countries with
> large Chinese-speaking populations to join them in that
> prohibition.  You expand on Erin's document, some of Prof
> Tseng's notes, and other comments and examples which have been
> introduced here to provide other registries cautions about the
> problems they could cause by registering such names.  And you
> try to convince ICANN to prohibit those names in gTLDs.   From
> the perspective of this WG, that is a policy move, made in
> policy forums.  The fact that the WG provides a _mechanism_ for
> encoding CDNs does not imply that any registry need _permit_
> CDNs.  And it seems to me that, at this late date and given the
> overlapping Japanese and Korean issues, that may be your most
> efficient way forward on this particular problem.
>
> regards,
>      john
>
>

After reading all the email exchanges lately concerning the TC<->SC
issue, I must admit that this part of John's email is the most
constructive.  It reminds of the Chinese saying:

塞翁失马，焉知非福

Which is literally translated as:
"A man who lost his horse is neither fortune nor misfortune."

or roughly translated to mean:
"What ever will be... will be."

Thanks,
Ben













From owner-idn@ops.ietf.org  Sat Feb  9 01: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 BAA04173
	for ; Sat, 9 Feb 2002 01:12:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZQfG-000Cyp-00
	for idn-data@psg.com; Fri, 08 Feb 2002 22:07:10 -0800
Received: from imo-r07.mx.aol.com ([152.163.225.103])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZQfF-000Cyc-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 22:07:09 -0800
Received: from DougEwell2@cs.com
	by imo-r07.mx.aol.com (mail_out_v32.5.) id i.d8.1342adcc (16488);
	Sat, 9 Feb 2002 01:07:04 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: 
Date: Sat, 9 Feb 2002 01:07:04 EST
Subject: Re: [idn] A question...
To: idn@ops.ietf.org
CC: rosenne@qsm.co.il, jseng@pobox.org.sg, jw-lin@yahoo.com.tw
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-08 12:15:08 Pacific Standard Time, 
rosenne@qsm.co.il writes:

>>> VERBATIM means "word for word". LITERATIM is "letter by letter". This 
>>> is precisely the essence of the problem - you hear a domain name, and 
>>> spell it exactly as you hear it, and it should be found.
>>
>> www.color.com and www.colour.com are not ever going to match.
>
> So we don't mean VERBATIM.

Right, OK, I made a mistake.  So let's try again and see if I can avoid 
obscuring the point this time:

"The same, exact thing will happen with Han logographs.  If # and & are TC 
and SC characters (respectively) that have the same meaning, and the user 
types # when he should have typed & (or vice versa), under the proposed IDN 
system the name will not match.  The user will get a 404, mutter "aw, 
shucks," and type it again, LITERATIM, and the page will appear.  And the 
user will learn that it is important to type the EXACT characters that appear 
on the business card, or billboard, or wherever the name came from."

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Sat Feb  9 01:24: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 BAA04225
	for ; Sat, 9 Feb 2002 01:24:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZQrC-000Dpe-00
	for idn-data@psg.com; Fri, 08 Feb 2002 22:19:30 -0800
Received: from smtp14.singnet.com.sg ([165.21.6.34])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZQrB-000DpY-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 22:19:29 -0800
Received: from jamessonyvaio (bb-165-21-154-215.singnet.com.sg [165.21.154.215])
	by smtp14.singnet.com.sg (8.12.2/8.12.2) with SMTP id g196JSRH021400
	for ; Sat, 9 Feb 2002 14:19:28 +0800
Message-ID: <048001c1b131$c984ec10$1001000a@jamessonyvaio>
From: "James Seng/Personal" 
To: 
Subject: [idn] 200 protest mails
Date: Sat, 9 Feb 2002 14:19:53 +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 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: 7bit

yoohoo, we just reach a total of 200 protest mails (many are dups tho)!

*cheers* james




From owner-idn@ops.ietf.org  Sat Feb  9 02:03: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 CAA09307
	for ; Sat, 9 Feb 2002 02:03:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZRT7-000GQK-00
	for idn-data@psg.com; Fri, 08 Feb 2002 22:58:41 -0800
Received: from mx-out.daemonmail.net ([209.75.5.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZRT7-000GQE-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 22:58:41 -0800
Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1])
	by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id WAA45468;
	Fri, 8 Feb 2002 22:58:38 -0800 (PST)
	(envelope-from rosenne@qsm.co.il)
Received: from qsm3 (qsm3 [212.150.108.98])
	by mail.qsm.co.il with ESMTP id soB0OtH2
	Fri, 08 Feb 2002 22:58:32 -0700 (PST)
From: "Jonathan Rosenne" 
To: , 
Cc: , 
Subject: RE: [idn] A question...
Date: Sat, 9 Feb 2002 08:58:09 +0200
Message-ID: <000801c1b137$2503acc0$eb0110ac@qsm3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: 
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

How about the telephone?

Jony

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] 
> On Behalf Of DougEwell2@cs.com
> Sent: Saturday, February 09, 2002 8:07 AM
> To: idn@ops.ietf.org
> Cc: rosenne@qsm.co.il; jseng@pobox.org.sg; jw-lin@yahoo.com.tw
> Subject: Re: [idn] A question...
> 
> 
> In a message dated 2002-02-08 12:15:08 Pacific Standard Time, 
> rosenne@qsm.co.il writes:
> 
> >>> VERBATIM means "word for word". LITERATIM is "letter by letter". 
> >>> This
> >>> is precisely the essence of the problem - you hear a 
> domain name, and 
> >>> spell it exactly as you hear it, and it should be found.
> >>
> >> www.color.com and www.colour.com are not ever going to match.
> >
> > So we don't mean VERBATIM.
> 
> Right, OK, I made a mistake.  So let's try again and see if I 
> can avoid 
> obscuring the point this time:
> 
> "The same, exact thing will happen with Han logographs.  If # 
> and & are TC 
> and SC characters (respectively) that have the same meaning, 
> and the user 
> types # when he should have typed & (or vice versa), under 
> the proposed IDN 
> system the name will not match.  The user will get a 404, mutter "aw, 
> shucks," and type it again, LITERATIM, and the page will 
> appear.  And the 
> user will learn that it is important to type the EXACT 
> characters that appear 
> on the business card, or billboard, or wherever the name came from."
> 
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)
> 
> 
> 




From owner-idn@ops.ietf.org  Sat Feb  9 02:04: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 CAA10530
	for ; Sat, 9 Feb 2002 02:04:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZRQj-000GGL-00
	for idn-data@psg.com; Fri, 08 Feb 2002 22:56:13 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZRQi-000GFr-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 22:56:12 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g196tuU21576
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Sat, 9 Feb 2002 14:55:57 +0800 (CST)
Message-ID: <008101c1b136$73fe98e0$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= 
To: "James Seng/Personal" , 
References: <200202090236.SAA02130@birdie.sybase.com> <001401c1b117$c7570e60$4407e29f@deng> <021701c1b11e$e0034350$1001000a@jamessonyvaio>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 14:53:15 +0800
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 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

Hi All:
        The problems of TC/SC related to IDN is only the term --Does we need
comparison of identifier, character by character without to care it is TC or
SC ?
In the Total Listing Table of  Simplified  Characters (簡化字總表) ,  it
define this one way  mapping .
        (U+53eA 只) <-- (U+96bb 隻)
        (U+53eA 只) <-- (U+8879 衹)
In a old book before 1949 ,  you can find  " 衹要..." , "一隻..." are the
traditional using of these characters. If  you want to do reverse mapping
from SC to TC ,  these 1-n pair can be very easy  to do it ,  If  you can
accept that table is one way mapping .
        (U+53ea 只)  --> (U+53ea 只)
In Taiwan ,  you write "只要..." , "一只...." ,  we all know it .  Only a
Chinese Literature Expert will argue  "一只碗" , "一隻鳥"  are different ,
it is used in literature not a simple identifier od domain name.
       If  (U+53ea, U+96bb, U+8879) are not accepted as equivalent set ,
why not remove it  from the table ?  But as an identifier ,  comparing of
these 3 characters as the same is easy and simple .
       Because there are Japan, Korean are all use these Han characters ,
this example (U+53eA 只)  is more complex, you can find UNICODE 3.1.1
Unihan.txt have all the related variant listed.  From Unihan.txt , it
records each character as following:
       (U+8879)  is the traditional variant of (U+53EA)
       (U+6B62) (U+7957) (U+96BB) are all the variant of (U+53EA)
       (U+53EA) is the simplified variant of (U+8879)

To get an identical variant equivalent  table  may be need  more time in UTC
to do it , but   in  IDN WG we need a presentation method/scheme to help DNS
server can do comparison without to care the variant .
        Whether the variant equivalent table is global or local ,  we all
need
1. An interface or scheme that can  pass the equivalent result and its
related information to IDNA, the current draft need to clarify it.
2. A  scheme or encoding mechanism to treat the equivalent result and
related information to convert them to ACE string and that string can do
comparison without to care variants in LDH-DNS server.
3. To recognize current last call drafts are not enough to solve these
variant problems  related to  IDN identifier. IDN WG must be very careful to
announce the result to avoid the  irreversible deployment of  CJK  IDN.
4. CJK area should find a way/stage to do CJK IDN registration  to reduce
the ambiguity of  variant characters and try to find a way to get a/some
final CJK variant equivalent table(s) to be used in identifier of domain
name.

L.M.Tseng
----- Original Message -----
From: "James Seng/Personal" 

> Originally send the following as a private mail to you but heck, lets
> open this "profound" topic.
>
> U+53EA is both a TC and a SC, depending how it is use, with two tone,
> "zhi1" or "zhi3".
>
> OTOH, U+986F is a TC only character which have only one tone "zhi1".
>
> When you use U+53EA in "1 little bird" in chinese, "一只小鸟" (SC) "一隻
> 小鳥" (TC) then U+53EA ("zhi1") is a SC of U+96BB ("zhi1").
>
> In the case when you use to U+53EA to mean 'Only' ("zhi3"), then using
> U+96BB ("zhi1") is inappropriate.
>
> In my case, "只顯示BIG5字集" is a valid Traditional Chinese sentence.
>
> This is yet another example why TC-SC is not just a simple 1-to-1
> mapping.
>
> ps: If chinese is "so profound" that "no one (human) can enumarate",
> then should we expect a computer (or DNS) to be able to do so?
>
> -James Seng
>
> ----- Original Message -----
> From: "xiang deng" 
> To: "Kenneth Whistler" 
> Cc: 
> Sent: Saturday, February 09, 2002 11:13 AM
> Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
>
>
> > Mr. Kenneth,
> >
> > Chinese culuture is so profound,no one can enumerate
> > all case, neither you nor me.
> >
> > The U+53EA is one case of the 1:(n+1) simplifications.
> > It is simplified character.
> >
> > All variants of U+53EA are include in GBK GB13000 GB18030
> > And U+7947 is a TongJiaZhi of U+53EA.
> >
> > If you decide one character is simplified of traditional
> > depend on whether it is been included in BIG5 or GB, you
> > don't understand the TC/SC variant issue.
> >
> > And yes, it's tiresome to keep deny a simple fact.
> > There are objecting argument, I respect it.
> > But, I'm not appreciate the way of deny fact.
> >
> > Regards
> > Deng xiang
> >
> > ----- Original Message -----
> > From: "Kenneth Whistler" 
> >
> > > Mr. Deng,
> > >
> > > > Hi James,
> > > >
> > > > Maybe you not realize that your following input Chinese string
> > > > is  TC/SC mixed:
> > > > the simplified is "鍙樉绀築IG5瀛楅泦"
> > > > 
> > > >
> > > > the traditional is "闅婚’绀築IG5瀛楅泦"
> > > > 
> > > >
> > > > your input is "鍙’绀築IG5瀛楅泦"
> > > > 
> > >
> > > And perhaps *you* do not realize that U+53EA zhi3 is *also* a
> > > traditional character, and that it contrasts in proper usage
> > > with U+96BB zhi3, and that a normal *traditional* representation
> > > of zhi3xian4 "Only show..." would be U+53EA U+986F.
> > >
> > > U+53EA is also one of the 1-n simplifications that screw up the
> > > SC/TC mapping in any case. In PRC orthography, it is not only the
> > > simplification of U+96BB, but also the simplification for U+7947
> > > (and U+7957), which is the proper adverbial particle for "only,
> merely".
> > >
> > > > And, do you mean User will set a cofiguration to forbiden himself
> to use
> > > > his familiar character?
> > >
> > > U+53EA *is* in Big-5. 0xA575. Do your homework.
> > >
> > > This kind of intentionally misleading example and campaign of
> > > ad hominem argumentation directed at the chair is getting
> > > truly tiresome.
> > >
> > > --Ken
> > >
> > >
> >
>
>




From owner-idn@ops.ietf.org  Sat Feb  9 02:18: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 CAA12398
	for ; Sat, 9 Feb 2002 02:18:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZRhZ-000HQ2-00
	for idn-data@psg.com; Fri, 08 Feb 2002 23:13:37 -0800
Received: from mail.fm-net.ne.jp ([211.15.66.133])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZRhY-000HPw-00
	for idn@ops.ietf.org; Fri, 08 Feb 2002 23:13:36 -0800
Received: from bruce (bruce.fm-net.ne.jp [211.15.66.163])
	by mail.fm-net.ne.jp (8.9.3/8.8.7) with SMTP id QAA16879;
	Sat, 9 Feb 2002 16:13:27 +0900
Message-ID: <018301c1b139$2a716010$6503a8c0@bruce>
From: "Bruce Thomson" 
To: "Jonathan Rosenne" ,
        "IETF idn working group" 
References: <000801c1b137$2503acc0$eb0110ac@qsm3>
Subject: Re: [idn] A question...
Date: Sat, 9 Feb 2002 16:12:42 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
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

Many people are in the situation where they have to communicate
a string of CJK characters over the telephone, and they have to
get the exact characters (for example in someone's name) and
not just something that sounds and means something similar. It's
a pain, but people deal with it by giving the sound, the meaning,
and and extra details about the structure of the character that may
be needed to pin down the exact glyph. 


> How about the telephone?
> 
> Jony
> 
> > -----Original Message-----
> > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] 
> > On Behalf Of DougEwell2@cs.com
> > Sent: Saturday, February 09, 2002 8:07 AM
> > To: idn@ops.ietf.org
> > Cc: rosenne@qsm.co.il; jseng@pobox.org.sg; jw-lin@yahoo.com.tw
> > Subject: Re: [idn] A question...
> > 
> > 
> > In a message dated 2002-02-08 12:15:08 Pacific Standard Time, 
> > rosenne@qsm.co.il writes:
> > 
> > >>> VERBATIM means "word for word". LITERATIM is "letter by letter". 
> > >>> This
> > >>> is precisely the essence of the problem - you hear a 
> > domain name, and 
> > >>> spell it exactly as you hear it, and it should be found.
> > >>
> > >> www.color.com and www.colour.com are not ever going to match.
> > >
> > > So we don't mean VERBATIM.
> > 
> > Right, OK, I made a mistake.  So let's try again and see if I 
> > can avoid 
> > obscuring the point this time:
> > 
> > "The same, exact thing will happen with Han logographs.  If # 
> > and & are TC 
> > and SC characters (respectively) that have the same meaning, 
> > and the user 
> > types # when he should have typed & (or vice versa), under 
> > the proposed IDN 
> > system the name will not match.  The user will get a 404, mutter "aw, 
> > shucks," and type it again, LITERATIM, and the page will 
> > appear.  And the 
> > user will learn that it is important to type the EXACT 
> > characters that appear 
> > on the business card, or billboard, or wherever the name came from."
> > 
> > -Doug Ewell
> >  Fullerton, California
> >  (address will soon change to dewell at adelphia dot net)
> > 
> > 
> > 
> 
> 
> 




From owner-idn@ops.ietf.org  Sat Feb  9 03:28: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 DAA13035
	for ; Sat, 9 Feb 2002 03:28:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZShU-000LdG-00
	for idn-data@psg.com; Sat, 09 Feb 2002 00:17:36 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZShT-000Lck-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 00:17:35 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g198HHU29820
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Sat, 9 Feb 2002 16:17:18 +0800 (CST)
Message-ID: <00ba01c1b141$d15e66e0$4007738c@q.j.tw>
From: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= 
To: "Kenneth Whistler" , 
Cc: 
References: <200202090028.QAA02105@birdie.sybase.com>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 16:14:36 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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


----- Original Message -----
From: "Kenneth Whistler" 
To: 
Cc: 
Sent: Saturday, February 09, 2002 8:28 AM
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)


> > http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm gives a
> > very visually powerful demonstration of the problem the working group
> > has debated over these many months, and I have no doubt that is useful
> > for many members of the working group to see some of the character
> > mixtures rather than hear them described.  Thank you for your efforts.
>
> Lest those on this list unfamiliar with Chinese be overly impressed
> with the "powerful" demonstration posted on that site, the
> islam.gif (2nd example) is *not* a valid representation of the
> distinctions in characters in question.
>
> The first character shown in all 8 lines is the glyph for U+6DF8
>   and *not* the glyph for U+6E05.
>
> The second character shown in all 8 lines is the glyph for U+771E
>   and *not* the glyph for U+771F.
>
> The third character shown in all 8 lines is the glyph for U+654E
>   and *not* the glyph for U+6559.
>
> So if told to type *exactly* what is shown in each line, the right
> answer in all 8 cases would be the same Unicode string:
> U+6DF8 U+771E U+654E.

                You  point out a very important issue that Windows 2000
traditional chinese version caused .
These characters can be copy and past to different AP or using the same text
file but select different AP to display it:
      1. notepad
      2.wordpad
      3.IE address BAR
      4.Mail body
      5.MicroSoft word
You can find a terriable results , all the font/script will change to
different style depend on different font size selected  as it is Japanese,
Taiwanese or Chinese scripts that you described.  There are not all the same
in different AP !!!
      These are the traditional variant coexisted in UNICODE table.  In
Taiwan,  people treat these pair as the same , not as you described that
which one is Japanese, PRC, Korean or Taiwan.

L.M.Tseng
> There *are* minute glyph distinctions here in the example, so it is
> clear that the font used to display these has a different glyph
> for each code position, but the font designer has *chosen* to
> make each pair look almost identical, rather than to reflect the
> glyph distinctions which underlay the separate character encoding.
> Presumably this is to meet some Taiwan-specific market
> requirements for font design. But the net effect is to artificially
> exaggerate the problem being complained about by those objecting
> to the IDNA handling of Chinese characters.
>
> To then advertise these examples as making the problem clear to
> those on this list who may be less than conversant with the
> Chinese variant problems I consider to verge on misleading.
>
> Those who wish to get an accurate depiction of the differences
> between the 3 pairs of characters in question should consult the
> standards themselves: ISO/IEC 10646-1:2000 or the online charts
> for the Unicode Standard:
>
> http://www.unicode.org/charts/PDF/U4E00.pdf
>
> --Ken
>
> (* O.k., I'll sit back down now. *)
>
>




From owner-idn@ops.ietf.org  Sat Feb  9 09:11: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 JAA15512
	for ; Sat, 9 Feb 2002 09:11:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZXzu-000HDI-00
	for idn-data@psg.com; Sat, 09 Feb 2002 05:56:58 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZXzt-000HD9-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 05:56:57 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g19Duqh18058;
	Sat, 9 Feb 2002 14:56:52 +0100 (MET)
From: "Kent Karlsson" 
To: "'Adam M. Costello'" ,
        "'IETF idn working group'" 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Sat, 9 Feb 2002 14:54:22 +0100
Message-ID: <000601c1b171$47b43de0$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20020208020008.GB10534@nicemice.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Adam M. Costello
> Sent: den 8 februari 2002 04:06
> To: IETF idn working group
> Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
> 
> 
> Kent Karlsson  wrote:
> 
> > 1. stringprep and nameprep should be rejoined to a 
> hostnameprep. They
> > are only about host name preparation, not any other name 
> preparation.
> 
> I think they are about domain name preparation.  Some domain names are
> textual but not host names, and don't obey the host name syntax rules.
> For example, _ldap._tcp.foo.net (see RFC 2782 about SRV 
> records).  I see
> no reason why IDNA should restrict its attention to host names when it
> can work perfectly well for all textual domain names.

A *delta* of the hostnameprep whould/should be used for SRV records;
i.e. it would use hostnameprep with a specified modification:
"LOW LINE is not prohibited" and whatever other changes needed 
for SRV records compared to hostnames, only listing the differences
(that is a delta), not the full result of applying the delta.


> That said, there could still be arguments for recombining the 
> stringprep
> and nameprep documents.  But you haven't yet presented any.

I'm not sure why the document was split into "stringprep" and a
"profile".  At least I would find a "hostnameprep" with deltas
for similar domain name preps a much more manageable approach.



> > 2. hostnameprep should be applied to the *entire* hostname; i.e. the
> > entire name should be 'mapped' in the same way *before* it is parsed
> > into parts.
> 
> Can you present any arguments favoring that approach?  I can 

Point 3 was the motivation.  Also: most users are likely to see a
hostname as an entity that would be treated the same by the system.
If fullwidth letters are perfectly ok to enter (mapped to normal width
by nameprep), why is not FULLWIDHT FULL STOP ok?  I think most users
that encounter that or similar (IDEOGRAPHIC FULL STOP in particular)
will find the currently specified behaviour idiosyncratic.


> think of a
> few problems with it:
> 
> Sometimes programs count the number of dots in a name.  Nameprep can
> change the number of dots (see the "Co." character, for 
> example).  This would be asking for trouble.

The "counting of dots" for an IDN should be done (as if) after the
mapping+NFKC, not before.



> After running nameprep on the whole string, then splitting 
> into labels,
> individual labels might be invalid Unicode strings.  For example, a
> label might start with a combining character.  So you'd have to do
> another round of checking on the individual labels anyway.

Yes, so?  "The other round" here does completely different things
than the "first round".  What's the problem?


> In general, software often operates on labels individually, splitting
> names, joining names, comparing labels, etc.  If IDNA were to do
> anything to create interdependencies and interactions between 
> labels, it
> would be asking for trouble.

Where was that implied in my suggestion?  As I said, parsing into parts
must be done as if after hostnameprep (most implementations may actually
do it after hostnameprep).  



> > 3. Various FULL STOPs should be mapped to FULL STOP
> 
> This is motivated by the previous suggestion,

No, it's the other way around: This point motivates the point 2.
See above.


> > 4. Various Pd (punctuation dash) should be mapped to HYPHEN-MINUS by
> > hostnameprep.
> 
> Presumably this is to avoid visual ambiguity. But there are many many
> visual ambiguities created by the addition of the Unicode repertoire
> (for example, several characters that look exactly like B).  Does this
> one really warrant special treatment?  Why?

If you had read my point 4 in its entirety, you would have found
the motivation: "Future keyboards may generate HYPHEN rather HYPHEN-MINUS
(except perhaps in "programming language mode", which few will use).
At least, hostnameprep should not prevent such a development."
What is not clear about that motivation?  It is not the business of
the IDN WG to prevent otherwise possibly desired developments of
keyboards.  The current suggestion puts up an unnecessary stumbling
block for this at least, which is inappropriate for this WG to do.


> > 5. Symbols/punctuation/dingbats (except the hyphen-like 
> dashes) should
> > not be allowed [in host names]...  Punctuatuation in particular, in
> > contexts where hostnames are embedded, may in future syntaxes use
> > non-ASCII punctuation adjacent to the hostname.
> 
> That's a reasonable argument.  I argued something similar myself long
> ago, but I didn't persuade the group.  Maybe it's too late now.

Again, it is not the business of the IDN WG to put up stumbling blocks
for developments that may otherwise be desirable.  It is quite
conceivable that future designers of syntaxes that embed host names
may wish to do so using non-ASCII punctuation and symbols adjacent
to the hostname (before being ACE encoded).  With the current proposal
that is, without reason, prevented.


> > 6. Hangul syllables (with conjoining characters, not non-conjoining
> > compatiblity characters) that represent the same syllable must be
> > mapped to the same representation.  Due to unfortunate historic
> > reasons, this does no longer happen automatically with NFKC (though
> > for drafts for NFKC it did).  Mappings should be added so that
> > "syllabically" equivalent Hangul conjoning characters are 
> mapped to a
> > common representation.
> 
> I know nothing about this issue, but it sounds like you want 
> the IETF to
> redo Unicode work.  The Unicode folks know more about 
> characters than we
> do; I'm skeptical that we could do a better job on that sort of thing.

This is due to a compatibility mapping removal.  The compatibility mapping
was present in Unicode 2.1, but was removed for Unicode 3.0, not for
Hangul specific reasons, but for technical trouble with the NFKC definition.
A better, and for Hangul more reasonable resolution would have been to
make those compatibility mappings canonical instead, which would have
been appropriate both for Hangul and for the NFKC definition issue.

This is again an issue of not putting up stumbling blocks for future
possible developments.  Future Hangul keyboards *may* (if so desired)
generate just single letter jamos (Hangul is an alphabetic script
with 14 consonant letters and 11 vowel letters; the alphabet *itself*
does not have hundreds/thousands of characters).



> > 7. No document associated with hostnameprep should make any further
> > restrictions on domain/host names than hostnameprep itself.
> 
> That's simply impossible.  Nameprep has no way of knowing whether the
> name is too long.  You can't know that until after Punycode has been
> applied.  Also, nameprep is not designed to apply special rules at the
> beginning/end of the string, like prohibiting 
> leading/trailing hyphens,
> or prohibiting the IDNA prefix.  Those checks are better left 
> where they
> are now, in ToASCII.

Let me rephrase:  "No document associated with hostnameprep should
make any further restrictions on the principal makeup of domain/host
names than hostnameprep itself. They make make size or tagging restrictions
though (those aspects would normally not be directly visible to the user)."



> > 9. User interfaces that encounter mixed script hostname 
> *parts* should
> > be recommended to "flag" them (ballon warning, color differentiate,
> > make blinking, bounce automatic registratations, ...).
> 
> Generally a good idea, although some scripts might be mixed often.
> Maybe just talk about "labels containing combinations of characters
> likely to be misleading", and give a couple of examples, and 
> leave it to
> the software developers to figure out what in general is 
> misleading and
> what isn't.

That's fine by me.


		/Kent K

> AMC




From owner-idn@ops.ietf.org  Sat Feb  9 09:36: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 JAA15741
	for ; Sat, 9 Feb 2002 09:36:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZYX2-000JQI-00
	for idn-data@psg.com; Sat, 09 Feb 2002 06:31:12 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZYX1-000JPy-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 06:31:11 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Sat, 9 Feb 2002 06:46:41 -0800
Message-ID: <003d01c1b177$d3632800$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "ben" , 
References:  <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost> <005e01c1b12e$e7a44900$cd462b18@mtag.phub.net.cable.rogers.com>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sat, 9 Feb 2002 09:41:13 -0500
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

>It reminds of the Chinese saying:
>
> 塞翁失马，焉知非福
>
> Which is literally translated as:
> "A man who lost his horse is neither fortune nor misfortune."
>
> or roughly translated to mean:
> "What ever will be... will be."
>

I got some offline feedback that basically says, "Huhh?  What are you
talking about?"

For most who probably do not care about what I have to say, please
press the delete button now.  For those who do, this is the story I
heard when I was a kid...

Long long time ago lived a very old man in China.  Although he lived
alone with his only grandson, he was not lonely- he was a very well
liked and respected old man.  When he was younger, he was a dedicated
and hard working jockey.  But as he got older, he became too weak to
race horses so he retired to training wild horses instead- perfecting
the art of a horse whisperer.  One day, the fence on his ranch broke
and his horse ran away.  The neighbours heard about it and felt really
bad for him.  They went to his house to console him... but to their
surprise, the old man was not at all sad.  Instead, he said, "This may
be a fortune".  The neighbours were no longer worried about the old
man and went home happy knowing that he can be so optimistic.  Amazing
how fate works... the next day, not only did the horse found his way
home, he brought back a wild but gorgeous companion.  When the
neighbours heard about this good new, they were so happy for him and
went to his house to congratulate him.  However, to their surprise,
the old man was not at all happy.  Instead, he said, "This may be a
mis-fortune".  The neighbours were completely puzzled by the old man's
reaction and went home thinking the poor old man has become senile.
Amazing how fate works... the next day when the old man tried to tame
the new wild horse by having his grandson ride it, the young man fell
off and broke his leg.  When the neighbours heard about the news, they
rushed to his house to see if the young man was okay and to see if he
needed any help.  Again, to their surprise, the old man said, "This
may be a fortune.".  Call it fate... call it coincidence... the next
day, the army drafted all the young men in the village to go to war.
But because the old man's grandson had a broken leg, he was not
drafted and permitted to stay home.  The sad thing was that all the
young men drafted either perished or were seriously injured in the
war.

Thanks,
Ben







From owner-idn@ops.ietf.org  Sat Feb  9 10:13: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 KAA16014
	for ; Sat, 9 Feb 2002 10:13:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZZ23-000LWg-00
	for idn-data@psg.com; Sat, 09 Feb 2002 07:03:15 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZZ22-000LWU-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 07:03:14 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16ZZ1y-0000Fz-00
	for ; Sat, 09 Feb 2002 07:03:10 -0800
Date: Sat, 9 Feb 2002 15:03:10 +0000
From: "Adam M. Costello" 
To: "'IETF idn working group'" 
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Message-ID: <20020209150309.GA900@nicemice.net>
Reply-To: IETF idn working group 
References: <20020208020008.GB10534@nicemice.net> <000601c1b171$47b43de0$b4e21081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000601c1b171$47b43de0$b4e21081@chalmers95a69n>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Kent Karlsson  wrote:

> A *delta* of the hostnameprep whould/should be used for SRV records;
> i.e. it would use hostnameprep with a specified modification:  "LOW
> LINE is not prohibited"

But what about when the exact classification of a domain name is
unknown?  Maybe the software knows that it's a textual domain name but
does't know whether it's a host or a SRV or something else that was
invented after the software was written.  Should the software err on the
side of being too lenient or too strict?  Should it default to enforcing
the hostname syntax, which is probably the most restrictive syntax there
will ever be?  How could it default to anything else if nothing else
were defined in IDNA?

Nameprep defines a least common denominator--the most lenient
restrictions that *all* textual domain names must adhere to.  Software
can always apply those restrictions without fear of disabling legitimate
domain names, and software can depend on the fact that all legitimate
domain names adhere to those restrictions.  Hostnameprep would not have
those useful properties.

Your idea of having one basic preparation for domain names and deltas
against it for particular kinds of domain names is a good idea, but I
think the deltas should always add restrictions, never remove them.  In
this model, the host restrictions in step 3 of ToASCII are a delta.

> I'm not sure why the document was split into "stringprep" and a
> "profile".

So that the stringprep framework could be reused for other things
(things that are not domain names at all).

> If fullwidth letters are perfectly ok to enter (mapped to normal width
> by nameprep), why is not FULLWIDTH FULL STOP ok?  I think most users
> that encounter that or similar (IDEOGRAPHIC FULL STOP in particular)
> will find the currently specified behaviour idiosyncratic.

What currently specified behavior?  IDNA says nothing about the
separators between labels except that they are "usually" dots.  IDNA
says nothing about how to split domain names into labels, or join labels
into domain names.  It neither requires nor prohibits the acceptance of
fullwidth full stop as a domain label separator.

I'm not sure there is any wide-reaching standard on this.  STD13 (the
DNS standard) specifies that labels are dot-separated in DNS master
files, but doesn't say they should use that syntax in other places.  RFC
(2)822 says that domain labels are dot-separated in email headers.  But
those two standards disagree about the trailing dot: it is required
in master files and forbidden in email headers.  They also disagree
about whether whitespace is allowed around the dots.  Syntax rules for
delimiting domain labels appear many separate standards, but I'm not
aware of any overall requirement regarding domain label delimiters that
applies to all applications/protocols.

> "Future keyboards may generate HYPHEN rather HYPHEN-MINUS (except
> perhaps in "programming language mode", which few will use).  At
> least, hostnameprep should not prevent such a development."

I have no strong opinion either way.  Anyone else?  Should hyphen-like
characters get special treatment just as whitespace characters get
special treatment?

AMC



From owner-idn@ops.ietf.org  Sat Feb  9 11:48: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 LAA17207
	for ; Sat, 9 Feb 2002 11:48:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZaaU-000267-00
	for idn-data@psg.com; Sat, 09 Feb 2002 08:42:54 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZaaT-00025z-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 08:42:53 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g19Ggp325838
	for ; Sat, 9 Feb 2002 08:42:51 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <000601c1b171$47b43de0$b4e21081@chalmers95a69n>
References: <000601c1b171$47b43de0$b4e21081@chalmers95a69n>
Date: Sat, 9 Feb 2002 08:41:51 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 2:54 PM +0100 2/9/02, Kent Karlsson wrote:
>I'm not sure why the document was split into "stringprep" and a
>"profile".

The stringprep document says so explicity:

Other protocols can create profiles of these rules; these profiles 
will allow users to enter internationalized text strings in 
applications and have the highest chance of getting the content of 
the strings correct.

Note the first two words. Stringprep is already being used by other 
protocols that have nothing to do with DNS, such as iSCSI names.

>   At least I would find a "hostnameprep" with deltas
>for similar domain name preps a much more manageable approach.

But would make all other string preparation documents much harder to read.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Sat Feb  9 11:49: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 LAA17220
	for ; Sat, 9 Feb 2002 11:49:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZaaU-000260-00
	for idn-data@psg.com; Sat, 09 Feb 2002 08:42:54 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZaaT-00025t-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 08:42:53 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g19Ggo325835
	for ; Sat, 9 Feb 2002 08:42:50 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <005d01c1b109$d7315100$4407e29f@deng>
References: 
 <029f01c1b026$2920dd30$0f01000a@jamessonyvaio>
 <00b801c1b056$0ade4760$49156d8c@acer603>
 <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio>
 <021e01c1b0e5$611d15e0$c5e16d8c@itsnb>
 <20020208142737.A53521@shell.nominum.com>
 <005d01c1b109$d7315100$4407e29f@deng>
Date: Sat, 9 Feb 2002 08:31:52 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 9:33 AM +0800 2/9/02, xiang deng wrote:
>Dear Ted,
>
>Thanks for your comment.
>Discussion make issue more clearly.
>
>we are clear:
>1. Current IDNA is a good solution.
>2. IDNA ONLY will be detrimental to Chinese Internet Community.
>3. IDN WG chairs' express: it's out of scope.

It is incredibly inappropriate to blame this on WG chairs. There have 
been many, many other people in the WG who have stated the same 
opinion. If you object to this, you can follow the IETF rules for 
appealing. Hint: that does not involve spamming the mailing list.

>  But decision maker is not
>     family with Chinese character and never use Chinese character in 
>daily life.

Why do you feel that is relevant in a standards body?

>4. Chinese Internet community object IDNA ONLY solution.

The two name registries on this mailing list do not represent the 
Chinese Internet community any more than Verisign represents the US 
community. Many of us know know lots of other Chinese people, and it 
is safe to say that the extreme rudeness and inability to work with 
others is not representative of the Chinese Internet community.

>5. Unicode haven't finish the equivalent set of Chinese character.

More importantly, ISO has not started it either.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Sat Feb  9 12:14: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 MAA17413
	for ; Sat, 9 Feb 2002 12:14:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zazc-0003IC-00
	for idn-data@psg.com; Sat, 09 Feb 2002 09:08:52 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zazb-0003I6-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 09:08:51 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g19H8m326260
	for ; Sat, 9 Feb 2002 09:08:48 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <3C6494D9.988C9CBA@iis.sinica.edu.tw>
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	
 <83129960.1012820475@localhost> 
 <3C6494D9.988C9CBA@iis.sinica.edu.tw>
Date: Sat, 9 Feb 2002 09:08:24 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 11:17 AM +0800 2/9/02, hoho wrote:
>Since the WG insists on a client solution based on Unicode, without on
>such technical
>solution, we have no way to depend on the courtesy of internationalized
>companies
>to make registration policies being friendly to language communities
>including Chinese

Correct.

>who will be most seriously damaged by the decision of the WG.

You have never given any justification for that assumption. In fact, 
later in your message you show that there are solutions to the 
problem.

>  It would be
>a pity
>if we could not prevent greedy business from dumping defective domain
>name products
>into Chinese community.

Then you should work to prevent it for your community. The IETF has 
absolutely no control over the products that use the standards we 
produce. Everyone knows that.

>  We definitely are positive for your efforts in
>bring up a solution
>that solves DN problem for many languages. But, please do not force the
>Chinese
>community to be the victim of the side-effect.

The IETF could not force such a thing, and obviously does not want to do so.

>  > Of course, CDNC members would like to maximize their
>>  financial gain in registration, but the concern of the IETF is always
>>  towards helping users. There is a huge different between "cannot be
>>  solved" and "it will cost a small number of organizations a lot of
>>  money".
>
>This is also interesting. As far as I know, TWNIC has their social
>responsibily
>in our country. There major concern for TWNIC to work with IDN WG is
>consumer
>protection. The reason why they work on TC/SC, is that we all aware the
>lack
>of an international standard on Han variants which we could use to
>convince the
>WG to pay attention.

That work, which was done by CNNIC starting a year ago, was 
successful. The WG now understands the scope of the problem. We also 
understand what it would take to solve the problem in the IDN 
standards or in a registration solution. (I don't consider the spam 
and technically misleading messages that TWNIC has been sending for 
the last two weeks to be constructive work on TC/SC.)

>  Thus TC/SC becomes the best hope because it's
>something
>exists for more than 50 years. If the working group could adopt it, then
>at least this is
>something for all registries to restrict their name space a little bit
>and not too make
>too much trouble to Chinese community.

We fully agree here. However, in order for the WG to adopt it, we 
need an Internet Draft that contains a protocol that can be used in 
the IETF. So far, no such Internet Draft has appeared, even after 
lots of strong efforts of CNNIC. Further, in recent private 
conversations, TWNIC has told people in the IETF that they don't 
believe such a draft is possible. So you are asking the WG to adopt 
something that you believe it cannot.

>  It's a very humble wish, but
>unfortunately, was
>rejected by the WG. On the other hand, I can assure you that there is no
>way for TWNIC
>to make a registration policy without taking the maximum set of Han
>variants into account.

It is good to hear you finally admit that this is possible! Note that 
the declaration that started this thread said it was not possible. 
Such a registration policy will indeed help the people of Taiwan and 
the rest of China.

>As a non-profit organization, consumer protection is beyond the goal of
>making a big
>profit. Furthermore, dometistic consumer protection groups will not allow
>that to
>happen either.

Then it is your responsibility to show them how to prevent the problem.

>I am going back to my family in another city for Chinese New Year now.
>I'll respond to
>the rest of your questions as soon as possible.

Please enjoy the holiday; many of us here will be doing the same.

>By the way, I have trouble sending a message with a long list of
>recipients. Could you
>cut your list shorter please? I guess most people on your list is already
>on IDN list.

Um, that long list was started by TWNIC. Most of us are quite happy 
to have the list shorter.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Sat Feb  9 13:35: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 NAA18748
	for ; Sat, 9 Feb 2002 13:35:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZcCK-000Jqr-00
	for idn-data@psg.com; Sat, 09 Feb 2002 10:26:04 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZcCI-000JmW-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 10:26:03 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g19IQ2U29032
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Sun, 10 Feb 2002 02:26:03 +0800 (CST)
Message-ID: <001001c1b196$d5765f80$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= 
To: , "Paul Hoffman / IMC" 
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	 <83129960.1012820475@localhost>  <3C6494D9.988C9CBA@iis.sinica.edu.tw> 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Date: Sun, 10 Feb 2002 02:23:10 +0800
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

Dear Paul Hoffman:
               You have release many messages ,  talking some people from
TWNIC in SLT or in private mail with you  that one always agree your point
like such as:
               1. make more money from registration
               2. it is impossible to solve TC/SC
               3. registration policy can solve all ...
               etc....
Can you specify more clearly ? we all like to know what is the reference ?
              In these discussion of  TC/SC , case mapping , normalization
of character set , prohibition . these  are all related to your draft and
you never response what is wrong or what can be improved to solve the TC/SC
problems.

----- Original Message -----
From: "Paul Hoffman / IMC"  Further, in recent private
> conversations, TWNIC has told people in the IETF that they don't
> believe such a draft is possible. So you are asking the WG to adopt
> something that you believe it cannot.
>
        These draft are present in TSCONV . Are you have eye in it ?
We , all come from Taiwan  like to know these message or people that you
referenced.

> >  It's a very humble wish, but
> >unfortunately, was
> >rejected by the WG. On the other hand, I can assure you that there is no
> >way for TWNIC
> >to make a registration policy without taking the maximum set of Han
> >variants into account.
>
> It is good to hear you finally admit that this is possible! Note that
> the declaration that started this thread said it was not possible.
> Such a registration policy will indeed help the people of Taiwan and
> the rest of China.
>
       To solve TC/SC only rely on registration is impossible to solve
problems of delegation and scalabilty .
You just to play the word tricky to fool others .

L.M.Tseng





From owner-idn@ops.ietf.org  Sat Feb  9 14:55: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 OAA19219
	for ; Sat, 9 Feb 2002 14:55:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZdTG-000Dzd-00
	for idn-data@psg.com; Sat, 09 Feb 2002 11:47:38 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZdTF-000DzX-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 11:47:37 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g19JlY329012
	for ; Sat, 9 Feb 2002 11:47:34 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <001001c1b196$d5765f80$4007738c@q.j.tw>
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	
 <83129960.1012820475@localhost> 
 <3C6494D9.988C9CBA@iis.sinica.edu.tw>
 
 <001001c1b196$d5765f80$4007738c@q.j.tw>
Date: Sat, 9 Feb 2002 11:47:37 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 2:23 AM +0800 2/10/02, tsenglm@cc.ncu.edu.tw wrote:
>Can you specify more clearly ? we all like to know what is the reference ?

Sure. The "reference" is personal conversations that folks from CDNC 
had with other people active in the IDN WG during the Salt Lake City 
meeting. Many people met with CDNC members in Salt Lake City, and 
many of us heard similar statements in our discussions.

>                1. make more money from registration

People from both CNNIC and TWNIC have said "we cannot do a 2^n 
registration solution because we need to charge end users for each 
name in the zone". Of course, you do not need to charge per name: you 
can charge per group of names that come from a single base name. But 
the fact that this argument still comes up leads one to think that 
maybe you want to charge per name even though doing that will hurt 
the Chinese people.

>                2. it is impossible to solve TC/SC

I never said that; I have said the opposite many times. What I said 
was that it is impossible to get the solutions proposed in the tsconv 
Internet Drafts approved by the IETF because of their obvious 
technical and political flaws, all of which have been openly 
discussed in the WG. During meetings in Salt Lake City, CDNC members 
agreed with this and said that they would pursue a good 
Traditional-Simplified solution outside the confines of the IETF.

>                3. registration policy can solve all ...

No one has ever said that "registration policy can solve all ...". 
What has been said, and agreed to by TWNIC people, is that in the 
absence of Traditional-Simplifed mapping in IDN, registration policy 
can serve end users. It will not be consistent, so it will not serve 
them as well as it would if we could have put it into IDN. Of course, 
doing T-S registration can serve users better than anything that ever 
appeared in the tsconv drafts because it will not be limited to 1:1 
mapping, and it will allow mapping that comes from humans instead of 
limited tables.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Sat Feb  9 15:09: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 PAA19327
	for ; Sat, 9 Feb 2002 15:09:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZdhI-000EHO-00
	for idn-data@psg.com; Sat, 09 Feb 2002 12:02:08 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZdhH-000EHI-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 12:02:07 -0800
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 MAA20645
	for ; Sat, 9 Feb 2002 12:02:06 -0800
Message-Id: <5.1.0.14.2.20020209114951.027b3358@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Feb 2002 12:01:52 -0800
To: 
From: Dave Crocker 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
In-Reply-To: <001001c1b196$d5765f80$4007738c@q.j.tw>
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>
 <83129960.1012820475@localhost>
 
 <3C6494D9.988C9CBA@iis.sinica.edu.tw>
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk


>                2. it is impossible to solve TC/SC
>                3. registration policy can solve all ...
>                etc....
>Can you specify more clearly ? we all like to know what is the reference ?


1.      There have been many postings, from many people, about these 
points.  There is no need to respond to this query because

                 a) these issues have nothing to do with him in particular, and

                 b) the explanations have been posted many times.

         Anyone who wishes to learn those details is encouraged to review 
the working group archive.

2.      I also must note some concern over the style of criticisms being 
lodged against the some participants in the working group.

         I have always been taught that Asians have a much better 
appreciation for personal politeness than do Americans.  And my direct 
experience has almost always matched that.  In this forum, however, there 
has been a large number of vigorous, ad hominem attacks coming from some 
Asian participants.  Perhaps there are subtleties to the cultural norms 
that I am missing, but public abuse of people is not acceptable in the IETF 
even from us crude Americans.

         Those engaging in personal attacks damage themselves and their 
point of view.

         Further pursuit of ad hominem criticisms is worthy of 
banishment.  We need to ignore postings from people who make these issues 
personal.

3.      We are also seeing challenges to IETF working group process that 
demonstrate a clear lack of understanding of working group management 
requirements and IETF process rules.

         We need to simply refer posters who demonstrate such failings to 
the considerable IETF documentation on these matters, rather than try to 
educate them online.  Such efforts participate in a denial of service 
attack on the working group.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sat Feb  9 15:11: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 PAA19352
	for ; Sat, 9 Feb 2002 15:11:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zdk7-000ELv-00
	for idn-data@psg.com; Sat, 09 Feb 2002 12:05:03 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zdk6-000ELa-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 12:05:02 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 54940 for idn@ops.ietf.org; Sat, 09 Feb 2002 14:04:23 -0600
Message-ID: <3C6580EA.DE431F4D@ehsco.com>
Date: Sat, 09 Feb 2002 14:04:58 -0600
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: IDN 
Subject: [idn] WG last call documents
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


This is commentary on

  draft-hoffman-stringprep-00.txt
  draft-ietf-idn-nameprep-07.txt
  draft-ietf-idn-idna-06.txt


draft-hoffman-stringprep-00.txt:

 | 4. Normalization

 | [[[[[ Patrik asks: Is not addition of unassigned codepoints regarded
 | an update of UAX15? This is relevant here. ]]]]]

embedded comments need to be addressed or removed

Overall, I think that stringprep needs to define a data structure for
profiles and also needs to discuss version negotiation, both of which are
needed to facilitate programmatic upgrades. This means defining a
standardized character notation scheme to be used by all profiles, a file
structure (version tags, comment notation, line syntax, EOL markers, etc),
and so forth.

This also means describing suggested common mechanisms for retrieving
profiles. One obvious method would include "will be made available via FTP
by IANA", for example. Encouraging vendors to "provide updates in routine
patch kits" is another. Protocols can extend on that as needed as well,
(it is feasible that DNS could even use zone files and the zone transfer
services to retrieve version 1.1 of the subordinate stringpreps). The
point here would be to encourage rapid adoption of updated profiles,
through as many mechanisms as possible. No method will work 100% of the
time, so find five mechanisms that each work 60% of the time.

The hole I am concerned with here is with future mappings, where 'A' is
currently assigned but it is not currently mapped to 'a', and where a
future version creates such a mapping. In that case, the client will
generate 'A' as unmapped, the server will respond with an error or with
'a', either of which would trigger a failure on the client. Consider
ISO/IEC 8859-1 and 8859-15, where the former had lowercase y with
diaeresis and where the latter defines an uppercase y with diaeresis. It
seems likely that this kind of disjointed mapping will happen again, so we
need to be thinking about ways to minimize the disjointedness.

Secondarily, the IETF has had the lesson of versioning beaten into it over
the last few years, and it seems odd not to address this issue head-on in
the controlling spec.


draft-ietf-idn-nameprep-07.txt:

 | Stringprep Profile for Internationalized Host Names

Since this profile is specifically for host names, all of the rules that
apply to hostnames should be placed here. Consider that there are apps and
protocols which may use these rules to build internationalized host names
but will not use IDNA (either because they do not need IDNA conversion for
their data-path or they use something other than IDNA to encode the
names). Those services will need access to the complete set of rules.
Putting some of the rules here and some of the rules in IDNA essentially
means that every application that wants to build an i18n hostname has to
use both specifications, even though the "profile" is the only document
that a reasonable person should be expected to know about.

As it stands, this profile is incomplete without IDNA, but it does not
reference IDNA as a mandatory component (nor should it).

Furthermore, any subsequent work in this field will almost certainly be
required to obsolete this profile in order to clarify these issues, which
reinforces the need for versionin in stringprep.


draft-ietf-idn-idna-06.txt:

 | Abstract

 | This document defines internationalized domain names (IDNs)

That definition should be in a separate document, specifically either in
nameprep or in a stringprep profile that defines i18n "domain names"
rather than hostnames.

IDNA should "define a mechansim for encoding internationalized domain name
labels into STD13 labels".

 | 2 Terminology

 | The "ACE prefix" is defined in this document to be a string of ASCII
 | characters that appears at the beginning of every ACE label. It is
 | specified in section 5.

I thought the idea behind adopting "punycode" was to avoid the use of the
generic "ACE" term?

 | 3. Requirements

 | IDNA conformance means adherence of the following three rules:

 | 1) Whenever a domain name is put into a generic domain name slot,
 | every label MUST contain only ASCII characters. 

"generic domain name slot" should be substituted with "STD13 slot". There
is no reason whatsoever that application protocols cannot exchange IDNs or
IHNs in whatever form they wish.

 | 2) ACE labels SHOULD be hidden from users whenever possible. 

I have argued against this before and I will do so again now.

Should WHOIS servers perform this conversion on output (email addresses
and nameservers) since it is likely to be displayed to a user? Should an
email client perform conversion on a message? Every protocol and
data-format has unique considerations. Making blanket statements like this
is harmful.

CONVERSION MUST ONLY OCCUR WHERE A PROTOCOL OR DATA-FORMAT EXPLICITLY
DEFINES THE BEHAVIOR. MANDATORY CONVERSION WILL BREAK THINGS IF THERE IS
NOT AN AGREED-UPON METHOD FOR CONVERSION SPECIFIC TO THE APPLICATION.

| 4.1 ToASCII
| 4.2 ToUnicode

Add a disclaimer to the effect of ~"these routines MUST NOT be used except
where the data is known to contain an i18n domain name label". Trying to
pipe all Unicode data through ToASCII will be harmful, to say the least.
Trying to pipe an STD13 binary domain name through ToUnicode may result in
some false-positives.

 | B. Design philosophy

What value does this section provide? This text is religion not science,
seeing as how it omits key counter-arguments, namely that there are
hundreds if not thousands of applications for every DNS server, so
upgrading servers in addition to applications represents an incremental
cost (rather than the "The cost of implementing IDN may thus be much
lower, and the speed of implementation could be much higher" erroneous
opinion). Other aspects (such as ~"no change to protocols") are just as
wrong (protocols MUST BE CHANGED FOR CONVERSION TO BE PROPERLY MANAGED),
if not argumentative. This section is non-contributory to say the least,
and possibly even a hindrance to future developments, and has no place in
a technical specification such as this.


General comments:

In general, I think that there is a tremendous amount of architectural
work that needs to be done here. We need to strongly and clearly define
the different domain name data-types that are in use, make up stringprep
profiles for them, impose versioning controls on stringprep profiles, and
tighten up the IDNA spec. I think at this point that IDNA is pretty close
to where it needs to be, but it is still far too grandiose. It should only
define an encoding for specific data-types, and it should not encourage
any interpretative behavior on the applications.

One specific item, there does not seem to be a prohibition against certain
characters in the first position of a domain name label. There is a minor
prohibition in IDNA, but there needs to be an exception list in nameprep
that covers the characters we discussed in the WG earlier, which are
punctuation, diacritical marks, or dashes. We discussed this at length on
the mailing list.

"Adam M. Costello" wrote in <20020207043706.GA7193@nicemice.net>:

> There are some code points that are prohibited in host names, but not
> in all textual domain names.  The underscore is the best example.
> These prohibitions belong in ToASCII.

I disagree with this for a couple of reasons. First of all, these
exceptions are associated with protocol identifier labels, which are not
hostnames. Nameprep defines i18n hostnames, so these characters belong in
the nameprep prohibition. Secondarily, "protocol identifiers" are
generally considered as protocol operators which do not need to be
internationalized (therefore never needing anything but ASCII). This is
why I defined them as a separate data-type (and why I think they need
their own stringprep profile). See BCP18:

 | 2.  Where to do internationalization
 | 
 | Internationalization is for humans. This means that protocols are not
 | subject to internationalization; text strings are. Where protocol
 | elements look like text tokens, such as in many IETF application
 | layer protocols, protocols MUST specify which parts are protocol and
 | which are text. [WR 2.2.1.1]

SRV owner labels are protocol elements, not text. They should never go
through any conversion. A dedicated profile for this would help.

I agree with many of the other comments which have been made. I think that
a parent i18n "domain name" stringprep profile can describe certain
generic characteristics (such as mapping of full-stop characters) that the
label-centric profiles cannot.

DJ Bernstein is right-on when he says that certs don't solve the spoofing
problem. There is nothing preventing the wiley hacker from getting a cert
for billg@micr0soft.com, and there would be nothing about that cert which
would alert anybody that spoofing had occurred. In general terms, this
means that I agree with DJB that the initial scope should be tightly
controlled and slowly incremented. I think that this opinion was also
expressed by J Klensin's solicitation for a "safe-set" and D Crocker's
endorsement of a safe-set. This doesn't mean we all agree with DJB, but I
think that in this case, he is probably correct. A stronger versioning
system in Stringprep would make this a feasible approach, I think.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Sat Feb  9 15:18: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 PAA19390
	for ; Sat, 9 Feb 2002 15:18:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZdrS-000EZH-00
	for idn-data@psg.com; Sat, 09 Feb 2002 12:12:38 -0800
Received: from rwcrmhc51.attbi.com ([204.127.198.38])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZdrS-000EZB-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 12:12:38 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020209201235.FWUU1672.rwcrmhc51.attbi.com@c1340594a>;
          Sat, 9 Feb 2002 20:12:35 +0000
Message-ID: <005801c1b1a6$702169d0$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: , 
Cc: , , 
References: 
Subject: Re: [idn] A question...
Date: Sat, 9 Feb 2002 12:14:54 -0800
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 think another example is relevant to the discussion TC/SC issue. In
Danish, "aa" is equivalent to "å". So one could argue that a perfect
IDN for Danish would map these sequences of letters together. But
because the Latin alphabets are unified, Danish "a", German "a", Dutch
"a", and so on are all represented by the same code points. Trying to
map letters together on the basis of equivalences in different
languages runs afoul of the fact that the equivalences are not the
same across the different languages. (This is even worse with sorting
rather than matching: in German or English, ö < z, but in Swedish z <
ö. Luckily IDN does not have to sort, however.) What the IDN should do
is account for the non-linguistic, character-based equivalences;
linguistic equivalences should be left to higher level protocols or
registrars.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: 
To: 
Cc: ; ; 
Sent: Friday, February 08, 2002 22:07
Subject: Re: [idn] A question...


> In a message dated 2002-02-08 12:15:08 Pacific Standard Time,
> rosenne@qsm.co.il writes:
>
> >>> VERBATIM means "word for word". LITERATIM is "letter by letter".
This
> >>> is precisely the essence of the problem - you hear a domain
name, and
> >>> spell it exactly as you hear it, and it should be found.
> >>
> >> www.color.com and www.colour.com are not ever going to match.
> >
> > So we don't mean VERBATIM.
>
> Right, OK, I made a mistake.  So let's try again and see if I can
avoid
> obscuring the point this time:
>
> "The same, exact thing will happen with Han logographs.  If # and &
are TC
> and SC characters (respectively) that have the same meaning, and the
user
> types # when he should have typed & (or vice versa), under the
proposed IDN
> system the name will not match.  The user will get a 404, mutter
"aw,
> shucks," and type it again, LITERATIM, and the page will appear.
And the
> user will learn that it is important to type the EXACT characters
that appear
> on the business card, or billboard, or wherever the name came from."
>
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)
>
>




From owner-idn@ops.ietf.org  Sat Feb  9 16:38: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 QAA19899
	for ; Sat, 9 Feb 2002 16:38:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zf6w-000GDv-00
	for idn-data@psg.com; Sat, 09 Feb 2002 13:32:42 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zf6v-000GDp-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 13:32:42 -0800
Received: from chalmers95a69n (dynamic-193-224.dialup.chalmers.se [129.16.193.224])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g19LWdh01435
	for ; Sat, 9 Feb 2002 22:32:39 +0100 (MET)
From: "Kent Karlsson" 
To: 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Sat, 9 Feb 2002 22:30:06 +0100
Message-ID: <000301c1b1b0$f1ff10b0$e0c11081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: 
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> Note the first two words. Stringprep is already being used by other 
> protocols that have nothing to do with DNS, such as iSCSI names.

It's a "00" DRAFT.  It cannot possibly (reasonably) already be *used*.


> >   At least I would find a "hostnameprep" with deltas
> >for similar domain name preps a much more manageable approach.
> 
> But would make all other string preparation documents much 
> harder to read.

The 'deltas' approch works very well for collation.  One big
'default' table and a number of (most often small) deltas.
I don't see why that approach would make things difficult here.
To me, and I guess to others, it's easier to handle just *one*
targe table (with parts; here: map, prohibit, unassigned) and
a number of small changes, than to handle multiple large tables
that may have arbitrary and unemphasised differences.

		Kind regards
		/kent k




From owner-idn@ops.ietf.org  Sat Feb  9 16:38: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 QAA19911
	for ; Sat, 9 Feb 2002 16:38:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zf6Y-000GDM-00
	for idn-data@psg.com; Sat, 09 Feb 2002 13:32:18 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zf6W-000GCw-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 13:32:17 -0800
Received: from chalmers95a69n (dynamic-193-224.dialup.chalmers.se [129.16.193.224])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g19LWDh01423
	for ; Sat, 9 Feb 2002 22:32:13 +0100 (MET)
From: "Kent Karlsson" 
To: "'IETF idn working group'" 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Sat, 9 Feb 2002 22:29:39 +0100
Message-ID: <000201c1b1b0$e27d0890$e0c11081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <20020209150309.GA900@nicemice.net>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit




> Adam M. Costello

> Kent Karlsson  wrote:
> 
> > A *delta* of the hostnameprep whould/should be used for SRV records;
> > i.e. it would use hostnameprep with a specified modification:  "LOW
> > LINE is not prohibited"
> 
> But what about when the exact classification of a domain name is
> unknown?  Maybe the software knows that it's a textual domain name but

draft-ietf-idn-nameprep-07.txt has the title "Stringprep profile for
Internationalised ***Host Names***" (my emphasis)...


> does't know whether it's a host or a SRV or something else that was
> invented after the software was written.  Should the software 
> err on the
> side of being too lenient or too strict?  Should it default 
> to enforcing
> the hostname syntax, which is probably the most restrictive 
> syntax there
> will ever be?  

You have a point there.  But then the "nameprep" document should
say that this is the "default table" (or "tailorable template"
which is politically correct ISO-speak for that) and "default
normalisation".  Another document should then define the "host name
delta", This should be quite separately from IDNA, which talks about
other things like the use of "punnycode" [I liked that misspelling...;
or was that "pennycode" ;-); sorry], something most users should
(though they will not) be shielded from.

However there is a problem with that: one has to decide *now* what
additions are allowable in the "textual formal Internet names",
and which are not.  With the approach I favor (most restrictive,
i.e. hostnames as "default", and no punctuation/symbols in the hostnames,
with deltas adding permissions to use) additional characters allowed
in "deltad" names or instead used for future IDN embedding syntaxes
can be decided as one goes along with this at future times.



> Nameprep defines a least common denominator--the most lenient
> restrictions that *all* textual domain names must adhere to.  Software
> can always apply those restrictions without fear of disabling 
> legitimate
> domain names, and software can depend on the fact that all legitimate
> domain names adhere to those restrictions.  Hostnameprep 
> would not have
> those useful properties.
> 
> Your idea of having one basic preparation for domain names and deltas
> against it for particular kinds of domain names is a good idea, but I
> think the deltas should always add restrictions, never remove 
> them.  In
> this model, the host restrictions in step 3 of ToASCII are a delta.

See above, on both issues.


> > I'm not sure why the document was split into "stringprep" and a
> > "profile".
> 
> So that the stringprep framework could be reused for other things
> (things that are not domain names at all).

I'm all in favour of reuse; note that a "deltas" approach has a much
higher degree of reuse!


> > If fullwidth letters are perfectly ok to enter (mapped to 
> normal width
> > by nameprep), why is not FULLWIDTH FULL STOP ok?  I think most users
> > that encounter that or similar (IDEOGRAPHIC FULL STOP in particular)
> > will find the currently specified behaviour idiosyncratic.
> 
> What currently specified behavior?  IDNA says nothing about the
> separators between labels except that they are "usually" dots.  IDNA
> says nothing about how to split domain names into labels, or 
> join labels
> into domain names.  It neither requires nor prohibits the 
> acceptance of
> fullwidth full stop as a domain label separator.

Hmmm, this kind of contradicts your statements in your other e-mail.
I think something should be said about this, namely that the entier
IDN is processed the same way before any kind of part splitting.
When everything else is so detailed about mappings etc., this should
be the same.  Otherwise how does anyone know if FULLWIDTH STOP is
allowed (as a part separator) in an IDN or not?


		Kind regards
		/kent k





From owner-idn@ops.ietf.org  Sat Feb  9 16:51: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 QAA19979
	for ; Sat, 9 Feb 2002 16:51:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZfKf-000GZH-00
	for idn-data@psg.com; Sat, 09 Feb 2002 13:46:53 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZfKe-000GZB-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 13:46:52 -0800
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 NAA24161;
	Sat, 9 Feb 2002 13:46:48 -0800
Message-Id: <5.1.0.14.2.20020209134304.01afd4b0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Feb 2002 13:46:21 -0800
To: "Kent Karlsson" 
From: Dave Crocker 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Cc: 
In-Reply-To: <000301c1b1b0$f1ff10b0$e0c11081@chalmers95a69n>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 10:30 PM 2/9/2002 +0100, Kent Karlsson wrote:
> > Note the first two words. Stringprep is already being used by other
> > protocols that have nothing to do with DNS, such as iSCSI names.
>
>It's a "00" DRAFT.  It cannot possibly (reasonably) already be *used*.

This represents both a failure to understand how things can be done in the 
IETF and what specific things are being done now.


> > But would make all other string preparation documents much
> > harder to read.
>
>The 'deltas' approch works very well for collation.

The choice for separation was made carefully, after failure to make the 
split caused problems.

You are, of course, entitled to your own preferences.  However personal 
preferences are not all that relevant during a Last Call.

d/
----------

Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sat Feb  9 17: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 RAA20035
	for ; Sat, 9 Feb 2002 17:01:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZfU0-000GpI-00
	for idn-data@psg.com; Sat, 09 Feb 2002 13:56:32 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZfTz-000GpC-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 13:56:31 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g19LuPU09340
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Sun, 10 Feb 2002 05:56:26 +0800 (CST)
Message-ID: <001101c1b1b4$3d3ca9e0$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= 
To: , "Paul Hoffman / IMC" 
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	 <83129960.1012820475@localhost>  <3C6494D9.988C9CBA@iis.sinica.edu.tw>  <001001c1b196$d5765f80$4007738c@q.j.tw> 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Date: Sun, 10 Feb 2002 05:53:40 +0800
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

Dear  Paul  Hoffman:


> At 2:23 AM +0800 2/10/02, tsenglm@cc.ncu.edu.tw wrote:
> >Can you specify more clearly ? we all like to know what is the reference
?
>
> Sure. The "reference" is personal conversations that folks from CDNC
> had with other people active in the IDN WG during the Salt Lake City
> meeting. Many people met with CDNC members in Salt Lake City, and
> many of us heard similar statements in our discussions.
>
> >                1. make more money from registration
>
> People from both CNNIC and TWNIC have said "we cannot do a 2^n
> registration solution because we need to charge end users for each
> name in the zone".
          Are  you sure you do not make any mistake in these statements ?
In  SLT , I  have heard from Director . Mao
talk to John Klensin , making more money is not the goal of CNNIC , so he
can accept the delay of CJK deployment to protect  all  CJK  users.  CEO of
TWNIC Prof. W.S. Chen is not in SLT ,  I can make sure it is also the same
answer as CNNIC .
> Of course, you do not need to charge per name: you
> can charge per group of names that come from a single base name. But
> the fact that this argument still comes up leads one to think that
> maybe you want to charge per name even though doing that will hurt
> the Chinese people.

>
> >                2. it is impossible to solve TC/SC
>
> I never said that; I have said the opposite many times. What I said
> was that it is impossible to get the solutions proposed in the tsconv
> Internet Drafts approved by the IETF because of their obvious
> technical and political flaws, all of which have been openly
> discussed in the WG. During meetings in Salt Lake City, CDNC members
> agreed with this and said that they would pursue a good
> Traditional-Simplified solution outside the confines of the IETF.
>
                  Sorry , I do not see discussions of TC/SC related to
technique of  Validation , HSE , Multi-Case ACE in here . I  am also in SLT
, why  I  have not  this  solution ?  We hope this WG  temporarily delay the
CJK deployment by code point inhibition to let CJK area can get a TC/SC
solution if  this WG is so hurry to pass all,  because it is incomplete and
irreversible  for  user to  register CJK  name.

> >                3. registration policy can solve all ...
>
> No one has ever said that "registration policy can solve all ...".
> What has been said, and agreed to by TWNIC people, is that in the
> absence of Traditional-Simplifed mapping in IDN, registration policy
> can serve end users. It will not be consistent, so it will not serve
> them as well as it would if we could have put it into IDN. Of course,
> doing T-S registration can serve users better than anything that ever
> appeared in the tsconv drafts because it will not be limited to 1:1
> mapping, and it will allow mapping that comes from humans instead of
> limited tables.
>
               I  think people from TWNIC recognizes that to solve TC/SC
problems , it  need  multiple stage/level to cooperate . 1-1 mapping  table
are proposed in the draft that can be applied in the mapping after  nameprep
and before Puny code encoding. 1-n mapping need more time to discuss and
select one of  them  as 1-1 mapping or no any mapping , if   no-mapping is
assigned by language expert , the registration approach can help to register
all of them or select few of them by register.
              All the argument in here is " 1-1 mapping should be doing in
which level ?"  1. inside IDNA  2. Outside-IDNA: a client local module or
level-2 server  like  IRNSS and what is the connection interface between
this module with IDNA, 3. Registration policy .

L.M.Tseng




From owner-idn@ops.ietf.org  Sat Feb  9 17:23: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 RAA20214
	for ; Sat, 9 Feb 2002 17:23:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zfos-000HID-00
	for idn-data@psg.com; Sat, 09 Feb 2002 14:18:06 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zfor-000HI7-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 14:18:05 -0800
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 OAA25212;
	Sat, 9 Feb 2002 14:17:49 -0800
Message-Id: <5.1.0.14.2.20020209141352.045ee7f0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Feb 2002 14:17:19 -0800
To: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= 
From: Dave Crocker 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Cc: , "Paul Hoffman / IMC" 
In-Reply-To: <001101c1b1b4$3d3ca9e0$4007738c@q.j.tw>
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>
 <83129960.1012820475@localhost>
 
 <3C6494D9.988C9CBA@iis.sinica.edu.tw>
 
 <001001c1b196$d5765f80$4007738c@q.j.tw>
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 05:53 AM 2/10/2002 +0800, 
=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= wrote:
>talk to John Klensin , making more money is not the goal of CNNIC ,

In fact, this issue is not relevant to the technical efforts of the working 
group.  Hence it does not need to be discussed further.


>                   Sorry , I do not see discussions of TC/SC related to
>technique of  Validation , HSE , Multi-Case ACE in here . I  am also in SLT
>, why  I  have not  this  solution ?  We hope this WG  temporarily delay

Indeed, it has been quite clear that there is a desire by some to delay 
this working group, including through efforts to request continued 
consideration of topics that a) have been thoroughly considered over the 
last few years, or b) are outside the immediate scope of effort of the 
working group.


>                I  think people from TWNIC recognizes that to solve TC/SC
>problems

Indeed there is quite a bit of support for the efforts to solve this 
challenging and important problem.  However that support does not include 
further delay for the IDN effort.

d/

----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sat Feb  9 19:46: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 TAA21049
	for ; Sat, 9 Feb 2002 19:46:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZhrW-0001LJ-00
	for idn-data@psg.com; Sat, 09 Feb 2002 16:28:58 -0800
Received: from imo-m03.mx.aol.com ([64.12.136.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZhrV-0001LD-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 16:28:57 -0800
Received: from DougEwell2@cs.com
	by imo-m03.mx.aol.com (mail_out_v32.5.) id 4.d5.12e3eef7 (3701);
	Sat, 9 Feb 2002 19:28:30 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: 
Date: Sat, 9 Feb 2002 19:28:30 EST
Subject: [idn] Re: Unicode and Security
To: unicode@unicode.org
CC: larsga@garshol.priv.no, idn@ops.ietf.org, schneier@counterpane.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-09 13:00:59 Pacific Standard Time, 
larsga@garshol.priv.no writes:

> It seems to me that this problem really needs some other fix than the
> merging of all similar-looking characters in all character sets. I
> just can't see that working. 

Even the "merging" part wouldn't work.  Let's say that I, like Ken Sakamura 
or Bernard Miller before me, have decided that I know much more about 
character encoding than the Unicode Consortium or WG2, and I am going to 
develop my own character encoding that will solve the problem of confusables 
once and for all.

OK, we start with the easy ones.  Latin A, Greek Alpha, and Cyrillic A all 
get unified.  Latin E, Greek Epsilon, Cyrillic E, unified.  Hey, this is 
easier than I thought.  Latin B, Greek Beta, Cyrillic Ve.  Ha!  I'm smart 
enough to know that Ve gets unified with B and Beta, even though it 
represents a different sound.  Just like Han unification!  Boy, those Unicode 
dolts really missed something there.

Let's keep going.  Latin Y, Greek Upsilon, Cyrillic U.  Wait a minute, that 
Cyrillic U doesn't look *quite* the same.  Oh well, it's close enough, right? 
 Let's try some lower-case letters.  Latin a, Greek alpha, Cyrillic a.  That 
Greek alpha looks kinda cursive, doesn't it?  Should we unify it or not.  
Hmmm...

How about Latin n and Greek eta?  Is that descender on the eta significant or 
not?  Hey, you could stick an eta in the middle of a Web address and really 
fool somebody.  Better unify.  How about Latin v and Greek nu?  Different 
glyphs or not?  In 9-point MS Sans Serif, they're pretty close, aren't they?  
(And don't forget Armenian vo!)  Same goes for Latin y and Greek gamma.

Well, you get the point.  The world of alphabetic confusables is just not 
that simple or that 1-to-1.  There are more edge cases, in fact, than obvious 
cases such as the a/alpha or o/omicron that we keep hearing about.  And if I 
were trying to design this hypothetical "Uniglyph" encoding to get rid of 
those pesky confusables, and still provide support for alphabetic scripts 
besides Latin, I would eventually have to face the fact that it *can't be 
done*.  Oh, sure, it can be done for a/alpha and o/omicron, so I can make a 
sales presentation or a picket sign.  But a complete technical solution, uh, 
no.

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Sat Feb  9 19:59: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 TAA21097
	for ; Sat, 9 Feb 2002 19:59:12 -0500 (EST)
From: owner-idn@ops.ietf.org
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZiAT-0001hu-00
	for idn-data@psg.com; Sat, 09 Feb 2002 16:48:33 -0800
To: Unicode List , idn@ops.ietf.org,
        schneier@counterpane.com
Subject: [idn] Re: Unicode and Security
References: 
Message-Id: 
Date: Sat, 09 Feb 2002 16:48:33 -0800



Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
From: Lars Marius Garshol 
Date: 09 Feb 2002 21:52:17 +0100
In-Reply-To: 
Message-ID: 
Lines: 53
X-Mailer: Gnus v5.5/Emacs 20.2
Sender: owner-idn@ops.ietf.org
Precedence: bulk


* Elliotte Rusty Harold
|
| Let's say I register microsoft.com, only the fifth letter isn't a
| lower-case Latin o. It's actually a lower case Greek omicron.

I'll grant you that this is possible, perhaps even likely, and that it
may cause problems, but I'm far from convinced that this in any way
supports the "there are security problems in Unicode" thesis.

There are many characters which look alike, and yet are different,
which can cause problems of this kind. There are for example already
viruses which exploit the visual similarity between 1 and l in the
Windows system font to keep themselves from being discovered in file
listings.

So if this really is considered a problem it would seem to me that you
would need to deal with the problem of whoever@hotmai1.com,
whoever@hotmaii.com, and whoever@hotrnail.com looking very similar to
whoever@hotmail.com in lots of fonts. To exploit this, all you need to
know is what email client someone uses, and usually every email they
write will have that information in its headers.

It seems to me that this problem really needs some other fix than the
merging of all similar-looking characters in all character sets. I
just can't see that working.

Similarly, the "security problems" caused by using Unicode encoding
tricks to hide or mangle text in, say, contracts, is no different from
using HTML or CSS (or whatever) tricks to achieve the same effect, and
yet nobody is talking about security problems with HTML or CSS. See
[1] for one way of dealing with it that is now being worked on.

So while I accept that there is a problem it does not seem to me that
Unicode is the problem. To me the problem seems to be the complexity
of the relationship between the bytes sent to the user and what the
user actually sees and reacts to. That complexity is not going to
disappear, and aspects of the same "problem" exist with just about any
information representation, so clearly the solution must be something
other than changing all of these syntaxes/formats/encodings.

In the specific case you cite, for example, a better solution might be
for the user's email client to keep track of all the user's contacts
and for it to indicate in some clearly visible way whether the current
email comes from one of them or not. Whether it uses string matching
of email addresses or digital signatures to do that doesn't really
matter; it solves the problem in your example either way.

[1] 

--
Lars Marius Garshol, Ontopian         
ISO SC34/WG3, OASIS GeoLang TC        






From owner-idn@ops.ietf.org  Sat Feb  9 20:08: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 UAA21157
	for ; Sat, 9 Feb 2002 20:08:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZiKk-0001vf-00
	for idn-data@psg.com; Sat, 09 Feb 2002 16:59:10 -0800
Received: from smtp11.singnet.com.sg ([165.21.6.31])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZiKj-0001vW-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 16:59:09 -0800
Received: from jamessonyvaio (bb-165-21-154-215.singnet.com.sg [165.21.154.215])
	by smtp11.singnet.com.sg (8.12.2/8.12.2) with SMTP id g1A0wc4O002056;
	Sun, 10 Feb 2002 08:58:38 +0800 (SGT)
Message-ID: <072f01c1b1ce$2869db90$1001000a@jamessonyvaio>
From: "James Seng/Personal" 
To: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= ,
        , "Paul Hoffman / IMC" 
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	 <83129960.1012820475@localhost>  <3C6494D9.988C9CBA@iis.sinica.edu.tw>  <001001c1b196$d5765f80$4007738c@q.j.tw>  <001101c1b1b4$3d3ca9e0$4007738c@q.j.tw>
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Date: Sun, 10 Feb 2002 08:59:14 +0800
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 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

Prof Tseng,

We are rethrashing issues which have been discussed and concluded.

So please, lets stop this thread, or at least bring it offline. There
are more important things to discuss at the moment, like completing the
last call.

The last call _will_ conclude on 11th feb. Time are better spend with
substainted points references to the last call drafts then to bring up
yet-another-proposal.

ps: A man whom I admired a lot, for his writing, his personality and
view of life once wrote these famous words: "Violence is the last resort
of the incompetent".

-James Seng

----- Original Message -----
From: "tsenglm@計網中心.中大.tw" 
To: ; "Paul Hoffman / IMC" 
Sent: Sunday, February 10, 2002 5:53 AM
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration


> Dear  Paul  Hoffman:
>
>
> > At 2:23 AM +0800 2/10/02, tsenglm@cc.ncu.edu.tw wrote:
> > >Can you specify more clearly ? we all like to know what is the
reference
> ?
> >
> > Sure. The "reference" is personal conversations that folks from CDNC
> > had with other people active in the IDN WG during the Salt Lake City
> > meeting. Many people met with CDNC members in Salt Lake City, and
> > many of us heard similar statements in our discussions.
> >
> > >                1. make more money from registration
> >
> > People from both CNNIC and TWNIC have said "we cannot do a 2^n
> > registration solution because we need to charge end users for each
> > name in the zone".
>           Are  you sure you do not make any mistake in these
statements ?
> In  SLT , I  have heard from Director . Mao
> talk to John Klensin , making more money is not the goal of CNNIC , so
he
> can accept the delay of CJK deployment to protect  all  CJK  users.
CEO of
> TWNIC Prof. W.S. Chen is not in SLT ,  I can make sure it is also the
same
> answer as CNNIC .
> > Of course, you do not need to charge per name: you
> > can charge per group of names that come from a single base name. But
> > the fact that this argument still comes up leads one to think that
> > maybe you want to charge per name even though doing that will hurt
> > the Chinese people.
>
> >
> > >                2. it is impossible to solve TC/SC
> >
> > I never said that; I have said the opposite many times. What I said
> > was that it is impossible to get the solutions proposed in the
tsconv
> > Internet Drafts approved by the IETF because of their obvious
> > technical and political flaws, all of which have been openly
> > discussed in the WG. During meetings in Salt Lake City, CDNC members
> > agreed with this and said that they would pursue a good
> > Traditional-Simplified solution outside the confines of the IETF.
> >
>                   Sorry , I do not see discussions of TC/SC related to
> technique of  Validation , HSE , Multi-Case ACE in here . I  am also
in SLT
> , why  I  have not  this  solution ?  We hope this WG  temporarily
delay the
> CJK deployment by code point inhibition to let CJK area can get a
TC/SC
> solution if  this WG is so hurry to pass all,  because it is
incomplete and
> irreversible  for  user to  register CJK  name.
>
> > >                3. registration policy can solve all ...
> >
> > No one has ever said that "registration policy can solve all ...".
> > What has been said, and agreed to by TWNIC people, is that in the
> > absence of Traditional-Simplifed mapping in IDN, registration policy
> > can serve end users. It will not be consistent, so it will not serve
> > them as well as it would if we could have put it into IDN. Of
course,
> > doing T-S registration can serve users better than anything that
ever
> > appeared in the tsconv drafts because it will not be limited to 1:1
> > mapping, and it will allow mapping that comes from humans instead of
> > limited tables.
> >
>                I  think people from TWNIC recognizes that to solve
TC/SC
> problems , it  need  multiple stage/level to cooperate . 1-1 mapping
table
> are proposed in the draft that can be applied in the mapping after
nameprep
> and before Puny code encoding. 1-n mapping need more time to discuss
and
> select one of  them  as 1-1 mapping or no any mapping , if
no-mapping is
> assigned by language expert , the registration approach can help to
register
> all of them or select few of them by register.
>               All the argument in here is " 1-1 mapping should be
doing in
> which level ?"  1. inside IDNA  2. Outside-IDNA: a client local module
or
> level-2 server  like  IRNSS and what is the connection interface
between
> this module with IDNA, 3. Registration policy .
>
> L.M.Tseng
>
>




From owner-idn@ops.ietf.org  Sat Feb  9 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 VAA21576
	for ; Sat, 9 Feb 2002 21:02:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZjDW-00033w-00
	for idn-data@psg.com; Sat, 09 Feb 2002 17:55:46 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16ZjDV-00033q-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 17:55:45 -0800
Received: (qmail 8000 invoked by uid 1001); 10 Feb 2002 01:54:42 -0000
Date: 10 Feb 2002 01:54:42 -0000
Message-ID: <20020210015442.27325.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

John C Klensin writes:
> already reached consensus

These claims of consensus are fraudulent. There have always been strong
objections from many regular group participants. We believe that the
current proposals are extremely harmful and should not be deployed. We
are speaking on behalf of a huge number of users.

Even more damning than the number of objections is the superficial way
in which the objections are treated. For example:

   * When we point out in detail how the proposed deployment plan
     creates serious interoperability problems---mail will bounce; web
     pages will fail to load---we're told that users should stop using
     pipes, copy-and-paste, and other program-linking mechanisms.

   * When two hundred users complain about the handling of Chinese,
     they're told that their objections ``don't count,'' and that they
     should learn to type _exactly_ what they see, no matter how painful
     that might be.

   * When I ask why the same principle doesn't apply to the uppercase
     issue, saving implementors a huge amount of case-conversion effort,
     my question is simply ignored.

The idea that objections should be ignored because ``we have to do
something'' is contrary to common sense, contrary to IETF procedures,
and contrary to United States antitrust law.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sat Feb  9 21:48: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 VAA22745
	for ; Sat, 9 Feb 2002 21:48:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZjpV-0003qr-00
	for idn-data@psg.com; Sat, 09 Feb 2002 18:35:01 -0800
Subject: [idn] Re: Unicode and Security
To: DougEwell2@cs.com
Date: Sat, 9 Feb 2002 21:28:53 -0500 (EST)
CC: unicode@unicode.org, larsga@garshol.priv.no, idn@ops.ietf.org,
        schneier@counterpane.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: 
From: John Cowan 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

DougEwell2@cs.com scripsit:

> Let's keep going.  Latin Y, Greek Upsilon, Cyrillic U.  Wait a minute,
that
> Cyrillic U doesn't look *quite* the same.  Oh well, it's close enough,
right?

And then there's the Cyrillic U with the straight descender, whic
actually does look just like its Latin and Greek counterparts.
I guess we just can't afford to have two kinds of Cyrillic U around:
off with their heads (or tails)!

Unfortunately, there goes all those Turkic languages written in
Cyrillic.
Well, they should Romanize anyway.  In fact all languages should
Romanize:
it simplifies everything soooo much, and if we get rid of diacritics
while we're at at it.... well, the ASCII Consortium
(off-net, but cached in part at
http://www.google.com/search?q=cache:IRueJQ1bA-4C:www.wholehog.fsnet.co.
uk/robert/ascii/+ASCII+Consortium&hl=en)
will find it a dream come true.  And there was much rejoicing.

--
John Cowan           http://www.ccil.org/~cowan
cowan@ccil.org
To say that Bilbo's breath was taken away is no description at all.
There
are no words left to express his staggerment, since Men changed the
language
that they learned of elves in the days when all the world was wonderful.
        --_The Hobbit_





From owner-idn@ops.ietf.org  Sat Feb  9 21:49: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 VAA22761
	for ; Sat, 9 Feb 2002 21:49:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zjrg-0003sw-00
	for idn-data@psg.com; Sat, 09 Feb 2002 18:37:16 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Zjrf-0003sq-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 18:37:15 -0800
Received: (qmail 24798 invoked by uid 1001); 10 Feb 2002 02:36:14 -0000
Date: 10 Feb 2002 02:36:14 -0000
Message-ID: <20020210023614.16137.qmail@cr.yp.to>
Mail-Followup-To: schneier@counterpane.com,
  unicode@unicode.org,
  idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: unicode@unicode.org, idn@ops.ietf.org
Cc: schneier@counterpane.com
Subject: Re: [idn] Re: Unicode and Security
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

DougEwell2@cs.com writes:
> Even the "merging" part wouldn't work.

Merging is certainly painful. It becomes incredibly painful if you
insist, as the IDNA proponents do, on merging lowercase characters with
uppercase characters.

On the other hand, _selection_ is easy. We can point to a fairly large
set of useful characters whose glyphs can be readily distinguished. If
we prohibit other characters, rather than trying to map them to the
selected set, then we won't have the merging problems.

Of course, eliminating those other characters from Unicode itself would
be foolish. The characters are useful in many other applications.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sat Feb  9 22:14: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 WAA22930
	for ; Sat, 9 Feb 2002 22:14:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZkK7-0004Xu-00
	for idn-data@psg.com; Sat, 09 Feb 2002 19:06:39 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZkK6-0004Xn-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 19:06:38 -0800
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 TAA01333
	for ; Sat, 9 Feb 2002 19:06:36 -0800
Message-Id: <5.1.0.14.2.20020209184121.04002100@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Feb 2002 19:05:58 -0800
To: idn@ops.ietf.org
From: Dave Crocker 
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
In-Reply-To: <20020210015442.27325.qmail@cr.yp.to>
References: <008f01c1b10e$f2eef690$4407e29f@deng>
 <3052129.1013207733@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 01:54 AM 2/10/2002 +0000, D. J. Bernstein wrote:
>John C Klensin writes:
> > already reached consensus
>
>These claims of consensus are fraudulent.

Folks,

Dan has a pattern of making this claim, whenever he does not disagrees with 
a working group's decision.  It has become something of a trademark.

So far, he has not believed his own claims enough to follow IETF appeals 
procedures.  Instead he simply keeps making these sorts of claims through 
email.

d/

----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sun Feb 10 00:33: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 AAA25020
	for ; Sun, 10 Feb 2002 00:33:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZmL0-0006Ci-00
	for idn-data@psg.com; Sat, 09 Feb 2002 21:15:42 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16ZmKz-0006Cc-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 21:15:41 -0800
Received: (qmail 31929 invoked by uid 1001); 10 Feb 2002 05:14:40 -0000
Date: 10 Feb 2002 05:14:40 -0000
Message-ID: <20020210051440.2468.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost> <20020210015442.27325.qmail@cr.yp.to> <5.1.0.14.2.20020209184121.04002100@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

My comments on the level of consensus here are based directly on the
mailing-list discussions, and can easily be verified from the archives.

For example, Marc Blanchet reported the results of a straw poll in May
2001, showing that _fourteen_ group participants disagreed with the IDNA
approach. James Seng stated on 5 June 2001 that he would not ``declare
consensus on IDNA'' over that number of objections. Now he seems to have
decided to ram the proposal down our throats despite all the objections.

Dave Crocker says that my reports of these facts---and the facts
themselves---should be ignored because I've pointed out similar problems
in a few other working groups. He neglects to mention that my statements
in all of these cases are supported by extensive evidence. He also
neglects to mention his own role in those other groups.

For example, http://cr.yp.to/smtp/klensin.html explains many problems in
RFC 2821. It includes detailed historical notes on how our beloved John
Klensin, the document editor, deliberately created one of the problems:

   * Klensin, without WG approval, singlehandedly changed the text;
   * five people objected, and nobody answered the objections;
   * Chris Newman, DRUMS WG chair, issued a ``Call for Consensus'';
   * more people objected, and nobody answered the objections;
   * people at a meeting were overwhelmingly _against_ Klensin's change;
   * the meeting note-taker declared consensus _against_ the change;
   * Klensin issued another draft, leaving his change in place;
   * I objected again, showing exactly how the text had to be fixed;
   * Klensin issued yet another draft, leaving his change in place;
   * Newman sent out a Last Call, ignoring all of the objections;
   * Newman and our beloved Dave Crocker declared consensus.

The web page includes detailed quotes and more than enough references
for readers to verify everything I say from the mailing-list archives.

Klensin and Crocker keep claiming consensus. I keep saying that they're
liars. The difference is that my claims are backed up by the facts. I'm
perfectly willing to provide detailed evidence for everything I say. In
contrast, Klensin and Crocker slither away when they're asked to defend
their claims.

``So far, he has not believed his own claims enough to follow IETF
appeals procedures,'' Crocker writes in his latest message. In fact, I
tried the IETF appeals process many years ago, and found it to be a
sham. As described in http://cr.yp.to/djbdns/namedroppers.html, I tried
the process again more recently, all the way to the ISOC board of
trustees; I again found the process to be a sham.

I recommend that anyone who is hurt financially by IETF file a United
States antitrust lawsuit against the document editors, committee chairs,
IESG members, IAB members, and ISOC members, as well as the companies
they work for. Antitrust law puts stringent requirements on the
procedures used by standards organizations; the IETF procedures don't
even come close to meeting those requirements. See

   http://caselaw.findlaw.com/cgi-bin/getcase.pl?court=US&vol=456&invol=556

for an example where a standards organization ended up paying $4.75
million for failing to impose procedures sufficient to prevent
anticompetitive behavior by a subcommittee chair.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sun Feb 10 00:53: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 AAA25176
	for ; Sun, 10 Feb 2002 00:53:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zmmq-0006df-00
	for idn-data@psg.com; Sat, 09 Feb 2002 21:44:28 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zmmp-0006dZ-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 21:44:27 -0800
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 VAA06353
	for ; Sat, 9 Feb 2002 21:44:26 -0800
Message-Id: <5.1.0.14.2.20020209213640.02027dc0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Feb 2002 21:42:12 -0800
To: idn@ops.ietf.org
From: Dave Crocker 
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
In-Reply-To: <20020210051440.2468.qmail@cr.yp.to>
References: <008f01c1b10e$f2eef690$4407e29f@deng>
 <3052129.1013207733@localhost>
 <20020210015442.27325.qmail@cr.yp.to>
 <5.1.0.14.2.20020209184121.04002100@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 05:14 AM 2/10/2002 +0000, D. J. Bernstein wrote:
>Dave Crocker says that my reports of these facts---and the facts
>themselves---should be ignored because I've pointed out similar problems
>in a few other working groups.

Thank you Dan.  It always helps to see one's statements distorted so well.


>In fact, I
>tried the IETF appeals process many years ago, and found it to be a
>sham. As described in http://cr.yp.to/djbdns/namedroppers.html,

Indeed I do stand corrected.  Tough to imagine how this stellar exception 
was missed, though of course Dan's assessment of the results is no 
surprise.  After all, being respectful of contrary opinions and assessments 
is difficult.


>  Antitrust law puts stringent requirements on the
>procedures used by standards organizations; the IETF procedures don't
>even come close to meeting those requirements.

And now Dan is trying to practise law.  How quaint.

For reference, folks, documentation of IETF procedures included 
considerable legal review by folks actually qualified in that profession.

d/

ps.  and this is easily the last note from me on this matter, lest Dan be 
permitted to drag things out further.

----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sun Feb 10 01:02: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 BAA25241
	for ; Sun, 10 Feb 2002 01:02:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zmy5-0006oD-00
	for idn-data@psg.com; Sat, 09 Feb 2002 21:56:05 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zmy4-0006o5-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 21:56:04 -0800
Received: from jamessonyvaio (bb-165-21-154-215.singnet.com.sg [165.21.154.215])
	by smtp12.singnet.com.sg (8.12.2/8.12.2) with SMTP id g1A5toZW011733;
	Sun, 10 Feb 2002 13:55:50 +0800
Message-ID: <07f701c1b1f7$a96b8940$1001000a@jamessonyvaio>
From: "James Seng/Personal" 
To: "D. J. Bernstein" , 
References: <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost> <20020210015442.27325.qmail@cr.yp.to> <5.1.0.14.2.20020209184121.04002100@127.0.0.1> <20020210051440.2468.qmail@cr.yp.to>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sun, 10 Feb 2002 13: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 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: 7bit

> For example, Marc Blanchet reported the results of a straw poll in May
> 2001, showing that _fourteen_ group participants disagreed with the
IDNA
> approach. James Seng stated on 5 June 2001 that he would not ``declare
> consensus on IDNA'' over that number of objections. Now he seems to
have
> decided to ram the proposal down our throats despite all the
objections.

All these are true with a few other fact missing:

1. We did not move IDNA forward in May/June 2001 (Have you check your
   calender lately?)

2. The minutes from SLC have been send to the group and for comments.
   Action items from the SLC include consensus to move IDNA for Last
   Call.

I trim off other information from the mail since it is irrelevant to the
IDN work.

-James Seng




From owner-idn@ops.ietf.org  Sun Feb 10 02:07: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 CAA03374
	for ; Sun, 10 Feb 2002 02:07:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Znyf-0007gs-00
	for idn-data@psg.com; Sat, 09 Feb 2002 23:00:45 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Znye-0007gm-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 23:00:44 -0800
Received: (qmail 14589 invoked by uid 1001); 10 Feb 2002 06:59:42 -0000
Date: 10 Feb 2002 06:59:42 -0000
Message-ID: <20020210065942.24959.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost> <20020210015442.27325.qmail@cr.yp.to> <5.1.0.14.2.20020209184121.04002100@127.0.0.1> <20020210051440.2468.qmail@cr.yp.to> <07f701c1b1f7$a96b8940$1001000a@jamessonyvaio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

James Seng/Personal writes:
> 1. We did not move IDNA forward in May/June 2001

What exactly has changed since then? You've been tweaking details. We
were objecting to fundamental flaws in the IDNA design. Those flaws are
still present in the current IDNA design. We continue to object to them.

> 2. The minutes from SLC have been send to the group and for comments.
>    Action items from the SLC include consensus to move IDNA for Last
>    Call.

The working group is _not_ the same as the set of people who show up at
an IETF meeting. See RFC 2418, section 3.2:

   Electronic mail permits the widest participation ... The WG must
   ensure that its process does not serve to exclude contribution by
   email-only participants ... Internet email discussion is possible for
   a much wider base of interested persons than is attendance at IETF
   meetings, due to the time and expense required to attend.

I accuse you of bias in your procedures for evaluating consensus. You
select procedures on the fly to support your position:

   * You run straw polls that you think will support IDNA, and you
     refuse to run other straw polls.

   * You say ``A louder voice does not make anyone more important than
     others'' when several of us put a great deal of time into
     explaining the flaws in your proposals in detail.

   * You say ``This is not an election'' when more than _two hundred_
     people state that they object to your proposals.

What's consistent is that you're discounting the views of people who
disagree with you. I call upon you to resign and find someone neutral to
serve as chair.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sun Feb 10 02:29: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 CAA03498
	for ; Sun, 10 Feb 2002 02:29:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZoK0-00082E-00
	for idn-data@psg.com; Sat, 09 Feb 2002 23:22:48 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZoK0-000828-00
	for idn@ops.ietf.org; Sat, 09 Feb 2002 23:22:48 -0800
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 XAA09048;
	Sat, 9 Feb 2002 23:22:45 -0800
Message-Id: <5.1.0.14.2.20020209231056.01f8d2c8@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Feb 2002 23:22:05 -0800
To: "D. J. Bernstein" 
From: Dave Crocker 
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Cc: idn@ops.ietf.org
In-Reply-To: <20020210065942.24959.qmail@cr.yp.to>
References: <008f01c1b10e$f2eef690$4407e29f@deng>
 <3052129.1013207733@localhost>
 <20020210015442.27325.qmail@cr.yp.to>
 <5.1.0.14.2.20020209184121.04002100@127.0.0.1>
 <20020210051440.2468.qmail@cr.yp.to>
 <07f701c1b1f7$a96b8940$1001000a@jamessonyvaio>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

(sorry.  meant to post no further notes on this, but Dan has decided to 
attack James.)


At 06:59 AM 2/10/2002 +0000, D. J. Bernstein wrote:
>What exactly has changed since then?

Repeated public discussion and review, and repeated IETF management review.


>The working group is _not_ the same as the set of people who show up at
>an IETF meeting.

And since no one has claimed otherwise, raising this point is not terribly 
relevant.


>I accuse you of bias in your procedures for evaluating consensus.

Well, yes, James has shown a major flaw in his management, although not the 
one Dan cites.  James and Marc have allowed far, far too much distraction 
and protraction, such as tolerating the sort of silliness that Dan is raising.

The real consensus was developed long ago.  However James and Marc desired 
to provide extra time to seek consensus with those unhappy at the dominant 
view.  Alas, all that has ensued from that kind effort has been to give 
this vocal minority more of a sense of credibility than they warrant.


>  You select procedures on the fly to support your position:

Dan has, as usual, asserted actions as personal when they were in fact 
subject to broad review, assistance, and agreement.  Dan does not want to 
acknowledge this clear fact, of course.

(And, by the way, variable consensus-assessment procedures are standard 
fare for the IETF.  They work well.  It's even in the formal rules, though 
Dan's selective citation effort managed to miss this point.)


>What's consistent is that you're discounting the views of people who 
>disagree with you.

Dan needs to stop accusing others of his own faults.

d/

----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sun Feb 10 05:56: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 FAA05091
	for ; Sun, 10 Feb 2002 05:56:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZrPf-000Azj-00
	for idn-data@psg.com; Sun, 10 Feb 2002 02:40:51 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZrPa-000Azd-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 02:40:46 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4Z2RyN1YgWuKuwCVQ0gMJHw==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GTAG4MJF; Sun, 10 Feb 2002 05:39:56 EST
To: phoffman@imc.org
Cc: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, erin@twnic.net.tw,
        fred@cisco.com, harald@alvestrand.no, htk@eecs.harvard.edu,
        iab@ISI.EDU, iesg@ietf.org, jet-member@nic.ad.jp, jseng@pobox.org.sg,
        lynn@icann.org, mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com,
        mouhamet@next.sn, narten@us.ibm.com, nordmark@eng.sun.com,
        paf@cisco.com, qhhu@public.bta.net.cn, sharil@cmc.gov.my,
        shkyong@kgsm.kaist.ac.kr, vcerf@mci.net, alanysho@hkdnr.net.hk,
        christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn, hlqian@cnnic.net.cn,
        hoho@iis.sinica.edu.tw, huangk@alum.sinica.edu, jasonho@umac.mo,
        lee@whale.cnnic.net.cn, mao@cnnic.net.cn, snw@twnic.net.tw,
        sstseng@twnic.net.tw, tsenglm@cc.ncu.edu.tw, whzhang@cnnnic.net.cn,
        wschen@twnic.net.tw, wuch@gate.sinica.edu.tw, yktham@umac.mo
Date: Sun, 10 Feb 2002 02:16:39 -0800
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Message-ID: <20020210.024958.-446323.1.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-9,11-27
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I just have to comment on your impression: 

It is not the whole picture!

> Due to the efforts of some CDNC members, the IETF is now well aware 
> of the "2^n" variant problem that is unique to the use of Han 
> characters in the Chinese language. Fortunately, using registration 
> guidelines will solve the problem. The only people seriously affected 
> by the size of DNS zones created by the "2^n" problem will be very 
> large, flat zones such as those managed by CDNC members, but they 
> are  able to compensate for the size of zones with no changes to the
DNS 
> protocols.

> Of course, the character variant problem exists in many different 
> languages, not just in Chinese. Because of this, each registry or 
> zone that includes IDN names needs to make decisions about name 
> equivalence (and therefore multiple registrations) before they enter 
> any IDN names into their zone. Based on this input during Working 
> Group last call from the CDNC, it seems clear that we need to 
> explain 
> these points more in the IDNA document.
> 

This provide another form of fragmented IDN.

Thanks.

Liana 



From owner-idn@ops.ietf.org  Sun Feb 10 08:51: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 IAA06402
	for ; Sun, 10 Feb 2002 08:51:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZuGN-000Dur-00
	for idn-data@psg.com; Sun, 10 Feb 2002 05:43:27 -0800
Received: from gate.sinica.edu.tw ([140.109.4.130])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZuGL-000Duf-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 05:43:26 -0800
Received: from cat (140-109-225-83.adsl.sinica.edu.tw [140.109.225.83])
	by gate.sinica.edu.tw (8.11.3/8.11.3) with SMTP id g1ADhPs28789
	for ; Sun, 10 Feb 2002 21:43:25 +0800 (CST)
Message-ID: <000501c1b238$dd69b690$53e16d8c@cat>
From: "cis.nctu.edu.tw" 
To: 
Subject: [idn] Please do not pass an IDN document which you know will cause conflicts and chaos
Date: Sun, 10 Feb 2002 21:42:00 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C1B27B.C57957F0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C1B27B.C57957F0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable


I' ve recently come to know that IETF is about to release drafts on IDN =
standards, and to my regret, I found that the document does not solve =
problems for Chinese domain names. and this defect in your drafts will =
result conflicts and chaos for internet users of Han characters, namely =
Chinese, Korean and Japanese, and the effect is international because =
users of these languages are all over the world.=20

It is important to know that while a certain character can have =
different appearance in Simplified Chinese and Traditional Chinese =
Character forms even though they are actually same words with the same =
meaning; at the same time, a certain character which might look exactly =
the same, but in fact are two different words with different meaning =
when applied to different languages such as Chinese and Japanese.

I believe that IETF bears great responsible in setting standards which =
will bring order to the internet world, and any document which might =
cause disorder, should be carefully reconsidered before =
release.Therefore, before IETF can resolve this problem and identify one =
mechanism which can differentiate these delicate language difference, =
IETF should not pass the document which would apply Unicode for IDN =
resolution, because this irresponsible decision is going to cause =
conflicts and chaos in DN registration policy and DRP worldwide.

Chih-Chung Huang

------=_NextPart_000_0003_01C1B27B.C57957F0
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable









 
I' ve recently come to know that IETF is about to =
release=20
drafts on IDN standards, and to my regret, I found that the document =
does not=20
solve problems for Chinese domain names. and this defect in your drafts =
will=20
result conflicts and chaos for internet users of Han characters, namely =
Chinese,=20
Korean and Japanese, and the effect is international because users of =
these=20
languages are all over the world. 

It is important to know that =
while a=20
certain character can have different appearance in Simplified Chinese =
and=20
Traditional Chinese Character forms even though they are actually same =
words=20
with the same meaning; at the same time, a certain character which might =
look=20
exactly the same, but in fact are two different words with different =
meaning=20
when applied to different languages such as Chinese and =
Japanese.

I=20
believe that IETF bears great responsible in setting standards which =
will bring=20
order to the internet world, and any document which might cause =
disorder, should=20
be carefully reconsidered before release.Therefore, before IETF can =
resolve this=20
problem and identify one mechanism which can differentiate these =
delicate=20
language difference, IETF should not pass the document which would apply =
Unicode=20
for IDN resolution, because this irresponsible decision is going to =
cause=20
conflicts and chaos in DN registration policy and DRP=20
worldwide.

Chih-Chung Huang

------=_NextPart_000_0003_01C1B27B.C57957F0--




From owner-idn@ops.ietf.org  Sun Feb 10 08: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 IAA06432
	for ; Sun, 10 Feb 2002 08:55:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZuMp-000E2Q-00
	for idn-data@psg.com; Sun, 10 Feb 2002 05:50:07 -0800
Received: from mail.cis.nctu.edu.tw ([140.113.23.5])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZuMn-000E1z-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 05:50:05 -0800
Received: (from root@localhost)
	by mail.cis.nctu.edu.tw (8.11.6/8.11.6) id g1ADo3Y22663
	for idn@ops.ietf.org; Sun, 10 Feb 2002 21:50:03 +0800 (CST)
	(envelope-from gis84527@mail.cis.nctu.edu.tw)
Received: from cissol1.cis.nctu.edu.tw (gis84527@cissol1 [140.113.23.101])
	by mail.cis.nctu.edu.tw (8.11.6/8.11.6) with ESMTP id g1ADo2922640
	for ; Sun, 10 Feb 2002 21:50:02 +0800 (CST)
	(envelope-from gis84527@mail.cis.nctu.edu.tw)
Received: (from gis84527@localhost)
	by cissol1.cis.nctu.edu.tw (8.10.2+Sun/8.10.2) id g1ADnwm13855
	for idn@ops.ietf.org; Sun, 10 Feb 2002 21:49:58 +0800 (CST)
Date: Sun, 10 Feb 2002 21:49:58 +0800 (CST)
From: 8423527 
Message-Id: <200202101349.g1ADnwm13855@cissol1.cis.nctu.edu.tw>
To: idn@ops.ietf.org
Subject: [idn] Please do not pass an IDN document which you know will cause conflicts and chaos
X-Virus-Scanned: by AMaViS perl
Sender: owner-idn@ops.ietf.org
Precedence: bulk

I' ve recently come to know that IETF is about to release drafts on IDN standards, and to my regret, I found that the document does not solve problems for Chinese domain names. and this defect in your drafts will result conflicts and chaos for internet users of Han characters, namely Chinese, Korean and Japanese, and the effect is international because users of these languages are all over the world.

It is important to know that while a certain character can have different appearance in Simplified Chinese and Traditional Chinese Character forms even though they are actually same words with the same meaning; at the same time, a certain character which might look exactly the same, but in fact are two different words with different meaning when applied to different languages such as Chinese and Japanese.

I believe that IETF bears great responsible in setting standards which will bring order to the internet world, and any document which might cause disorder, should be carefully reconsidered before release.Therefore, before IETF can resolve this problem and identify one mechanism which can differentiate these delicate language difference, IETF should not pass the document which would apply Unicode for IDN resolution, because this irresponsible decision is going to cause conflicts and chaos in DN registration policy and DRP worldwide.





From owner-idn@ops.ietf.org  Sun Feb 10 08:56: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 IAA06452
	for ; Sun, 10 Feb 2002 08:56:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZuGN-000Duq-00
	for idn-data@psg.com; Sun, 10 Feb 2002 05:43:27 -0800
Received: from gate.sinica.edu.tw ([140.109.4.130])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZuGL-000Due-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 05:43:25 -0800
Received: from cat (140-109-225-83.adsl.sinica.edu.tw [140.109.225.83])
	by gate.sinica.edu.tw (8.11.3/8.11.3) with SMTP id g1ADhOs28782
	for ; Sun, 10 Feb 2002 21:43:24 +0800 (CST)
Message-ID: <000401c1b238$dcef7d80$53e16d8c@cat>
From: "cis.nctu.edu.tw" 
To: 
Subject: [idn] PROTEST! RESCUE CHINESE DOMAIN NAMES
Date: Sun, 10 Feb 2002 21:41:27 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C1B27B.B19EF230"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C1B27B.B19EF230
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable


PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han character variants, also known as equivalent Chinese =
characters, exists in Unicode. A Chinese domain name thus usually has =
many different Unicode representations. As Unicode evolves, more CJK Han =
characters are added to Unicode. It also increases the number of =
variants of a character and the number of characters with variants, and =
thus the number of Unicode representations per Chinese domain name. =20

Though it meets the needs for internationalized domain name of those =
people who uses phonetic characters. However, a Chinese domain name =
service based on IDN WG technology is defective.

We urge the working group to seriously take these cultural differences =
into account. Do not finalize IDN documents without minimizing their =
negative impacts against Chinese domain names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!






Chih-Chung Huang

------=_NextPart_000_0003_01C1B27B.B19EF230
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable









 
PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han =
character=20
variants, also known as equivalent Chinese characters, exists in =
Unicode. A=20
Chinese domain name thus usually has many different Unicode =
representations. As=20
Unicode evolves, more CJK Han characters are added to Unicode. It also =
increases=20
the number of variants of a character and the number of characters with=20
variants, and thus the number of Unicode representations per Chinese =
domain=20
name.  

Though it meets the needs for internationalized =
domain name=20
of those people who uses phonetic characters. However, a Chinese domain =
name=20
service based on IDN WG technology is defective.

We urge the =
working=20
group to seriously take these cultural differences into account. Do not =
finalize=20
IDN documents without minimizing their negative impacts against Chinese =
domain=20
names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND=20
TAIWAN!






Chih-Chung Huang

------=_NextPart_000_0003_01C1B27B.B19EF230--




From owner-idn@ops.ietf.org  Sun Feb 10 09:45: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 JAA06735
	for ; Sun, 10 Feb 2002 09:45:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zv62-000Epe-00
	for idn-data@psg.com; Sun, 10 Feb 2002 06:36:50 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zv60-000EpY-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 06:36:49 -0800
Received: from jamessonyvaio (unknown [203.121.53.147])
	by mail.i-dns.net (Postfix) with SMTP id E45AEFFC24
	for ; Sun, 10 Feb 2002 22:35:48 +0800 (SGT)
Message-ID: <000b01c1b240$6026c850$933579cb@jamessonyvaio>
From: "James Seng/Personal" 
To: 
References: <008f01c1b10e$f2eef690$4407e29f@deng> <3052129.1013207733@localhost> <20020210015442.27325.qmail@cr.yp.to> <5.1.0.14.2.20020209184121.04002100@127.0.0.1> <20020210051440.2468.qmail@cr.yp.to> <07f701c1b1f7$a96b8940$1001000a@jamessonyvaio> <20020210065942.24959.qmail@cr.yp.to>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Sun, 10 Feb 2002 22:36:39 +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 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: 7bit

I am not responding to this mail because it will only divert into
another series of discussions on your opinion of IDNA, which the group
(and the chairs) have heard before and already noted.

I stand by my action. Lets other be the judge.

-James Seng

----- Original Message -----
From: "D. J. Bernstein" 
To: 
Sent: Sunday, February 10, 2002 2:59 PM
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)


> James Seng/Personal writes:
> > 1. We did not move IDNA forward in May/June 2001
>
> What exactly has changed since then? You've been tweaking details. We
> were objecting to fundamental flaws in the IDNA design. Those flaws
are
> still present in the current IDNA design. We continue to object to
them.
>
> > 2. The minutes from SLC have been send to the group and for
comments.
> >    Action items from the SLC include consensus to move IDNA for Last
> >    Call.
>
> The working group is _not_ the same as the set of people who show up
at
> an IETF meeting. See RFC 2418, section 3.2:
>
>    Electronic mail permits the widest participation ... The WG must
>    ensure that its process does not serve to exclude contribution by
>    email-only participants ... Internet email discussion is possible
for
>    a much wider base of interested persons than is attendance at IETF
>    meetings, due to the time and expense required to attend.
>
> I accuse you of bias in your procedures for evaluating consensus. You
> select procedures on the fly to support your position:
>
>    * You run straw polls that you think will support IDNA, and you
>      refuse to run other straw polls.
>
>    * You say ``A louder voice does not make anyone more important than
>      others'' when several of us put a great deal of time into
>      explaining the flaws in your proposals in detail.
>
>    * You say ``This is not an election'' when more than _two hundred_
>      people state that they object to your proposals.
>
> What's consistent is that you're discounting the views of people who
> disagree with you. I call upon you to resign and find someone neutral
to
> serve as chair.
>
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
>
>




From owner-idn@ops.ietf.org  Sun Feb 10 10:35: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 KAA07176
	for ; Sun, 10 Feb 2002 10:35:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZvpQ-000Ffj-00
	for idn-data@psg.com; Sun, 10 Feb 2002 07:23:44 -0800
Reply-To: 
From: 
To: 
Subject: [idn] Re: Thanks you all replying "a queston"...May I conclude that?
Date: Sun, 10 Feb 2002 22:14:51 +0800
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Content-Transfer-Encoding: 8bit

Sorry, dear all members, please forgive my poor English.

I think, the sentence
"Frankly speaking, I never notice there is difference, and think they
are
different."
should be
"Frankly speaking, neither I notice there is difference, nor think they
are
different."


----- Original Message -----
From: 
To: 
Sent: Sunday, February 10, 2002 9:05 PM
Subject: Thanks you all replying "a queston"...May I conclude that?


> Thanks all people on the mailing list.
>
> After reading the mails these days, i learn a lot.
>
> Thanks to Kenneth Whistler and Chun-Hsin Wu on thread "Inputting mixed
> SC/TC".
> It is demoed how Chinese characters are inputted in most widely used
OS.
And
> show how they are used even the fonts looked different with defined in
> UNICODE. We
> uses these fonts, and we never consider they are wrong even if
"U+6DF8"
and
> "U+6E05"
> are displayed in the same shape.
>
> Frankly speaking, I never notice there is difference, and think they
are
> different
> characters. Of course, it is outside the scope of UNICODE and computer
> display, and
> IDN.......:-(
>
> Especially thanks to James Seng, and Adam M. Costello. You teach me a
fact:
> Chinese should be re-educated to learn how Chinese characters are used
as
an
> Identifier
> before we can use IDN and then we can survive in the "International"
> Internet.  :-(
>
> As there is no objection about the story I've mentioned in my last
mail.
So
> can I conclude below?
> In the IDNA architecture, if Chinese want their 2^n names,
> a) register all allowed names (... I don't know who decide which are
allowd,
> which are not?? )
> b) configure correctly the registered names on related servers
> c) For those not-allowed names, apologize to their customers. Prepare
> answers, especially for
> characters that have different code points, and displayed in the same
shape.
>
> And then, if the CDN of www.csie.ntu.edu.tw is "網
.資訊系.台灣大學.教育
部.
> 台灣"
> i.e., "U+7DB2 U+9801.U+8CC7 U+8A0A U+7CFB.U+81FA U+7063 U+5927
U+5B78.U+6559
> U+80B2 U+90EB.U+81FA U+7063",
> we find that in the name, U+7DB2, U+9801, U+8CC7, U+8A0A, U+81FA,
U+7063,
> U+5B78, U+6559 have at least 2 variants, and U+81FA, U+7063 are used
twice,
> and
> there are total 2^10 names.
>
> WooWoo, What a great number it is.
>
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Sun Feb 10 10:37: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 KAA07197
	for ; Sun, 10 Feb 2002 10:37:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zvor-000Fel-00
	for idn-data@psg.com; Sun, 10 Feb 2002 07:23:09 -0800
From: 
To: 
Subject: [idn] Thanks you all replying "a queston"...May I conclude that?
Date: Sun, 10 Feb 2002 21:05:28 +0800
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Content-Transfer-Encoding: 8bit

Thanks all people on the mailing list.

After reading the mails these days, i learn a lot.

Thanks to Kenneth Whistler and Chun-Hsin Wu on thread "Inputting mixed
SC/TC".
It is demoed how Chinese characters are inputted in most widely used OS.
And
show how they are used even the fonts looked different with defined in
UNICODE. We
uses these fonts, and we never consider they are wrong even if "U+6DF8"
and
"U+6E05"
are displayed in the same shape.

Frankly speaking, I never notice there is difference, and think they are
different
characters. Of course, it is outside the scope of UNICODE and computer
display, and
IDN.......:-(

Especially thanks to James Seng, and Adam M. Costello. You teach me a
fact:
Chinese should be re-educated to learn how Chinese characters are used
as an
Identifier
before we can use IDN and then we can survive in the "International"
Internet.  :-(

As there is no objection about the story I've mentioned in my last mail.
So
can I conclude below?
In the IDNA architecture, if Chinese want their 2^n names,
a) register all allowed names (... I don't know who decide which are
allowd,
which are not?? )
b) configure correctly the registered names on related servers
c) For those not-allowed names, apologize to their customers. Prepare
answers, especially for
characters that have different code points, and displayed in the same
shape.

And then, if the CDN of www.csie.ntu.edu.tw is "網
.資訊系.台灣大學.教育部.
台灣"
i.e., "U+7DB2 U+9801.U+8CC7 U+8A0A U+7CFB.U+81FA U+7063 U+5927
U+5B78.U+6559
U+80B2 U+90EB.U+81FA U+7063",
we find that in the name, U+7DB2, U+9801, U+8CC7, U+8A0A, U+81FA,
U+7063,
U+5B78, U+6559 have at least 2 variants, and U+81FA, U+7063 are used
twice,
and
there are total 2^10 names.

WooWoo, What a great number it is.




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Sun Feb 10 10:39: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 KAA07219
	for ; Sun, 10 Feb 2002 10:39:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZvuQ-000Fmb-00
	for idn-data@psg.com; Sun, 10 Feb 2002 07:28:54 -0800
Received: from smtp14.singnet.com.sg ([165.21.6.34])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZvuO-000FmV-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 07:28:53 -0800
Received: from jamessonyvaio (hs06172.singnet.com.sg [165.21.198.207])
	by smtp14.singnet.com.sg (8.12.2/8.12.2) with SMTP id g1AFSeRH021611
	for ; Sun, 10 Feb 2002 23:28:50 +0800
Message-ID: <027f01c1b247$b494d740$cfc615a5@jamessonyvaio>
From: "James Seng/Personal" 
To: 
Subject: [idn] 300 protest mail
Date: Sun, 10 Feb 2002 23:28:59 +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 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: 7bit

we just reach another new record, 300 protest mails is recorded as of
today, many of which is dup'ed. *cheers*

btw, "dup" => same email address (sender) but different content (there
are two mail template).

will provide last and more complete summary tomorrow 11th feb.

james




From owner-idn@ops.ietf.org  Sun Feb 10 11:30: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 LAA07775
	for ; Sun, 10 Feb 2002 11:30:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZwlN-000GmG-00
	for idn-data@psg.com; Sun, 10 Feb 2002 08:23:37 -0800
Received: from mx-out.daemonmail.net ([209.75.5.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZwlM-000GmA-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 08:23:36 -0800
Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1])
	by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id IAA36506;
	Sun, 10 Feb 2002 08:22:23 -0800 (PST)
	(envelope-from rosenne@qsm.co.il)
Received: from qsm3 (qsm3 [212.150.96.239])
	by mail.qsm.co.il with ESMTP id KO90qSF2
	Sun, 10 Feb 2002 08:22:09 -0700 (PST)
From: "Jonathan Rosenne" 
To: "'James Seng/Personal'" , 
Subject: RE: [idn] last call reminder - Hebrew
Date: Sun, 10 Feb 2002 18:21:43 +0200
Message-ID: <000001c1b24f$0f9b96e0$eb0110ac@qsm3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <004501c1ad20$07132b20$0d01000a@jamessonyvaio>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Regarding Hebrew:

The proposals are inadequate for Hebrew domain names as follows:

Hebrew vowel signs etc. (points) should be stripped (mapped out) by
nameprep. Unicodes 05B0 to 05B9, 05BB to 05BD, 05BF, 05C1, 05C2, 05C4.

Explanation: These marks in Hebrew are optional, one may or may not use
them, for example to clarify a possible ambiguity. They should be
allowed but they should be ignored. Their presence or absence should not
make two host names different.

Note: This implies that FB2A to FB4e and FB1D should be mapped to their
base letters in nameprep.

Jony

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] 
> On Behalf Of James Seng/Personal
> Sent: Monday, February 04, 2002 4:03 AM
> To: idn@ops.ietf.org
> Subject: [idn] last call reminder
> 
> 
> This is a reminder that the working group last call for
> 
> 1. Internationalizing Domain Names in Applications (IDNA) 
> http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt
> 
> 2. Stringprep Profile for Internationalized Host Names 
> http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-07
.txt

3. Punycode version 0.3.3
http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt

4. Preparation of Internationalized Strings ("stringprep")
http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt

will end on Feb 11th 2002, 23h59m GMT-5.

-James Seng







From owner-idn@ops.ietf.org  Sun Feb 10 11:59: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 LAA08062
	for ; Sun, 10 Feb 2002 11:59:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZxE9-000HK1-00
	for idn-data@psg.com; Sun, 10 Feb 2002 08:53:21 -0800
Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZxE8-000HJv-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 08:53:20 -0800
Received: from mailc.telia.se (localhost [127.0.0.1])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g1AGrHn25308
	for ; Sun, 10 Feb 2002 17:53:17 +0100 (MET)
Received: from trab.se (terra.malmo.trab.se [131.115.48.22])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g1AGrFZ25298;
	Sun, 10 Feb 2002 17:53:15 +0100 (MET)
Message-ID: <3C66A551.231AE0E6@trab.se>
Date: Sun, 10 Feb 2002 17:52:33 +0100
From: Dan Oscarsson 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org, ehall@ehsco.com
Subject: Re: [idn] WG last call documents
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


>From: "Eric A. Hall" 

>
>draft-hoffman-stringprep-00.txt:
>draft-ietf-idn-nameprep-07.txt:
>
> | Stringprep Profile for Internationalized Host Names
>
>Since this profile is specifically for host names, all of the rules that
>apply to hostnames should be placed here. 

From what I could read the title is wrong.
It should be: Stringprep Profile for Domain Names.

To make this work, we need ONE stringprep plus ACE.
One that can be used on ALL labels in DNS.
To have different profiles for different labels would be
a mess. Well, you could mark each profile+ACE with a
different ACE prefix to indicate profile used but having
lots of different encodings/profiles have so far proven to be
a big difficulty for programmers to handle.

A part from the stringprep plus ACE we need rules on what
characters should (or must) be used on different things.
For example a host name should be printable letters
with intermixed printable separators (and no repeated ones).
An other rule is applied on e-mail names.
The above rules on what character are allowed does
only belong in applications, not at DNS protocol level.


>
>
>draft-ietf-idn-idna-06.txt:
>

> | 3. Requirements
>
> | IDNA conformance means adherence of the following three rules:
>
> | 1) Whenever a domain name is put into a generic domain name slot,
> | every label MUST contain only ASCII characters. 
>
>"generic domain name slot" should be substituted with "STD13 slot". There
>is no reason whatsoever that application protocols cannot exchange IDNs or
>IHNs in whatever form they wish.

I agree. Also the term "generic" means anything and that would mean
non-ASCII characters.

>
> | 2) ACE labels SHOULD be hidden from users whenever possible. 
>
>I have argued against this before and I will do so again now.
>
>Should WHOIS servers perform this conversion on output (email addresses
>and nameservers) since it is likely to be displayed to a user? Should an
>email client perform conversion on a message? Every protocol and
>data-format has unique considerations. Making blanket statements like this
>is harmful.

I agree in that the WHOIS server should output names using the character
context of it's protocol. We need a WHOIS protocol that uses UTF-8 and
when it does, ACE labels may not be transmitted over that protocol.

But a WHOIS client should always decode ACE data and display them using
the
local character set.

There should also be a requirement that a protocol using UTF-8 should
never send data using ACE so the receiver does not have to handle
the extra work of checking for embedded ACE.


>
> | B. Design philosophy
>
>What value does this section provide? This text is religion not science,
>seeing as how it omits key counter-arguments, namely that there are
>hundreds if not thousands of applications for every DNS server, so
>upgrading servers in addition to applications represents an incremental
>cost (rather than the "The cost of implementing IDN may thus be much
>lower, and the speed of implementation could be much higher" erroneous
>opinion).

I agree. Remove this section. It contains too much religion.


>
>
>General comments:

>"Adam M. Costello" wrote in <20020207043706.GA7193@nicemice.net>:
>
>> There are some code points that are prohibited in host names, but not
>> in all textual domain names.  The underscore is the best example.
>> These prohibitions belong in ToASCII.
>
>I disagree with this for a couple of reasons. First of all, these
>exceptions are associated with protocol identifier labels, which are not
>hostnames. Secondarily, "protocol identifiers" are
>generally considered as protocol operators which do not need to be
>internationalized (therefore never needing anything but ASCII). 

Depend on who is expected to view protocol identifiers and what
programs using the protocol expects.
Protocol identifiers can have non-ASCII characters.

>SRV owner labels are protocol elements, not text. They should never go
>through any conversion.

Why not. There can be non-ASCII SRV owner labels. As prople are afraid
the non-ASCII host names (which is also a type of protocol element)
can break applications they should be afraid that non-ASCII SRV owner
labels could break applications.

It is easiest if at the DNS protocol level ONE type of ACE (and
stringprep)
is used on all labels. The the lowest level can all use the same
code. Higher levels in applications can put additional constraints
on the content of labels. By having the lowest level as broad as
possible and as few as possible constraints we have a good building
ground for the future. Otherwise we might just like to day with
this ugly "use only ASCII constraint" have to invent a new layer
on top of the old one to bypass the constraints.


>DJ Bernstein is right-on when he says that certs don't solve the spoofing
>problem. There is nothing preventing the wiley hacker from getting a cert
>for billg@micr0soft.com, and there would be nothing about that cert which
>would alert anybody that spoofing had occurred. In general terms, this
>means that I agree with DJB that the initial scope should be tightly
>controlled and slowly incremented. I think that this opinion was also
>expressed by J Klensin's solicitation for a "safe-set" and D Crocker's
>endorsement of a safe-set. This doesn't mean we all agree with DJB, but I
>think that in this case, he is probably correct.

Most of this burden is on the domain owners. Registration of bad type
of domains below .com should not be allowed. This includes names
like micr0soft.com and micorsoft.com which clearly never should
have been allowed.


-
One other thing. As the IDNA supporters think this idea will work fine
and the users will soon not have to see or write ACE names, there
should be a date on which this should be examined. If at that date
not most important software and protocols have been updated, IDNA
should be removed and replaced with something making people update
their software. UTF-8 would probably do that.
For example, at that date I expect to be able to write URLs in HTML
documents using the documents native character set.
The date should be fairely soon as the supporters of IDNA have said
this is quick. 2003-12-31 is acceptable.

   Dan



From owner-idn@ops.ietf.org  Sun Feb 10 12:49: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 MAA08680
	for ; Sun, 10 Feb 2002 12:49:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zy0u-000IHK-00
	for idn-data@psg.com; Sun, 10 Feb 2002 09:43:44 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zy0s-000IHD-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 09:43:42 -0800
Received: from iis.sinica.edu.tw (iists09 [140.109.21.220])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g1AHcfT08454;
	Mon, 11 Feb 2002 01:38:43 +0800 (CST)
Message-ID: <3C66B1C4.23A94DCC@iis.sinica.edu.tw>
Date: Mon, 11 Feb 2002 01:45:41 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: "John H. Jenkins" 
CC: Kenneth Whistler , idn@ops.ietf.org
Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
References: <13B4233A-1BF0-11D6-B3E1-003065F9CD7C@apple.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

"John H. Jenkins" gJG

>
> As Ken well knows.  It's a nasty, nasty problem in general, and one
> which
> Unicode is trying to address.  At its last meeting the UTC agreed to
> request that the IRG start to work on definitive variant data for the
> CJK
> repertoire of Unicode/10646.
>
> If there is any body in the IT standardization community which should
> own
> the problem, it's the IRG.  It's international, multilingual, and has
> the
> longest and best experience with the characters involved.

Hope that the Han variant problem can be solved in IRG. The people I
consulted are Prof. C.C. Hsieh of our institute and Chritian Wittern of
Kyoto University. They are both experts in Han variants. There is also
a online variant dictionary published by Ministry of Education, Taiwan.
In the past, the CCCII group of people also contributed enormous amount
of efforts on Han variants.

> >>
> >>   B. The move to Unicode implementations means that mingling
> >>      of traditional and simplified orthographies is easier.
> >>      In effect, users now have the rope to hang themselves,
> >>      if they so desire. Whereas, before, the constraints of
> >>      the deployment of IME's and fonts generally meant that
> >>      you couldn't easily mix SC/TC, even when the code page
> >>      nominally supported it.
> >>
> >
> > I would accept A with minor modification as follows. B is not true.
> >
>
> I would disagree here.  As you point out, Windows 2000 has the ability
> to
> mingle traditional and simplified orthographies because of Unicode 2.0.
> Mac OS X now has the problem, too, because of Unicode 3.1.  In the past
> on
> the Mac, if you wanted to do Japanese you used the Japanese "code page,"
> if you wanted to do traditional Chinese, you did the traditional Chinese
> "code page," and if you wanted to do simplified Chinese, you used the
> simplified Chinese "code page."  This inherent link between code page
> and
> nuanced version of a script was something Unicode intended to break.  In
> the past, one had to deliberately work to mix the two, and the mixture
> was
> generally obvious.  This isn't true now.

Thanks, I accept it. I am sorry that I didn't quite understand some English
sentences in statement B previously.

>
> > Without a internationalized dictionary for Han variants, the current
> > IDN proposals are bringing side-effects to users and holders of
> > domain names of Han characters.
> >
>
> I agree with Ken that it's not clear how *anything* could both include
> hanzi in IDN *and* be free from unpleasant side effects.

This is hard indeed. But, by decomposing name equivalence matching
function into the IDN protocol, registration policy and the recently
proposed IRNSS protocol, it is likely to minimized its unpleasant side
effects.

> >
> > I appreciate your loving for Japanese. But, if you do care about
> > Japanese, why did you ignore Chinese and Taiwanese, and perhaps
> > even more silent Japanese and Korean out there?
> >
>
> I'm sure it wasn't intentional.  I believe that Ken's point is that you
> can't do a Chinese-only solution here.  (And I'll naturally bring up the
> Cantonese speaking population of the world, as just adding to the mess.)

This is fine. But, I think you also understand. If having some people to
wait could help some other people from being damage, then we choose
to help, don't we?

>
>
> ==========
> John H. Jenkins
> jenkins@apple.com
> jenkins@mac.com
> http://homepage.mac.com/jenkins/




From owner-idn@ops.ietf.org  Sun Feb 10 12:51: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 MAA08700
	for ; Sun, 10 Feb 2002 12:51:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Zy2I-000IK2-00
	for idn-data@psg.com; Sun, 10 Feb 2002 09:45:10 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Zy2H-000IJv-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 09:45:09 -0800
Received: from iis.sinica.edu.tw (iists09 [140.109.21.220])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g1AHcST08380;
	Mon, 11 Feb 2002 01:38:28 +0800 (CST)
Message-ID: <3C66B1B7.1190D4B@iis.sinica.edu.tw>
Date: Mon, 11 Feb 2002 01:45:28 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Paul Hoffman / IMC 
CC: idn@ops.ietf.org, Elisabeth.Porteneuve@cetp.ipsl.fr,
        Marc.Blanchet@viagenie.qc.ca, ajm@icann.org, fred@cisco.com,
        harald@alvestrand.no, htk@eecs.harvard.edu, iab@isi.edu, iesg@ietf.org,
        jet-member@nic.ad.jp, jseng@pobox.org.sg, lynn@icann.org,
        mkatoh@mkatoh.net, mkatoh@wdc.fujitsu.com, mouhamet@next.sn,
        narten@us.ibm.com, nordmark@eng.sun.com, paf@cisco.com,
        sharil@cmc.gov.my, shkyong@kgsm.kaist.ac.kr, vcerf@mci.net,
        alanysho@hkdnr.net.hk, christine.tsang@hkdnr.net.hk, deng@cnnic.net.cn,
        hlqian@cnnic.net.cn, huangk@alum.sinica.edu, jasonho@umac.mo,
        lee@whale.cnnic.net.cn, mao@cnnic.net.cn, yktham@umac.mo
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>
							 <83129960.1012820475@localhost> 
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Paul Hoffman / IMC gJG

> Solving the Traditional-Simplified problem in the IDN protocol would
> have given more uniform results for users.

Agree. For example, LDH naming constraints are also built into the
DNS instead of registration policies which might vary from registry to
registry.

> The intense discussions
> over the past 18 months have shown that not only is it unlikely that
> there will ever be an IETF-based solution, and it has also become
> clear that a registration-based solution will likely give Chinese
> users more sensible naming that anything than the IETF could
> standardize.

A written document presenting detailed ideas would be helpful for
further discussions. I appreciate it if you could give a pointer to
one such document.

But, I am not sure whether you're referring to a global registration
policy of equivalent names based on Han characters, or various
inconsistent registration policies  among all the registries including
TLD, SLD, etc.?

A hybrid approach combining both IDN protocol and registration
policy is indeed an effective approach for the Chinese domain name
problem. Without implementing basic equivalence matching function
in IDN protocol, I am not sure if  registration policy along would make
sense.

Chinese  domain names service is not only provided by CNNIC,
KRNIC, JPNIC, and TWNIC, but is also provided by other ccTLD and
gTLD. Second level domain name holders can also develop their cDN
registry business by selling the third level names to other parties.
Thus,
it is essential to build a standard Han variant table into the IDN
protocol
so that users are guaranteed to receive consistent resolution of Chinese
domain names independent of the many registries. We also believe that
the developing IRNSS protocol will add more equivalence matching
capabilities to Chinese domain names, especially for those with context
sensitive variants or language-specific variants.

We believe that with international collaboration, there is an opportunity

to develop a more reasonable domain name technology. Please do not
rush into a standard to allow registries to dump premature products
into Chinese Internet community.

> For example, in the IDN WG, the proposals from CDNC
> members only addressed part of the Traditional-Simplified problem
> (the 1:1 mapping), while the registration solution can address all of
> the problem in a manner that will help Chinese users.

I understand that the 1:1 mapping table does not solve all the problems.
But, I am not sure if, "the" registration solution had ever been
proposed,
and it's going to solve all the problems.

> Due to the efforts of some CDNC members, the IETF is now well aware
> of the "2^n" variant problem that is unique to the use of Han
> characters in the Chinese language. Fortunately, using registration
> guidelines will solve the problem. The only people seriously affected
> by the size of DNS zones created by the "2^n" problem will be very
> large, flat zones such as those managed by CDNC members, but they are
> able to compensate for the size of zones with no changes to the DNS
> protocols.

There is obviously serious scalability problem associated with this
large,
flat zone solution. Though it seems to work fine for the time being. But,

its management is complicated. Furthermore, with various dictionaries
of Han variants,  registries may choose to adopt different policy of name

equivalence.  Consistent resolution of domain names is thus hard to
maintain among the registries unless character variant equivalence
matching is part of the IDN protocol.

Without supports in IDN protocol, do you have a feasible solution to
mandate a consistent registration policy on Han characters among all
registries interested in commercializing Chinese domain names, including
TLD, SLD, etc?


> Of course, the character variant problem exists in many different
> languages, not just in Chinese. Because of this, each registry or
> zone that includes IDN names needs to make decisions about name
> equivalence (and therefore multiple registrations) before they enter
> any IDN names into their zone.

If you mean to say that each registry may decide its own name
equivalence, then you are wrong. Language is international and thus
name equivalence MUST be consistent among all registries.

> Based on this input during Working
> Group last call from the CDNC, it seems clear that we need to explain
> these points more in the IDNA document.

No, explanations are not good enough. The IDN protocol has serious
roblems in dealing with Han ideograph. We need to pay more attention
on those problems.

>
> --Paul Hoffman, Director
> --Internet Mail Consortium




From owner-idn@ops.ietf.org  Sun Feb 10 13:14: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 NAA08836
	for ; Sun, 10 Feb 2002 13:14:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZyKT-000IkM-00
	for idn-data@psg.com; Sun, 10 Feb 2002 10:03:57 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZyKS-000Ik9-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 10:03:56 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55020; Sun, 10 Feb 2002 12:03:18 -0600
Message-ID: <3C66B609.7A538AC7@ehsco.com>
Date: Sun, 10 Feb 2002 12:03:53 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@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:

> From what I could read the title is wrong.
> It should be: Stringprep Profile for Domain Names.
> 
> To make this work, we need ONE stringprep plus ACE.
> One that can be used on ALL labels in DNS.

We have been through this subject many times. STD13 binary domain names
and i18n host names are fundamentally incompatible. One specification will
not suffice.

> To have different profiles for different labels would be
> a mess. Well, you could mark each profile+ACE with a
> different ACE prefix to indicate profile used but having
> lots of different encodings/profiles have so far proven to be
> a big difficulty for programmers to handle.

I disagree. IDNA only needs to perform encoding and decoding, it doesn't
need to validate the domain names. Validation has ALWAYS been performed by
the participating applications, and has NEVER been performed by the
resolver. There is no reason why a codec should perform this validation.
The profiles are/should-be for the benefit of the applications, the
protocol designers and the data-format designers. The codec should just
convert them.

> I agree in that the WHOIS server should output names using the
> character context of it's protocol.

Are you sure the server should do this and not the client? Well, what if
the "client" is TELNET, should TELNET always do it?

The point here is that EVERY network service has its own considerations.
Demanding that all services implement a user-level feature is absurd. It's
as ridiculous as saying that all text MUST be white-on-black from this
moment forward.

The outcome of this mandate is that every existing specification is made
obsolete and non-compliant. BY A DRAFT! It's arrogant and ignorant of the
ramifications that every network service has different issues that have to
be worked through. Completely absurd.

> Protocol identifiers can have non-ASCII characters.

/etc/services cannot be expected to hold UTF-8 on all Internet systems

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Sun Feb 10 14:28: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 OAA09641
	for ; Sun, 10 Feb 2002 14:28:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ZzWl-000KNI-00
	for idn-data@psg.com; Sun, 10 Feb 2002 11:20:43 -0800
Received: from spider.nic-se.se ([212.247.3.67])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ZzWk-000KNC-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 11:20:42 -0800
Received: from localhost (dufberg@localhost)
	by spider.nic-se.se (8.11.1/8.11.1) with ESMTP id g1AJKVc01104;
	Sun, 10 Feb 2002 20:20:31 +0100 (CET)
X-Authentication-Warning: spider.nic-se.se: dufberg owned process doing -bs
Date: Sun, 10 Feb 2002 20:20:31 +0100 (CET)
From: Mats Dufberg 
To: Elliotte Rusty Harold 
cc: 
Subject: Re: [idn] Re: Unicode and Security
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 Feb 7, 2002, 12:22 (-0500) Elliotte Rusty Harold  For the sake of argument, let's call the company they work at
> Microsoft, but this attack could hit most companies with a .com
> address. Let's say I register microsoft.com, only the fifth letter
> isn't a lower-case Latin o. It's actually a lower case Greek omicron.
> I then forge a believable letter from alice@microsoft.com to
> bob@microsoft.com saying "Can you please update me on your budget?"
> Bob, noticing that the e-mail appears to come from Alice, whom he
> knows and trusts, fires off a reply with his confidential
> information. Only it doesn't go to Alice. It goes to me. I can then
> reply to Bob, asking for clarification or more details. I can ask him
> to attach the latest build of his software. I can carry on a
> conversation in which Bob believes me to be Alice and spills his
> guts. This is very, very bad.
(...)
> Specifying requirements for internationalized domain names does not
> itself raise any new security issues. However, any change to the DNS
> MAY affect the security of any protocol that relies on the DNS or on
> DNS names. A thorough evaluation of those protocols for security
> concerns will be needed when they are developed. In particular, IDNs
> MUST be compatible with DNSSEC and, if multiple charsets or
> representation forms are permitted, the implications of this
> name-spoof MUST be throughly understood.

DNSsec is compatible with ACE encoded IDN's. But the DNSsec keys and
signatures will be based on the ACE encoded domain, not the native IDN
domain.

Bob will not be helped by DNSsec in your scenario. Bob has been fooled to
use another mail domain, and that is beyond the scope of DNSsec.



Mats

----------------------------------------------------------------------
Mats Dufberg 
----------------------------------------------------------------------





From owner-idn@ops.ietf.org  Sun Feb 10 15:38: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 PAA10456
	for ; Sun, 10 Feb 2002 15:38:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a0Yw-000LsW-00
	for idn-data@psg.com; Sun, 10 Feb 2002 12:27:02 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a0Yv-000Ls9-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 12:27:01 -0800
Received: from iis.sinica.edu.tw (ists12 [140.109.21.223])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g1AKM1T04115;
	Mon, 11 Feb 2002 04:22:01 +0800 (CST)
Message-ID: <3C66D80D.1E98AD6D@iis.sinica.edu.tw>
Date: Mon, 11 Feb 2002 04:29:01 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Paul Hoffman / IMC 
CC: idn@ops.ietf.org
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	
		 <83129960.1012820475@localhost> 
		 <3C6494D9.988C9CBA@iis.sinica.edu.tw> 
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Paul Hoffman / IMC gJG

> >we have no way to depend on the courtesy of internationalized
> >companies
> >to make registration policies being friendly to language communities
> >including Chinese
>
> Correct.
>
> >who will be most seriously damaged by the decision of the WG.

>
> You have never given any justification for that assumption. In fact,
> later in your message you show that there are solutions to the
> problem.

No! This is misleading. Please refer to later part of this message.

> >  It would be
> >a pity
> >if we could not prevent greedy business from dumping defective domain
> >name products
> >into Chinese community.
>
> Then you should work to prevent it for your community. The IETF has
> absolutely no control over the products that use the standards we
> produce. Everyone knows that.

I have to reiterate, this situation comes from IDN protocol because it
adopts Unicode. Because the IDN protocol does not have the capability
to handle character model of Han characters in a proper way as it does
for some other languages, thus it is an incomplete solution. The
negative
side-effects on Chinese Internet community comes from this
incompleteness.

> >  We definitely are positive for your efforts in
> >bring up a solution
> >that solves DN problem for many languages. But, please do not force the
> >Chinese
> >community to be the victim of the side-effect.
>
> The IETF could not force such a thing, and obviously does not want to do so.

Are you saying that IETF does not care if a WG is providing an
incomplete 
solution to the Internet community?

> >  > Of course, CDNC members would like to maximize their
> >>  financial gain in registration, but the concern of the IETF is always
> >>  towards helping users. There is a huge different between "cannot be
> >>  solved" and "it will cost a small number of organizations a lot of
> >>  money".
> >
> >This is also interesting. As far as I know, TWNIC has their social
> >responsibily
> >in our country. There major concern for TWNIC to work with IDN WG is
> >consumer
> >protection. The reason why they work on TC/SC, is that we all aware the
> >lack
> >of an international standard on Han variants which we could use to
> >convince the
> >WG to pay attention.

You didn't answer the question. Who do you call in specific is trying to
maximize their financial gain? What is your evidence before making
these interesting comments?

>
> That work, which was done by CNNIC starting a year ago, was
> successful. The WG now understands the scope of the problem. We also
> understand what it would take to solve the problem in the IDN
> standards or in a registration solution. (I don't consider the spam
> and technically misleading messages that TWNIC has been sending for
> the last two weeks to be constructive work on TC/SC.)

Those messages are not sent by TWNIC.  James replied to each of
the protest emails to confirm the existence and willingness of the
senders,
didn't he? Do not accuse people for something they did not do. Do you
intend to mislead the WG to wrong conclusions? I believe this is a
mistake.

>
>
> >  Thus TC/SC becomes the best hope because it's
> >something
> >exists for more than 50 years. If the working group could adopt it, then
> >at least this is
> >something for all registries to restrict their name space a little bit
> >and not too make
> >too much trouble to Chinese community.
>
> We fully agree here. However, in order for the WG to adopt it, we
> need an Internet Draft that contains a protocol that can be used in
> the IETF. So far, no such Internet Draft has appeared, even after
> lots of strong efforts of CNNIC. Further, in recent private
> conversations, TWNIC has told people in the IETF that they don't
> believe such a draft is possible. So you are asking the WG to adopt
> something that you believe it cannot.

But, isn't it one of the functions of stringprep? So, it sounds like you
are admitting that stringprep is incomplete?

> --Paul Hoffman, Director
> --Internet Mail Consortium

Jan-Ming Ho, PhD
Research Fellow and Deputy Director
Institute of Information Science
Academia Sinica



From owner-idn@ops.ietf.org  Sun Feb 10 16:40: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 QAA11166
	for ; Sun, 10 Feb 2002 16:40:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a1bc-000NTx-00
	for idn-data@psg.com; Sun, 10 Feb 2002 13:33:52 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a1bb-000NTr-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 13:33:51 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020210213350.XPFY2951.rwcrmhc53.attbi.com@c1340594a>;
          Sun, 10 Feb 2002 21:33:50 +0000
Message-ID: <00b701c1b27a$f5075fe0$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: , "John Cowan" 
Cc: , , ,
        
References: 
Subject: [idn] Re: Unicode and Security
Date: Sun, 10 Feb 2002 13:36:10 -0800
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 have long advocated more intelligent GUIs to help distinguish
spoofing names. I think the technique could also help for the
Traditional vs Simplified Chinese issue; to help people type in one or
the other but not mix. I coded up (very rough, I warn you) a quick
demo of what I mean. Try:

http://www.macchiato.com/utc/despoofing

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "John Cowan" 
To: 
Cc: ; ;
; 
Sent: Saturday, February 09, 2002 18:28
Subject: Re: Unicode and Security


> DougEwell2@cs.com scripsit:
>
> > Let's keep going.  Latin Y, Greek Upsilon, Cyrillic U.  Wait a
minute, that
> > Cyrillic U doesn't look *quite* the same.  Oh well, it's close
enough, right?
>
> And then there's the Cyrillic U with the straight descender, whic
> actually does look just like its Latin and Greek counterparts.
> I guess we just can't afford to have two kinds of Cyrillic U around:
> off with their heads (or tails)!
>
> Unfortunately, there goes all those Turkic languages written in
Cyrillic.
> Well, they should Romanize anyway.  In fact all languages should
Romanize:
> it simplifies everything soooo much, and if we get rid of diacritics
> while we're at at it.... well, the ASCII Consortium
> (off-net, but cached in part at
http://www.google.com/search?q=cache:IRueJQ1bA-4C:www.wholehog.fsnet.c
o.uk/robert/ascii/+ASCII+Consortium&hl=en)
> will find it a dream come true.  And there was much rejoicing.
>
> --
> John Cowan           http://www.ccil.org/~cowan
cowan@ccil.org
> To say that Bilbo's breath was taken away is no description at all.
There
> are no words left to express his staggerment, since Men changed the
language
> that they learned of elves in the days when all the world was
wonderful.
>         --_The Hobbit_
>
>




From owner-idn@ops.ietf.org  Sun Feb 10 16:46: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 QAA11222
	for ; Sun, 10 Feb 2002 16:46:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a1j5-000Nfl-00
	for idn-data@psg.com; Sun, 10 Feb 2002 13:41:35 -0800
Received: from mx-out.daemonmail.net ([209.75.5.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a1j4-000Nff-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 13:41:34 -0800
Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1])
	by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id NAA98334
	for ; Sun, 10 Feb 2002 13:41:33 -0800 (PST)
	(envelope-from rosenne@qsm.co.il)
Received: from qsm3 (qsm3 [212.150.108.127])
	by mail.qsm.co.il with ESMTP id gZP0CeV2
	Sun, 10 Feb 2002 13:41:27 -0700 (PST)
From: "Jonathan Rosenne" 
To: 
Subject: RE: [idn] Chinese Domain Names
Date: Sun, 10 Feb 2002 23:41:05 +0200
Message-ID: <000501c1b27b$a7989200$eb0110ac@qsm3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3C66D80D.1E98AD6D@iis.sinica.edu.tw>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think it would be inadvisable to proceed against strong opposition of
Chinese experts. 

I'm not sure I understand what it is all about, and whether it is
justified or not, but it would be better if it could be resolved in an
amicable manner.

Jony




From owner-idn@ops.ietf.org  Sun Feb 10 17:26: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 RAA11511
	for ; Sun, 10 Feb 2002 17:26:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a2II-000OWD-00
	for idn-data@psg.com; Sun, 10 Feb 2002 14:17:58 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a2IH-000OW7-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 14:17:57 -0800
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 OAA04452;
	Sun, 10 Feb 2002 14:17:56 -0800
Message-Id: <5.1.0.14.2.20020210141105.031ae440@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 10 Feb 2002 14:12:21 -0800
To: "Jonathan Rosenne" 
From: Dave Crocker 
Subject: RE: [idn] Chinese Domain Names
Cc: 
In-Reply-To: <000501c1b27b$a7989200$eb0110ac@qsm3>
References: <3C66D80D.1E98AD6D@iis.sinica.edu.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 11:41 PM 2/10/2002 +0200, Jonathan Rosenne wrote:
>I think it would be inadvisable to proceed against strong opposition of
>Chinese experts.
>
>I'm not sure I understand what it is all about, and whether it is
>justified or not, but it would be better if it could be resolved in an
>amicable manner.

indeed it is always nice to be able to resolve things, especially amicably.

however before you call for delaying an effort that is already a couple of 
years late, perhaps you will consider becoming familiar with the issues and 
history.

d/


----------
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Sun Feb 10 20:31: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 UAA13055
	for ; Sun, 10 Feb 2002 20:31:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a52L-0002OJ-00
	for idn-data@psg.com; Sun, 10 Feb 2002 17:13:41 -0800
From: "jw-lin" 
To: 
Subject: [idn] Refuce to be re-educated!!
Date: Mon, 11 Feb 2002 02:24:40 +0800
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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 
Content-Transfer-Encoding: 7bit

Dear all members:

    As what i stated in last mail, the IDN WG is requesting to
re-educate
Chinese to learn how Chinese characters are used by last calling the
drafts
of IDNA architecture.
    Althouth I am just a powerless student, i want to warn all audience
on
the mailing list:

    It is wrong to try it.
    We refuce to be re-educated.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com






From owner-idn@ops.ietf.org  Sun Feb 10 20:31: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 UAA13067
	for ; Sun, 10 Feb 2002 20:31:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a531-0002Pn-00
	for idn-data@psg.com; Sun, 10 Feb 2002 17:14:23 -0800
From: "jwlin" 
To: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= ,
        
Subject: [idn] Refuce to be re-educated!! (again!!)
Date: Mon, 11 Feb 2002 02:46:42 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
Message-Id: 

boundary="----=_NextPart_000_0148_01C1B2A6.5656AA00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0148_01C1B2A6.5656AA00
Content-Type: text/plain;
charset="big5"
Content-Transfer-Encoding: quoted-printable

Dear all members:

    As what i stated in my mails, the IDN WG is requesting to re-educate
Chinese to learn how Chinese characters are used by last calling the =
drafts
of IDNA architecture.
    Althouth I am just a powerless student, i want to warn all audience
=
on
the mailing list:

    It is wrong to try it.
    We refuce to be re-educated.



------=_NextPart_000_0148_01C1B2A6.5656AA00
Content-Type: text/html;
charset="big5"
Content-Transfer-Encoding: quoted-printable









Dear all =
members:

    As=20
what i stated in my mails, the IDN WG is requesting to =
re-educate
Chinese to=20
learn how Chinese characters are used by last calling the drafts
of =
IDNA=20
architecture.
    Althouth I am just a powerless =
student, i=20
want to warn all audience on
the mailing =
list:

    It=20
is wrong to try it.
    We refuce to be=20
re-educated.



------=_NextPart_000_0148_01C1B2A6.5656AA00--




-------


From owner-idn@ops.ietf.org  Sun Feb 10 20:36: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 UAA13130
	for ; Sun, 10 Feb 2002 20:36:05 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a5C4-0002dX-00
	for idn-data@psg.com; Sun, 10 Feb 2002 17:23:44 -0800
Received: from imo-m06.mx.aol.com ([64.12.136.161])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a5C3-0002dR-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 17:23:43 -0800
Received: from DougEwell2@cs.com
	by imo-m06.mx.aol.com (mail_out_v32.5.) id 4.74.17dc01a8 (4215);
	Sun, 10 Feb 2002 20:23:31 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <74.17dc01a8.29987713@cs.com>
Date: Sun, 10 Feb 2002 20:23:31 EST
Subject: [idn] Re: Unicode and Security
To: unicode@unicode.org, idn@ops.ietf.org
CC: elharo@metalab.unc.edu, schneier@counterpane.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-10 13:00:19 Pacific Standard Time, 
elharo@metalab.unc.edu writes:

> However, I do continue to maintain that character confusion is a real 
> security risk that will have real impact on users, and that needs to 
> be considered in any system that uses Unicode.

We have already established that similar-looking characters can cause 
confusion in Unicode-based systems.  However, we have also established that 
ISO 8859-1, 8859-5 (Cyrillic), 8859-7 (Greek), and even ASCII can suffer from 
this same problem.  It is unrealistic to sugest that the problem began with 
Unicode.

> In some domains the 
> problem might be severe enough to eliminate Unicode from 
> consideration in favor of less extensive character sets like Latin-1. 
> That would be a shame, but until the Unicode consortium addresses at 
> a root level the real security implications of their work, security 
> conscious developers will look elsewhere. (I notice the Unicode 3.0 
> book does not even have the word "security" in its index.) Many more 
> developers who are at best tangentially conscious of security issues 
> will go ahead and develop insecure systems because they don't realize 
> the security implications of adopting Unicode.

Companies and individuals that choose to throw out the baby with the bath 
water will achieve the kind of results that that approach usually delivers.

Companies and individuals that wish to establish their own definitions of, 
and policies for dealing with, confusable characters are free to do so.  As I 
stated earlier, and nobody could refute, there is no consistent way to 
determine which sets of characters are confusable with each other, other than 
in the most obvious cases like o/omicron.  So of course neither the Unicode 
Consortium nor WG2 has taken it upon themselves to draw up such a list.  This 
must be a local decision.

> Another possibility is a super-normalization that does combine 
> similar looking Unicode characters; e.g. in the domain name system we 
> might decide that microsoft.com with Latin o's or Cyrillic o's or 
> Greek o's is to resolve to the same address. No separate registration 
> would be necessary or possible. This would require detailed analysis 
> of the tens of thousands of Unicode characters allowed in domain 
> names by fluent speakers of various languages; not easy, not cheap, 
> but perhaps necessary. Besides, the security improvements, this 
> proposal would also improve the system's usability. Aren't sure 
> whether that URL on the bus used an o or an omicron? Doesn't matter, 
> type either one.

Adding this sort of unification to the nameprep stage might have been 
possible about a year or so ago.  It's probably too late now.

> Actually, people have been talking about the security problems with 
> HTML for years. Search engines have gone to some effort to eliminate 
> spamdexers that use these techniques. The log in HTML's eye does not, 
> however, negate the existence of the log in Unicode's eye.

Again (and again), the problem is not unique to Unicode.  Existing character 
sets also contain confusables.  Blaming Unicode for exacerbating the problem 
by offering so many characters is like blaming your local ice cream shop for 
offering 31 flavors, because that makes it so much more difficult to choose.

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Sun Feb 10 20:40: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 UAA13226
	for ; Sun, 10 Feb 2002 20:40:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a5D2-0002fT-00
	for idn-data@psg.com; Sun, 10 Feb 2002 17:24:44 -0800
Date: Sun, 10 Feb 2002 13:05:10 -0500
To: , idn@ops.ietf.org, schneier@counterpane.com
From: Elliotte Rusty Harold 
Subject: [idn] Re: Unicode and Security
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: 

At 9:52 PM +0100 2/9/02, Lars Marius Garshol wrote:


>It seems to me that this problem really needs some other fix than the
>merging of all similar-looking characters in all character sets. I
>just can't see that working.
>

That's your suggestion, not mine. I have never proposed merging all 
the similar looking characters. If I misspoke or something I wrote 
was misinterpreted as indicating that, I apologize. But that is not 
now nor ever was my position.

However, I do continue to maintain that character confusion is a real 
security risk that will have real impact on users, and that needs to 
be considered in any system that uses Unicode. In some domains the 
problem might be severe enough to eliminate Unicode from 
consideration in favor of less extensive character sets like Latin-1. 
That would be a shame, but until the Unicode consortium addresses at 
a root level the real security implications of their work, security 
conscious developers will look elsewhere. (I notice the Unicode 3.0 
book does not even have the word "security" in its index.) Many more 
developers who are at best tangentially conscious of security issues 
will go ahead and develop insecure systems because they don't realize 
the security implications of adopting Unicode.

There might be other solutions. I have proposed forbidding mixed 
block domain names; e.g. allowing Cyrillic names and Latin names but 
not mixed Cyrillic-Latin names. To me, that seems a reasonable 
trade-off. Vastly improved spoof-resistance (though still not 
perfect) while still allowing the registration of most desired 
localized names.

Another possibility is a super-normalization that does combine 
similar looking Unicode characters; e.g. in the domain name system we 
might decide that microsoft.com with Latin o's or Cyrillic o's or 
Greek o's is to resolve to the same address. No separate registration 
would be necessary or possible. This would require detailed analysis 
of the tens of thousands of Unicode characters allowed in domain 
names by fluent speakers of various languages; not easy, not cheap, 
but perhaps necessary. Besides, the security improvements, this 
proposal would also improve the system's usability. Aren't sure 
whether that URL on the bus used an o or an omicron? Doesn't matter, 
type either one.

>Similarly, the "security problems" caused by using Unicode encoding
>tricks to hide or mangle text in, say, contracts, is no different from
>using HTML or CSS (or whatever) tricks to achieve the same effect, and
>yet nobody is talking about security problems with HTML or CSS. See
>[1] for one way of dealing with it that is now being worked on.
>

Actually, people have been talking about the security problems with 
HTML for years. Search engines have gone to some effort to eliminate 
spamdexers that use these techniques. The log in HTML's eye does not, 
however, negate the existence of the log in Unicode's eye.

>So while I accept that there is a problem it does not seem to me that
>Unicode is the problem. To me the problem seems to be the complexity
>of the relationship between the bytes sent to the user and what the
>user actually sees and reacts to. That complexity is not going to
>disappear, and aspects of the same "problem" exist with just about any
>information representation, so clearly the solution must be something
>other than changing all of these syntaxes/formats/encodings.
>
>In the specific case you cite, for example, a better solution might be
>for the user's email client to keep track of all the user's contacts
>and for it to indicate in some clearly visible way whether the current
>email comes from one of them or not. Whether it uses string matching
>of email addresses or digital signatures to do that doesn't really
>matter; it solves the problem in your example either way.
>

If the internationalized domain name system comes into being without 
any resistance to spoofing, I will certainly recommend that people 
upgrade their client software to prevent this, just as I recommend 
today that people avoid Outlook Express, Microsoft Office, and other 
products that provide fertile soil for worms. I expect such efforts 
to be about equally effective; i.e. some wiser users will protect 
themselves. Many other users will be protected by accident. And many 
more users will not be protected at all.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+





From owner-idn@ops.ietf.org  Sun Feb 10 20:44: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 UAA13289
	for ; Sun, 10 Feb 2002 20:44:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a5G1-0002kw-00
	for idn-data@psg.com; Sun, 10 Feb 2002 17:27:49 -0800
To: Elliotte Rusty Harold 
Date: Sun, 10 Feb 2002 19:31:16 -0500 (EST)
CC: unicode@unicode.org, idn@ops.ietf.org, schneier@counterpane.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: 
From: John Cowan 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Elliotte Rusty Harold scripsit:

> Another possibility is a super-normalization that does combine
> similar looking Unicode characters; e.g. in the domain name system we
> might decide that microsoft.com with Latin o's or Cyrillic o's or
> Greek o's is to resolve to the same address.

In that case comment NOW, TODAY or TOMORROW, to the IETF IDN lists
so that they can extend the nameprep process to do such things.
(They will be resistant at this stage, no doubt, but it's worth
a try.)  The Unicode list can't help you.

--
John Cowan           http://www.ccil.org/~cowan
cowan@ccil.org
To say that Bilbo's breath was taken away is no description at all.
There
are no words left to express his staggerment, since Men changed the
language
that they learned of elves in the days when all the world was wonderful.
        --_The Hobbit_





From owner-idn@ops.ietf.org  Sun Feb 10 22:18: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 WAA15295
	for ; Sun, 10 Feb 2002 22:18:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a6qF-0005Ey-00
	for idn-data@psg.com; Sun, 10 Feb 2002 19:09:19 -0800
Received: from smtp-server2.tampabay.rr.com ([65.32.1.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a6qE-0005Es-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 19:09:18 -0800
Received: from e0g0l1 (242685hfc26.tampabay.rr.com [24.26.85.26])
	by smtp-server2.tampabay.rr.com (8.11.2/8.11.2) with SMTP id g1B39Dt22708;
	Sun, 10 Feb 2002 22:09:13 -0500 (EST)
Message-ID: <000c01c1b2a5$b434ed40$1a551a18@tampabay.rr.com>
From: "William Blackwood" 
To: , , 
Cc: , 
References: <74.17dc01a8.29987713@cs.com>
Subject: Re: [idn] Re: Unicode and Security
Date: Sun, 10 Feb 2002 21:42:05 -0500
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.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Very well stated Doug.

Spoofing existed long before Unicode and will so afterward.

STOP IMPLICATING UNICODE BECAUSE OF A PRIOR AND COMPLETELY INDEPENDENT
ISSUE.

LETS GET MOVING ON THESE IDN NAMES NOW!




----- Original Message -----
From: 
To: ; 
Cc: ; 
Sent: Sunday, February 10, 2002 8:23 PM
Subject: [idn] Re: Unicode and Security


> In a message dated 2002-02-10 13:00:19 Pacific Standard Time,
> elharo@metalab.unc.edu writes:
>
> > However, I do continue to maintain that character confusion is a real
> > security risk that will have real impact on users, and that needs to
> > be considered in any system that uses Unicode.
>
> We have already established that similar-looking characters can cause
> confusion in Unicode-based systems.  However, we have also established
that
> ISO 8859-1, 8859-5 (Cyrillic), 8859-7 (Greek), and even ASCII can suffer
from
> this same problem.  It is unrealistic to sugest that the problem began
with
> Unicode.
>
> > In some domains the
> > problem might be severe enough to eliminate Unicode from
> > consideration in favor of less extensive character sets like Latin-1.
> > That would be a shame, but until the Unicode consortium addresses at
> > a root level the real security implications of their work, security
> > conscious developers will look elsewhere. (I notice the Unicode 3.0
> > book does not even have the word "security" in its index.) Many more
> > developers who are at best tangentially conscious of security issues
> > will go ahead and develop insecure systems because they don't realize
> > the security implications of adopting Unicode.
>
> Companies and individuals that choose to throw out the baby with the bath
> water will achieve the kind of results that that approach usually
delivers.
>
> Companies and individuals that wish to establish their own definitions of,
> and policies for dealing with, confusable characters are free to do so.
As I
> stated earlier, and nobody could refute, there is no consistent way to
> determine which sets of characters are confusable with each other, other
than
> in the most obvious cases like o/omicron.  So of course neither the
Unicode
> Consortium nor WG2 has taken it upon themselves to draw up such a list.
This
> must be a local decision.
>
> > Another possibility is a super-normalization that does combine
> > similar looking Unicode characters; e.g. in the domain name system we
> > might decide that microsoft.com with Latin o's or Cyrillic o's or
> > Greek o's is to resolve to the same address. No separate registration
> > would be necessary or possible. This would require detailed analysis
> > of the tens of thousands of Unicode characters allowed in domain
> > names by fluent speakers of various languages; not easy, not cheap,
> > but perhaps necessary. Besides, the security improvements, this
> > proposal would also improve the system's usability. Aren't sure
> > whether that URL on the bus used an o or an omicron? Doesn't matter,
> > type either one.
>
> Adding this sort of unification to the nameprep stage might have been
> possible about a year or so ago.  It's probably too late now.
>
> > Actually, people have been talking about the security problems with
> > HTML for years. Search engines have gone to some effort to eliminate
> > spamdexers that use these techniques. The log in HTML's eye does not,
> > however, negate the existence of the log in Unicode's eye.
>
> Again (and again), the problem is not unique to Unicode.  Existing
character
> sets also contain confusables.  Blaming Unicode for exacerbating the
problem
> by offering so many characters is like blaming your local ice cream shop
for
> offering 31 flavors, because that makes it so much more difficult to
choose.
>
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)
>




From owner-idn@ops.ietf.org  Sun Feb 10 23:47: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 XAA17231
	for ; Sun, 10 Feb 2002 23:47:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16a7sp-0006qG-00
	for idn-data@psg.com; Sun, 10 Feb 2002 20:16:03 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16a7so-0006q3-00
	for idn@ops.ietf.org; Sun, 10 Feb 2002 20:16:02 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16a7sn-0004Oh-00
	for ; Sun, 10 Feb 2002 20:16:01 -0800
Date: Mon, 11 Feb 2002 04:16:01 +0000
From: "Adam M. Costello" 
To: IDN 
Subject: Re: [idn] WG last call documents
Message-ID: <20020211041601.GB14664@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[A response to a remark by Dan Oscarsson appears at the end of this
message.]

"Eric A. Hall"  wrote:

>  | Stringprep Profile for Internationalized Host Names
>
> Since this profile is specifically for host names, all of the rules
> that apply to hostnames should be placed here.

I think the intended title of this document is "Stringprep Profile
for Internationalized Domain Names".  The previous IDNA draft was
"Internationalizing Host Names in Applications", but the latest IDNA
draft is "Internationalizing Domain Names in Applications".  I think
when that change was made, the same change should have been to the title
of the nameprep draft, but was not due to a simple oversight.  Can the
nameprep authors confirm that?

In my view, (and in the view of the IDNA draft) nameprep is *not*
specifically for host names, but is for all internationalized textual
domain names.  That is how IDNA uses it.

> Consider that there are apps and protocols which may use [nameprep]
> to build internationalized host names but will not use IDNA (either
> because they do not need IDNA conversion for their data-path or they
> use something other than IDNA to encode the names).

Those apps still need the IDNA spec, because the IDNA spec defines
what is a valid internationalized domain label.  Nameprep alone cannot
possibly tell you whether the label is too long; you can know that only
after applying Punycode.

> draft-ietf-idn-idna-06.txt:
> 
>  | This document defines internationalized domain names (IDNs)
> 
> That definition should be in a separate document

Here is the definition in question:

    An "internationalized domain name" (IDN) is a domain name for which
    the ToASCII operation (see section 4) can be applied to each label
    without failing.

Clearly the IDNA spec is the logical place for that definition.  Maybe
you'd like to change the definition, but that's a separate issue.

> I thought the idea behind adopting "punycode" was to avoid the use of
> the generic "ACE" term?

Nope.  Currently, the relationship between the terms "ACE" and
"Punycode" is as follows:  An ACE label is an ASCII label that is
equivalent to a non-ASCII label.  ToASCII is the operation that converts
labels to equivalent ASCII labels.  Punycode is one of several steps of
ToASCII (other steps include nameprep and checking for various other
restrictions, like length).

The term "ACE" has been used to refer to several subtley different
concepts over the past few years, but no formal definition was ever
given until the recent IDNA drafts.

>  | 1) Whenever a domain name is put into a generic domain name slot,
>  | every label MUST contain only ASCII characters.
>
> "generic domain name slot" should be substituted with "STD13 slot".
> There is no reason whatsoever that application protocols cannot
> exchange IDNs or IHNs in whatever form they wish.

The second sentence is true, but I don't see how the first sentence
follows from it.

IDNA defines "generic domain name slot" as follows:

    An "internationalized domain name slot" is defined in this document
    to be a domain name slot explicitly designated for carrying an
    internationalized domain name as defined in this document.  The
    designation may be static (for example, in the specification of
    the protocol or interface) or dynamic (for example, as a result of
    negotiation in an interactive session).

    A "generic domain name slot" is defined in this document to be any
    domain name slot that is not an internationalized domain name slot.
    Obviously, this includes any domain name slot whose specification
    predates IDNA.

Regardless of what we call it, that is the concept that is needed in
rule 1.  Perhaps you think the term "generic domain name slot" is
counter-intuitive and should be renamed (but not redefined)?

I don't think the term "STD13 slot" is appropriate.  I would expect a
term called "STD13 slot" to be defined in terms of STD13 only, but the
concept we need here is defined in terms of the IDNA spec.

>  | 2) ACE labels SHOULD be hidden from users whenever possible.
>
> Should WHOIS servers perform this conversion on output (email
> addresses and nameservers) since it is likely to be displayed to a
> user?

That rule also says "When requirements 1 and 2 both apply, requirement
1 takes precedence."  If the output of whois is considered to be
machine-readable, then the email address domains and nameservers occupy
generic domain name slots and rule 1 requires the ASCII forms to be
used.  If the output is considered to be plain text for humans, and if
the charset supports non-ASCII, then ToUnicode should be applied to the
domain labels when the output is composed.

> Should an email client perform conversion on a message?

On the body, no.  But it should perform conversion on the domain names
in the header.

Hmmm, maybe we should insert "obtained from domain name slots" after
"ACE labels" in rule 2.

Notice that it's a SHOULD and not a MUST.  That is deliberate, because I
don't think any simple rule can describe exactly the circumstances where
you want to perform ToUnicode while excluding all the circumstances
where you wouldn't want to.  Neglecting to apply ToUnicode will at worst
cause users to see garbage, but otherwise won't break anything, so we
leave room for the application programmer to decide that rule 2 is
better left unheeded in special situations.

> CONVERSION MUST ONLY OCCUR WHERE A PROTOCOL OR DATA-FORMAT EXPLICITLY
> DEFINES THE BEHAVIOR.

That would defeat the whole point of IDNA, which is to allow
applications to use internationalized domain names with legacy protocols
and interfaces, without having to revise those protocols and interfaces.

> | 4.1 ToASCII
> | 4.2 ToUnicode
> 
> Add a disclaimer to the effect of ~"these routines MUST NOT be used
> except where the data is known to contain an i18n domain name label".

They are designed to work for all domain labels, and the rules in
section 3 require them to be applied to all domain labels.

The IDNA draft nowhere suggests using them for anything but domain
labels.  But forbidding their use on other things would be out of scope.
IDNA can assert restrictions related to domain names, but the one you
suggest would be a requirement that applies to everything *except*
domain names.

> Trying to pipe an STD13 binary domain name through ToUnicode may
> result in some false-positives.

If a domain label gets altered by ToUnicode, then it *is* an ACE label,
whether by designed or by accident.  We've known from the start that
the possibility of accidental ACEs is unavoidable in the IDNA approach,
which takes an existing corner of the namespace and repurposes it.  (But
accidents will be quite rare:  The label must contain only ASCII code
points, and begin with the ACE prefix, and the remainder must be a valid
Punycode encoding, and the decoding of that must remain unchanged by
nameprep).

You don't need to invoke "binary" domain names to illustrate this
problem, since it is equally present for ASCII domain names.  In either
case, an accidental ACE label might get displayed (or even transported)
in an untintended way, but no information will be lost, and the original
form will be restored before any program attempts to interpret the
name as intended.  (Why?  Because a program that knows the intended
interpretation will be receiving it through a slot that isn't an
internationalized domain name slot, and hence the name must have been
converted back (by ToASCII) before being put into that slot.)

>  | B. Design philosophy
> 
> What value does this section provide?

It documents the rationale behind the design decisions.  I think it's
often helpful and/or instructive for people who later read the spec and
wonder "Why did they do it that way?"

I think its generally good to have a rationale appendix in any technical
spec.  (Punycode lacks one only because I never got around to writing
one.)

> One specific item, there does not seem to be a prohibition against
> certain characters in the first position of a domain name label.

Has the current prohibition of leading & trailing hyphens been terribly
helpful?  I think it probably would have been better if the host
label syntax were simpler--just a set of allowed characters, with no
restrictions on position.  So I think we should keep any new positional
restrictions to a minimum.

But there is one class of characters that might indeed be dreadful at
the beginning: combining characters.  I recently refered to labels
that begin with combining characters as invalid Unicode strings, but
they're not, are they?  They just behave in surprising ways when abutted
with something else.  Maybe nameprep should prohibit initial combining
characters.

> > There are some code points that are prohibited in host names,
> > but not in all textual domain names.  The underscore is the best
> > example.  These prohibitions belong in ToASCII.
>
> I disagree with this for a couple of reasons.  First of all, these
> exceptions are associated with protocol identifier labels, which are
> not hostnames.

Right, they're not host names.  That's the whole point.  There exist
domain names that are not host names.

> Nameprep defines i18n hostnames, so these characters belong in the
> nameprep prohibition.

See above.  I think nameprep applies to domain names, not just host
names.

> SRV owner labels are protocol elements, not text.  They should never
> go through any conversion.  A dedicated profile for this would help.

Consider the following UTF-8 zone file:

$ORIGIN THAI1.net.
_ldap._tcp CNAME _ldap._tcp.THAI2.net

It would be ludicrous to expect the preprocessor that converts this to
a STD-13 zone file to do a lookup on _ldap._tcp.THAI2.net (which is
not defined in this zone file) and discover that it has a SRV record
and hence avoid applying conversions to _ldap._tcp.  It should be able
to simply apply ToASCII to all domain labels.  As IDNA is currently
specified, it can.

> The point here is that EVERY network service has its own
> considerations.  Demanding that all services implement a user-level
> feature is absurd.

We recommend, we don't demand.  And we don't try to apply the user-level
feature in absurd places, we say "before a domain name is displayed
to a user or is output into a context likely to be viewed by users".
Maybe you think that description is too broad.  Suggest some alternative
wording.  But we need to give some sort of encouragement for ToUnicode
to be applied in some situations.

> The outcome of this mandate is that every existing specification is
> made obsolete and non-compliant.

I don't know what it means for a specification to comply or not comply
with IDNA.  Applications can comply with IDNA, or not.

Every existing application is non-compliant with IDNA.  Obviously we
cannot expect any existing application to comply with a new spec written
after the application.

Existing applications will never apply ToASCII or ToUnicode, because
they don't know about them.  IDNA-compliant applications will apply
ToASCII and ToUnicode in various situations according to rules 1-3.

I don't see how existing specifications are made obsolete.

Dan Oscarsson  wrote:

> There should also be a requirement that a protocol using UTF-8 should
> never send data using ACE so the receiver does not have to handle the
> extra work of checking for embedded ACE.

That would be out of scope.  IDNA specifies a method for applications
to use IDNs with non-IDN-aware protocols and interfaces.  IDNA has no
business telling new IDN-aware protocols what representations they
should allow or forbid.

Besides, I think it's a good idea to do the check anyway, whenever you
display a domain name, regardless of where it came from.  ACEs might
have been leaked into the system by a gateway or cut/paste operation.

AMC



From owner-idn@ops.ietf.org  Mon Feb 11 07:39: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 HAA29350
	for ; Mon, 11 Feb 2002 07:39:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aFUj-000Ixv-00
	for idn-data@psg.com; Mon, 11 Feb 2002 04:23:41 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aFUi-000Ixd-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 04:23:40 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP
	id 4126A160C; Mon, 11 Feb 2002 21:23:23 +0900 (JST)
Message-Id: <4.2.0.58.J.20020211203223.042e8090@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 11 Feb 2002 20:45:41 +0900
To: idn@ops.ietf.org
From: Martin Duerst 
Subject: [idn] Last call comments to nameprep/stringprep: BIDI
Cc: mark.davis@us.ibm.com, mark@macchiato.com (Mark Davis), atkin@us.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Currently, neither draft-ietf-idn-nameprep-07.txt nor
draft-hoffman-stringprep-00.txt deal with bidirectionality
(mixing right-to-left (Arabic/Hebrew) and left-to-right
writing directions) issues. This should be changed as soon
as possible.

If a label can contain both right-to-left and left-to-right
characters, how it will be displayed, and how displayed
labels will be entered and looked up in the DNS, is highly
context-dependent. This is obviously very undesirable.

The following is a proposal written up by Mark Davis,
based on input from others:


 >>>>
A. Characters are classified into RTL, LTR, DIGIT, OTHER.

These categories are drawn from the BIDI algorithm. The precise lists of 
characters in each category would be added to NamePrep as an appendix. The 
composition is as follows (See 
http://ww 
w.unicode.org/reports/tr9/#Bidirectional_Character_Types).

LTR   := L ; # including LRM

RTL   := R | AL ;

DIG   := EN | AN ;

OTH := all other characters: NSM, ON, etc.

Note: The characters in categories LRM, RLM, LRO, RLO, LRE, RLE, PDF, B, S, 
and some other BIDI categories are prohibited anyway.


B. In any field that contains any RTL characters:
B0. no LTR characters can occur.
C1. a sequence of characters of type DIG can only occur at the end.
C2. a sequence of characters of type OTHER can occur only between 
characters of type RTL.
 >>>>

I propose that this be added as an additional step after the current
'prohibition' step.

Regards,    Martin.



From owner-idn@ops.ietf.org  Mon Feb 11 07:39: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 HAA29362
	for ; Mon, 11 Feb 2002 07:39:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aFUj-000Ixw-00
	for idn-data@psg.com; Mon, 11 Feb 2002 04:23:41 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aFUi-000Ixf-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 04:23:40 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 7AF20160E
	for ; Mon, 11 Feb 2002 21:23:24 +0900 (JST)
Message-Id: <4.2.0.58.J.20020211205215.04315008@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 11 Feb 2002 21:20:35 +0900
To: idn@ops.ietf.org
From: Martin Duerst 
Subject: [idn] Last call comments to stringprep
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Last call comments to draft-hoffman-stringprep-00.txt:

Section 4, paragaph starting 'If a profile': 'Many user interface
systems enter compatibility characters instead of the base equivalents.'
The systems don't really enter the characters, the users enter them.
Also, sometimes compatibility characters get entered, but it's not that
frequent. I suggest writing:

'Some user interface systems make it possible to enter compatibility
characters instead of the base equivalents.'


Regarding:
    [[[[[ Patrick asks: Is not addition of unassigned codepoints regarded
    an update of UAX15? This is relevant here. ]]]]]

First, I'm a bit surprised to find this question in a last-call document.
But I hope I can help clearing it up. Being coauthor of UAX15, I can tell
you that UAX15 does not have to be updated when new characters get added
to Unicode (which I guess is what 'addition of unassigned codepoints'
refers to).

UAX15 points to a list of composition exclusions, maintained in a separate
file. In case new precomposed characters are added, this file will be
updated. It should be expected that implementations at least use the
composition exclusion file that corresponds to the Unicode version
for the relevant stringprep profile (as expressed by the unassigned
codepoints). This should probably be mentioned in stringprep.
Apart from that, I don't know any way in which assignement of
additional codepoints as such (as opposed to an actual change to
UAX15, which is a different thing) can change normalization.


Section 6.1: MN: 'are never appear': Remove 'are'.

Regards,   Martin.

Regards,    Martin.



From owner-idn@ops.ietf.org  Mon Feb 11 07:39: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 HAA29374
	for ; Mon, 11 Feb 2002 07:39:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aFUs-000Ixz-00
	for idn-data@psg.com; Mon, 11 Feb 2002 04:23:50 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aFUi-000Ixe-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 04:23:40 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 06950160D
	for ; Mon, 11 Feb 2002 21:23:24 +0900 (JST)
Message-Id: <4.2.0.58.J.20020211204734.042ddc78@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 11 Feb 2002 21:23:32 +0900
To: idn@ops.ietf.org
From: Martin Duerst 
Subject: [idn] Last call comments to nameprep
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Last call comments to draft-ietf-idn-nameprep-07.txt:


Section 3, second paragraph: 'Note that text in this section describe'
-> 'Note that THE text in this section describeS'.


Section 5.1: 'Space characters would make visual transcription of URLs
nearly impossible...': This document is about domain names, so just
say 'would make visual transcription of domain names nearly impossible'.


References: Several references are not used in the document:
[CharModel], [URI]. Please use them or remove them. In case
[URI] is kept, the 'For example' should be removed. RFC 2396
(as updated by RFC 2732) defines URI syntax. It does not define
any single URI scheme. The 'Note that...' should also be removed.


Note before App. F: 'pints' -> 'points'


Regards,    Martin. 



From owner-idn@ops.ietf.org  Mon Feb 11 08:05: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 IAA00007
	for ; Mon, 11 Feb 2002 08:05:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aG30-000K3B-00
	for idn-data@psg.com; Mon, 11 Feb 2002 04:59:06 -0800
Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aG2x-000K2y-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 04:59:04 -0800
Received: from bamdad.org (IDENT:root@gilas.bamdad.org [194.225.42.242])
	by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g1BCwWd05819;
	Mon, 11 Feb 2002 16:28:32 +0330
Received: from localhost (roozbeh@localhost)
	by bamdad.org (8.11.6/8.11.6) with ESMTP id g1BD68v22307;
	Mon, 11 Feb 2002 16:36:08 +0330
X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs
Date: Mon, 11 Feb 2002 16:36:08 +0330 (IRT)
From: Roozbeh Pournader 
X-X-Sender: roozbeh@gilas.bamdad.org
To: IDN 
cc: Martin Duerst , ,
        Mark Davis , 
Subject: Re: [idn] Last call comments to nameprep/stringprep: BIDI
In-Reply-To: <4.2.0.58.J.20020211203223.042e8090@localhost>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


As an expert in modern text processing of the Arabic script, having put my
head deeply into the mouth of the bidirectional algorithm, I wish to tell
about my complete approval of Martin Duerst's comments. The suggested
solution solves many security and confusion problems that may raise 
because of the complexities of the bidirectional scripts.

The problem may need to discussed further, but Mark's suggestion is the 
best I have seen so far.

Roozbeh Pournader

On Mon, 11 Feb 2002, Martin Duerst wrote:

> Currently, neither draft-ietf-idn-nameprep-07.txt nor
> draft-hoffman-stringprep-00.txt deal with bidirectionality
> (mixing right-to-left (Arabic/Hebrew) and left-to-right
> writing directions) issues. This should be changed as soon
> as possible.
> 
> If a label can contain both right-to-left and left-to-right
> characters, how it will be displayed, and how displayed
> labels will be entered and looked up in the DNS, is highly
> context-dependent. This is obviously very undesirable.
> 
> The following is a proposal written up by Mark Davis,
> based on input from others:
> 
> 
>  >>>>
> A. Characters are classified into RTL, LTR, DIGIT, OTHER.
> 
> These categories are drawn from the BIDI algorithm. The precise lists of 
> characters in each category would be added to NamePrep as an appendix. The 
> composition is as follows (See 
> http://ww 
> w.unicode.org pes>/reports/tr9/#Bidirectional_Character_Types).
> 
> LTR   := L ; # including LRM
> 
> RTL   := R | AL ;
> 
> DIG   := EN | AN ;
> 
> OTH := all other characters: NSM, ON, etc.
> 
> Note: The characters in categories LRM, RLM, LRO, RLO, LRE, RLE, PDF, B, S, 
> and some other BIDI categories are prohibited anyway.
> 
> 
> B. In any field that contains any RTL characters:
> B0. no LTR characters can occur.
> C1. a sequence of characters of type DIG can only occur at the end.
> C2. a sequence of characters of type OTHER can occur only between 
> characters of type RTL.
>  >>>>
> 
> I propose that this be added as an additional step after the current
> 'prohibition' step.
> 
> Regards,    Martin.
> 


-- 
Note: If you want me to read a message, please make sure you include my
address in "To" or "CC" fields. I may not be able to follow all the
discussions on the mailing lists I subscribe. Sorry. (No, there's no problem
to receive duplicates.)




From owner-idn@ops.ietf.org  Mon Feb 11 11:05: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 LAA07317
	for ; Mon, 11 Feb 2002 11:05:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aIn6-000PSD-00
	for idn-data@psg.com; Mon, 11 Feb 2002 07:54:52 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aIn4-000PS7-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 07:54:51 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BFsbR25482
	for ; Tue, 12 Feb 2002 00:54:37 +0900
Message-ID: <0bfb01c1b314$5e663940$2b19fea9@temp>
From: "Soobok Lee" 
To: 
Subject: [idn] stringprep comment 4 :  hangul jamo filler
Date: Tue, 12 Feb 2002 00:54:20 +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

hangul conjoining jamo filles look like blank space when they don't form  complete 
hangul syllables. 

I had suggested in my hangulchar draft that such standalone fillers should be prohibitted
by new context-sensitive procedural prohibition stage after table-mapping based
current prohibition stage. (In the same position like BIDI checking stage suggested by Martin
in the previous posting)

The very suggestion was abandoned with all other bypassing suggestions for 
other UAX15 shortbacks. 

Fillers may be the security holes of IDNA if not taken carefully in loosely managed zones.

Soobok Lee






From owner-idn@ops.ietf.org  Mon Feb 11 11:07: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 LAA07407
	for ; Mon, 11 Feb 2002 11:07:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aIsl-000Pfw-00
	for idn-data@psg.com; Mon, 11 Feb 2002 08:00:43 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aIsk-000Pfq-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 08:00:42 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BG0e329888
	for ; Mon, 11 Feb 2002 08:00:40 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <20020211041601.GB14664@nicemice.net>
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com>
 <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com>
 <20020211041601.GB14664@nicemice.net>
Date: Mon, 11 Feb 2002 08:00:37 -0800
To: IETF idn working group 
From: Paul Hoffman / IMC 
Subject: Re: [idn] WG last call documents
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 4:16 AM +0000 2/11/02, Adam M. Costello wrote:
>I think the intended title of this document is "Stringprep Profile
>for Internationalized Domain Names".  The previous IDNA draft was
>"Internationalizing Host Names in Applications", but the latest IDNA
>draft is "Internationalizing Domain Names in Applications".  I think
>when that change was made, the same change should have been to the title
>of the nameprep draft, but was not due to a simple oversight.  Can the
>nameprep authors confirm that?

Yep, that is correct. I worked so hard on getting it right in IDNA 
that I forgot to be careful in nameprep. This will be fixed.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Mon Feb 11 11:19: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 LAA07760
	for ; Mon, 11 Feb 2002 11:19:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJ4U-00008N-00
	for idn-data@psg.com; Mon, 11 Feb 2002 08:12:50 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJ4S-000089-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 08:12:49 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BGChR25613;
	Tue, 12 Feb 2002 01:12:43 +0900
Message-ID: <0c0601c1b316$dfc16350$2b19fea9@temp>
From: "Soobok Lee" 
To: 
Cc: "Martin Duerst" , "Mark Davis" 
Subject: [idn] stringprep comment 5: hangul conjoining sequence 
Date: Tue, 12 Feb 2002 01:12:16 +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

Two issues briefed in hangulchars drafts and in this mailling list, but not mentions in
  the latest nameprep and stringprep drafts:

 1. When  old trailing hangul jamos are included in conjoining jamo sequences, UAX15(NFC)
     performs  partial combinations to produce  "a modern hangul syllable(LV) + a standalone
      old hangul jamo(oT)" and that form satify a ridiculous syllable break condition (X.T) .


 2. UAX15 also tries ridiculous partial combinations when it met a combining sequence if
      two or more leading hangul jamos followed by hangul vowel jamos, and produce
      a syllable break condition (L.LV)

 3. Compatibility hangul jamos are mapped into conjoining jamos without any fillers.

 Errors briefed in 1,2 and 3 came from  past poor cooperations between UAX15 authors and Korean UTC participants, and NFC routines
was already widely distributed.

 Now I propose UTC make new normalizations (call it NFN)to correct such errors and faults and
    let stringprep include it after casefolding : that is  NFKC(NFN(casefold(x)).

 We dont need to modify NFC and NFKC. Just add new correcting normalizations as soon as possible.

 Stringprep efforts should be in sync with further UTC's works. No hastes!

 Soobok Lee




From owner-idn@ops.ietf.org  Mon Feb 11 11: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 LAA09417
	for ; Mon, 11 Feb 2002 11:47:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJVA-00018u-00
	for idn-data@psg.com; Mon, 11 Feb 2002 08:40:24 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJV7-00018o-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 08:40:21 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BGeGR25770
	for ; Tue, 12 Feb 2002 01:40:16 +0900
Message-ID: <0c1f01c1b31a$b8b9caf0$2b19fea9@temp>
From: "Soobok Lee" 
To: 
Subject: [idn] IDNA comment 1 :  applications' own normalization vs stringprep
Date: Tue, 12 Feb 2002 01:39:48 +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


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  Mon Feb 11 11:49: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 LAA09477
	for ; Mon, 11 Feb 2002 11:49:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJWT-0001At-00
	for idn-data@psg.com; Mon, 11 Feb 2002 08:41:45 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJWS-0001An-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 08:41:44 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020211164144.OQXB2951.rwcrmhc53.attbi.com@c1340594a>;
          Mon, 11 Feb 2002 16:41:44 +0000
Message-ID: <001101c1b31b$50d3c7f0$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "Soobok Lee" , 
Cc: "Martin Duerst" , "Mark Davis" 
References: <0c0601c1b316$dfc16350$2b19fea9@temp>
Subject: [idn] Re: stringprep comment 5: hangul conjoining sequence 
Date: Mon, 11 Feb 2002 08:44:03 -0800
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

Syllable breaks are different than character boundaries. Please see
http://www.unicode.org/versions/beta.html, where that is clarified.

Now, of course, it would be possible to choose a different
normalization. That has, however, been debated at great length on this
list; see the archives. I see no pressing need for change.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Soobok Lee" 
To: 
Cc: "Martin Duerst" ; "Mark Davis"

Sent: Monday, February 11, 2002 08:12
Subject: stringprep comment 5: hangul conjoining sequence


> Two issues briefed in hangulchars drafts and in this mailling list,
but not mentions in
>   the latest nameprep and stringprep drafts:
>
>  1. When  old trailing hangul jamos are included in conjoining jamo
sequences, UAX15(NFC)
>      performs  partial combinations to produce  "a modern hangul
syllable(LV) + a standalone
>       old hangul jamo(oT)" and that form satify a ridiculous
syllable break condition (X.T) .
>
>
>  2. UAX15 also tries ridiculous partial combinations when it met a
combining sequence if
>       two or more leading hangul jamos followed by hangul vowel
jamos, and produce
>       a syllable break condition (L.LV)
>
>  3. Compatibility hangul jamos are mapped into conjoining jamos
without any fillers.
>
>  Errors briefed in 1,2 and 3 came from  past poor cooperations
between UAX15 authors and Korean UTC participants, and NFC routines
> was already widely distributed.
>
>  Now I propose UTC make new normalizations (call it NFN)to correct
such errors and faults and
>     let stringprep include it after casefolding : that is
NFKC(NFN(casefold(x)).
>
>  We dont need to modify NFC and NFKC. Just add new correcting
normalizations as soon as possible.
>
>  Stringprep efforts should be in sync with further UTC's works. No
hastes!
>
>  Soobok Lee
>
>




From owner-idn@ops.ietf.org  Mon Feb 11 11:56: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 LAA09834
	for ; Mon, 11 Feb 2002 11:56:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJcg-0001QT-00
	for idn-data@psg.com; Mon, 11 Feb 2002 08:48:10 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJce-0001QM-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 08:48:08 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BGm6R25823
	for ; Tue, 12 Feb 2002 01:48:06 +0900
Message-ID: <0c2d01c1b31b$d0e21190$2b19fea9@temp>
From: "Soobok Lee" 
To: 
References: <0c0601c1b316$dfc16350$2b19fea9@temp> <001101c1b31b$50d3c7f0$08d8ea0c@c1340594a>
Subject: [idn] Re: stringprep comment 5: hangul conjoining sequence 
Date: Tue, 12 Feb 2002 01:47:38 +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


----- Original Message -----
From: "Mark Davis" 
To: "Soobok Lee" ; 
Cc: "Martin Duerst" ; "Mark Davis" 
Sent: Tuesday, February 12, 2002 1:44 AM
Subject: Re: stringprep comment 5: hangul conjoining sequence


> Syllable breaks are different than character boundaries. Please see
> http://www.unicode.org/versions/beta.html, where that is clarified.
>
> Now, of course, it would be possible to choose a different
> normalization. That has, however, been debated at great length on this
> list; see the archives. I see no pressing need for change.

That is a fundamental issue to us Koreans, not merely a practical or engineering
issues. The language and scripts are like  parts of our bodies and minds and spirits.

All IETF participants!
Be loyal to and pay greatest repects for local language communities, please.

Soobok Lee



>
> Mark
> —————
>
> Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
> [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
>
> http://www.macchiato.com
>
> ----- Original Message -----
> From: "Soobok Lee" 
> To: 
> Cc: "Martin Duerst" ; "Mark Davis"
> 
> Sent: Monday, February 11, 2002 08:12
> Subject: stringprep comment 5: hangul conjoining sequence
>
>
> > Two issues briefed in hangulchars drafts and in this mailling list,
> but not mentions in
> >   the latest nameprep and stringprep drafts:
> >
> >  1. When  old trailing hangul jamos are included in conjoining jamo
> sequences, UAX15(NFC)
> >      performs  partial combinations to produce  "a modern hangul
> syllable(LV) + a standalone
> >       old hangul jamo(oT)" and that form satify a ridiculous
> syllable break condition (X.T) .
> >
> >
> >  2. UAX15 also tries ridiculous partial combinations when it met a
> combining sequence if
> >       two or more leading hangul jamos followed by hangul vowel
> jamos, and produce
> >       a syllable break condition (L.LV)
> >
> >  3. Compatibility hangul jamos are mapped into conjoining jamos
> without any fillers.
> >
> >  Errors briefed in 1,2 and 3 came from  past poor cooperations
> between UAX15 authors and Korean UTC participants, and NFC routines
> > was already widely distributed.
> >
> >  Now I propose UTC make new normalizations (call it NFN)to correct
> such errors and faults and
> >     let stringprep include it after casefolding : that is
> NFKC(NFN(casefold(x)).
> >
> >  We dont need to modify NFC and NFKC. Just add new correcting
> normalizations as soon as possible.
> >
> >  Stringprep efforts should be in sync with further UTC's works. No
> hastes!
> >
> >  Soobok Lee
> >
> >




From owner-idn@ops.ietf.org  Mon Feb 11 12:08: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 MAA10568
	for ; Mon, 11 Feb 2002 12:08:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJlZ-0001mJ-00
	for idn-data@psg.com; Mon, 11 Feb 2002 08:57:21 -0800
Received: from rwcrmhc52.attbi.com ([216.148.227.88])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJlZ-0001mD-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 08:57:21 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020211165720.RCKD1147.rwcrmhc52.attbi.com@c1340594a>;
          Mon, 11 Feb 2002 16:57:20 +0000
Message-ID: <004101c1b31d$7ecd45d0$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "Soobok Lee" , 
References: <0c1f01c1b31a$b8b9caf0$2b19fea9@temp>
Subject: Re: [idn] IDNA comment 1 :  applications' own normalization vs stringprep
Date: Mon, 11 Feb 2002 08:59:40 -0800
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

>stringprep(NFC(x)) == stringprep(x)

This was brought up early in the Unicode 3.2 development. We have
programmatically checked, and I with dot is the only case that causes
a problem. It will be discussed at the UTC meeting this week. I have
no doubt that it will be resolved for U3.2, and even if StringPrep
doesn't pick up U3.2, it could add a mapping to that one case.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Soobok Lee" 
To: 
Sent: Monday, February 11, 2002 08:39
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  Mon Feb 11 12: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 MAA11239
	for ; Mon, 11 Feb 2002 12:17:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJsH-00022L-00
	for idn-data@psg.com; Mon, 11 Feb 2002 09:04:17 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJsG-00022E-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 09:04:16 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BH4AR25972;
	Tue, 12 Feb 2002 02:04:10 +0900
Message-ID: <0c5601c1b31e$0fa002a0$2b19fea9@temp>
From: "Soobok Lee" 
To: "Mark Davis" , 
References: <0c1f01c1b31a$b8b9caf0$2b19fea9@temp> <004101c1b31d$7ecd45d0$08d8ea0c@c1340594a>
Subject: Re: [idn] IDNA comment 1 :  applications' own normalization vs stringprep
Date: Tue, 12 Feb 2002 02:03:43 +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


----- Original Message -----
From: "Mark Davis" 
To: "Soobok Lee" ; 
Sent: Tuesday, February 12, 2002 1:59 AM
Subject: Re: [idn] IDNA comment 1 : applications' own normalization vs stringprep


> >stringprep(NFC(x)) == stringprep(x)
>
> This was brought up early in the Unicode 3.2 development. We have
> programmatically checked, and I with dot is the only case that causes
> a problem. It will be discussed at the UTC meeting this week. I have
> no doubt that it will be resolved for U3.2, and even if StringPrep
> doesn't pick up U3.2, it could add a mapping to that one case.

Okay!     I am glad to make useful contributions to UNICODE.

The honor is mine!

But, still we may have many compensation UTC or non-UTC normalizations
especially for hangul or other scripts, and that will make similar stringprep
faiilures..

That is , the possibility of     stringpre(newnormlization(x) != stringpre(x).

Soobok Lee


>
> Mark
> —————
>
> Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
> [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
>
> http://www.macchiato.com
>
> ----- Original Message -----
> From: "Soobok Lee" 
> To: 
> Sent: Monday, February 11, 2002 08:39
> 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
> >
> >
> >
> >
> >
> >
> >




From owner-idn@ops.ietf.org  Mon Feb 11 12:24: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 MAA11619
	for ; Mon, 11 Feb 2002 12:24:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aJyE-0002Jd-00
	for idn-data@psg.com; Mon, 11 Feb 2002 09:10:26 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aJyC-0002JV-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 09:10:24 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BHALR25997
	for ; Tue, 12 Feb 2002 02:10:21 +0900
Message-ID: <0c5701c1b31e$ecb4d7b0$2b19fea9@temp>
From: "Soobok Lee" 
To: 
Subject: [idn] stringprep comment 6:  casefold and then noramlization is not enough
Date: Tue, 12 Feb 2002 02:09:53 +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


As I and David Hopwood suggested in the list,

  NFC(casefold(x)) or NFKC(casefold(x)) are not correct for  and .

  Rather, NFKC(casefold(NFKC(x)) is the correct one, even though it's not efficient.

  And There may be new UTC or non-UTC normalization that may applid before stringpre
   in various future i18n applications.


But, in current Stringprep draft in its section 2,

"2. Preparation Overview

The steps for preparing strings are:

1) Map -- For each character in the input, check if it has a mapping
and, if so, replace it with its mapping. This is described in Section 4.

2) Normalize -- Possibly normalize the result of step 1 using Unicode
normalization. This is described in Section 5.

3) Look for prohibited output -- Check for any characters that are not
allowed in the output. If any are found, return an error. This is
described in Section 6.

The above steps MUST be performed in the order given to comply with this
specification."

Please suggest a proof that this last enforcement is necessary and sufficient.

I suggest  the last "MUST" be changed to "MAY" .
this 3-staged stringprep may be not sufficient for future
diverse i18n appliations and protocols.
Too early freeze-up of stringprep architures from over-simplifications does
not help the stringprep to last long, IMHO.


Soobok Lee

 




From owner-idn@ops.ietf.org  Mon Feb 11 12:38: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 MAA12172
	for ; Mon, 11 Feb 2002 12:38:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aKCr-0002sz-00
	for idn-data@psg.com; Mon, 11 Feb 2002 09:25:33 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aKCq-0002sj-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 09:25:32 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4nCUu51NAqpDH92CpEnzjYg==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GTDSMLWK; Mon, 11 Feb 2002 12:24:13 EST
To: klensin@jck.com
Cc: deng@cnnic.net.cn, jseng@pobox.org.sg, idn@ops.ietf.org
Date: Mon, 11 Feb 2002 09:34:23 -0800
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <20020211.093423.-412797.0.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-29,31-102
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear John:

I appreciate your understanding of all the problems the IDN 
does not solve. The differences between the WG and the 
CDN group is not a political issue at its base.  WG is trying 
to push TC/SC out of IDN.  The CDN and the others argue
for them to be dealt with in IDN. 

If you consider IDN is a part of DNS, then the CDN group 
say "NO, NO, NO" with force for you and the WG to raise 
eyeballs.   And I hope they have accomplished it with 
all their protests.  

If you consider IDN is above DNS then you are agreeing 
with CDN group. 

If you admit that you are not an expert in dealing with 
Han charaters processing then you should give a good 
and hard study regarding what they have been saying 
all along.

If you are understand what Xiang Deng is saying then 
don't introduce political arguements.  It doesn't help the 
communication at all. 

Regards,

Liana Ye


On Fri, 08 Feb 2002 22:35:33 -0500 John C Klensin 
writes:
> --On Saturday, 09 February, 2002 10:10 +0800 xiang deng
>  wrote:
> 
> > Chair's responsibily is not to create conflict but to collect
> > all different argument and coordinate to find a possible
> > solution.
> 
> Under normal IETF procedures, which apply to this Working Group
> as well, the Chair's responsibility, at this stage in the
> process, is to move work along.  That includes, quite
> explicitly, 
> 
> 	* Discouraging the further discussion of topics on which
> 	the WG has already reached a conclusion.
> 	
> 	* Discouraging discussion of problems that are either
> 	out of the WG's scope, or for which realistic solutions
> 	(e.g., solutions that deal with all appropriate cases)
> 	have not been proposed.
> 
> James (and Marc) have, if anything, been more tolerant of
> extended discussions of topics the WG can't fix, or has already
> reached consensus that it won't try to fix, than is normal in
> the IETF.
> 
> Since I have started on this, I am very concerned about the very
> real and serious problems with TC<->SC.  I am also very
> concerned about problems with look-alike characters in
> alphabetic character sets.  I am also very concerned about the
> implications of non-language characters in Unicode that, from my
> point of view, don't belong in the DNS (however coded).  
> 
> I have raised those issues with the WG, discovered that the WG
> isn't interested in the problems, and gone on to worry about
> contexts in which those problems _can_ be solved.   That does
> not make me worry less, nor does it mean that I think the
> problems are unimportant.  But, until and unless I think I have
> new arguments or evidence, I don't bring them up again, and I
> would _expect_ James or Marc to tell me that I'm out of order if
> I did.  I also don't try to convince the WG that those topics
> are important by getting many people --who have not been
> participating in the WG's work-- to send identical notes
> complaining, nor do I circulate notes to other groups in the
> hope that they will somehow overrule the WG.  I avoid doing
> those things for two reasons: they are considered in very bad
> taste in the IETF and they never convince anyone; instead, they
> tend to irritate people enough that they stop listening.
> 
> What is strange, to me, about this discussion is that there is a
> way to delay CDN deployment without impacting Korean or
> Japanese.  It is fairly simple, and does not require that the
> IDN WG agree. And I had assumed it would be obvious to everyone.
> Specifically, the four NICs simply refuse to register such
> names.  You try to convince Singapore and other countries with
> large Chinese-speaking populations to join them in that
> prohibition.  You expand on Erin's document, some of Prof
> Tseng's notes, and other comments and examples which have been
> introduced here to provide other registries cautions about the
> problems they could cause by registering such names.  And you
> try to convince ICANN to prohibit those names in gTLDs.   From
> the perspective of this WG, that is a policy move, made in
> policy forums.  The fact that the WG provides a _mechanism_ for
> encoding CDNs does not imply that any registry need _permit_
> CDNs.  And it seems to me that, at this late date and given the
> overlapping Japanese and Korean issues, that may be your most
> efficient way forward on this particular problem.
> 
> regards,
>      john
> 
> 



From owner-idn@ops.ietf.org  Mon Feb 11 12:44: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 MAA12376
	for ; Mon, 11 Feb 2002 12:44:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aKMN-0003Ft-00
	for idn-data@psg.com; Mon, 11 Feb 2002 09:35:23 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aKML-0003Fj-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 09:35:21 -0800
Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1BHZ3h13168;
	Mon, 11 Feb 2002 18:35:04 +0100 (MET)
From: "Kent Karlsson" 
To: "'Soobok Lee'" , 
Cc: "'Martin Duerst'" ,
        "'Mark Davis'" 
Subject: RE: [idn] stringprep comment 5: hangul conjoining sequence 
Date: Mon, 11 Feb 2002 18:32:15 +0100
Message-ID: <001201c1b322$0d156350$d5d61081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <0c0601c1b316$dfc16350$2b19fea9@temp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Soobok Lee
...
>  1. When  old trailing hangul jamos are included in 
> conjoining jamo sequences, UAX15(NFC)
>      performs  partial combinations to produce  "a modern 
> hangul syllable(LV) + a standalone
>       old hangul jamo(oT)" and that form satify a ridiculous 
> syllable break condition (X.T) .

There is no syllable break there.  There may be a sequence of L before
a Hangul syllable character, and a sequence of T after it, without any syllable
break inbetween.  For some of the Hangul syllable characters, there may even
be both Vs and Ts after, without there being a syllable break.

>  2. UAX15 also tries ridiculous partial combinations when it 
> met a combining sequence if
>       two or more leading hangul jamos followed by hangul 
> vowel jamos, and produce
>       a syllable break condition (L.LV)

There is no syllable break there.  [Skipping syllable characters for the moment]
Note that a Hangul syllable consists of a non-empty **sequence** of L, followed
by a non-empty **sequence** of V, followed by a (possibly empty) **sequence** of T.
Note that in many cases compatibility equivalents with regard to these were
(erroneously) made non-equivalent between Unicode 2.1 and Unicode 3.0. 

>  3. Compatibility hangul jamos are mapped into conjoining 
> jamos without any fillers.

Compatibility (non-conjoining) Hangul letters are best prohibited.  Doing
the correct mapping is not expressible in via nameprep without adding
a new, special for Hangul, mechanism.  Would there be any major problems
just prohibiting them? (Allowing only the conjoining jamo and syllable characters.)

...
>  Now I propose UTC make new normalizations (call it NFN)to 
> correct such errors and faults and
>     let stringprep include it after casefolding : that is  
> NFKC(NFN(casefold(x)).

I have suggested a solution that involves only additions to the tables in
"nameprep" (these include prohibiting non-conjoining compatibility Jamo
as well as the Hangul filler characters).  Table available upon request.

I agree that it is very unfortunate that "letter sequence" equivalent strings,
like [gg] (SSANGKIYEOK) and [g][g] () are not
formally equivalent in Unicode; indeed these should have been canonically
equivalent; but the normal forms are by now frozen, and I don't think anyone
wants to have yet another Unicode formal equivalence or normal form.

		Kind regars
		/kent k




From owner-idn@ops.ietf.org  Mon Feb 11 13:22: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 NAA13234
	for ; Mon, 11 Feb 2002 13:22:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aKyv-0004ZS-00
	for idn-data@psg.com; Mon, 11 Feb 2002 10:15:13 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aKyt-0004ZK-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 10:15:12 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BIF2R26305;
	Tue, 12 Feb 2002 03:15:02 +0900
Message-ID: <0ca001c1b327$f6a1a650$2b19fea9@temp>
From: "Soobok Lee" 
To: "Kent Karlsson" , 
Cc: "'Martin Duerst'" ,
        "'Mark Davis'" 
References: <001201c1b322$0d156350$d5d61081@chalmers95a69n>
Subject: Re: [idn] stringprep comment 5: hangul conjoining sequence 
Date: Tue, 12 Feb 2002 03:14:35 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
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

Hi, Kent

----- Original Message ----- 
From: "Kent Karlsson" 
 
> >  3. Compatibility hangul jamos are mapped into conjoining 
> > jamos without any fillers.
> 
> Compatibility (non-conjoining) Hangul letters are best prohibited.  Doing
> the correct mapping is not expressible in via nameprep without adding
> a new, special for Hangul, mechanism.  Would there be any major problems
> just prohibiting them? (Allowing only the conjoining jamo and syllable characters.)
> 

That's impossible. Unicode-issued KSC5601 ==> UNicode mapping tables
 provides "hangul legacy code jamos --> Unicode u+3??? compability jamos".
 When ordinary Korean users enter hangul jamo sequence in 
all version of Windows or LInux which adop the table above, 
those legacy-coded jamo sequences will be eventually converted into 
Unicode compatibility jamos sequence. There is no way to input directly  conjoining jamo sequences
including necessary fillers and that will be painfully complex to end users.

And Even windows and linux does not render correctly the conjoining jamo sequence including fillers.
The compability jamos are the only viable alternative for correct jamo sequence rendering in
commerical windows and linux platforms.

Soobok 




From owner-idn@ops.ietf.org  Mon Feb 11 13:32: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 NAA13425
	for ; Mon, 11 Feb 2002 13:32:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aL84-0004u2-00
	for idn-data@psg.com; Mon, 11 Feb 2002 10:24:40 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aL82-0004tu-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 10:24:38 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1BIOZR26353
	for ; Tue, 12 Feb 2002 03:24:35 +0900
Message-ID: <0cae01c1b329$4be05a70$2b19fea9@temp>
From: "Soobok Lee" 
To: 
Subject: [idn] Punycode comment:  hangul reordering
Date: Tue, 12 Feb 2002 03:24:03 +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

Many of this WG participants may remember that I was the first supporter of ACE-Z (PUNYCODE). :-)

Reordering for chinese letters  had met some objections from japanese participants,
while it could benefit billions of other chinese end users.
But for reordering for hangul syllables  there were no significant objections.

Hangul is the most benefited scripts by reordering (25% , up to 60% shorter for frequent names). 
I hope This WG may consider an option to include limited reordering in in PUNYCODE.
It's consisted of very compact and simple table.

Thanks.

Soobok Lee


 




From owner-idn@ops.ietf.org  Mon Feb 11 14:12: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 OAA14332
	for ; Mon, 11 Feb 2002 14:12:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aLmj-0006Os-00
	for idn-data@psg.com; Mon, 11 Feb 2002 11:06:41 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aLmi-0006Ol-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 11:06:40 -0800
Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1BJ6Uh17352;
	Mon, 11 Feb 2002 20:06:30 +0100 (MET)
From: "Kent Karlsson" 
To: "'Soobok Lee'" , 
Cc: "'Martin Duerst'" ,
        "'Mark Davis'" ,
        "'Jungshik Shin'" 
Subject: RE: [idn] stringprep comment 5: hangul conjoining sequence 
Date: Mon, 11 Feb 2002 20:03:42 +0100
Message-ID: <001501c1b32e$d339e9a0$d5d61081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <0ca001c1b327$f6a1a650$2b19fea9@temp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Soobok Lee [mailto:lsb@postel.co.kr]

> ----- Original Message ----- 
> From: "Kent Karlsson" 
>  
> > >  3. Compatibility hangul jamos are mapped into conjoining 
> > > jamos without any fillers.
> > 
> > Compatibility (non-conjoining) Hangul letters are best prohibited.  Doing
> > the correct mapping is not expressible in via nameprep without adding
> > a new, special for Hangul, mechanism.  Would there be any major problems
> > just prohibiting them? (Allowing only the conjoining jamo and syllable characters.)
> > 
> 
> That's impossible. Unicode-issued KSC5601 ==> UNicode mapping tables
>  provides "hangul legacy code jamos --> Unicode u+3??? 
> compability jamos".

Yes. 

>  When ordinary Korean users enter hangul jamo sequence in 
> all version of Windows or LInux which adop the table above, 
> those legacy-coded jamo sequences will be eventually converted into 
> Unicode compatibility jamos sequence. There is no way to 
> input directly  conjoining jamo sequences
> including necessary fillers and that will be painfully 
> complex to end users.

Keyboard drivers+IME handling for Hangul often take Hangul compatibility
letters and (when the IME deems appropriate) **replaces** subsequences
of (maybe a Hangul syllable character and) Hangul compatiblity letters with
a Hangul syllable character.

It is true that many IMEs may not be able to produce all and any Hangul syllable,
in the logical sense, not even all and any Hangul syllable Johab character.  But
that is beside the point here.

> And Even windows and linux does not render correctly the 
> conjoining jamo sequence including fillers.

True, but that is a lack of support issue with those systems, and should be
taken up in some other forum.

> The compability jamos are the only viable alternative for 
> correct jamo sequence rendering in
> commerical windows and linux platforms.

The compatibility letters render as spacing characters; they do not normally
conjoin into syllable blocks.  Doing that analysis (with a filler to tell that a
"compatibility 'maybe conjoning'" sequence begins) of the input and proper
conversion to Hangul conjoining jamo is still beyond what nameprep can do
with just simple additions to the tables. Adding a proper, and Hangul specific,
conversion step *to nameprep* seems inappropriate.  This is an input issue.
But yes, that conversion may be useful, but I would not push it into nameprep.

A "better keyboard" could generate the conjoining single-letter jamos directy,
without using any IME (17 consonants (twice, via shift: lead, trail) and 11 vowels
plus some very few historic variants fit easily on a keyboard).  Indeed, there would
then be no problem in typing all and any Hangul syllable (in the logical sense), as
long as the result could be fitted into a rendered syllable block. But such a keyboard
would be appropriate only after the display issue became obsolescent; which it
isn't yet.  However, it may someday relatively soon be an obsolescent rendering
problem.  (Netscape 6 is close to rendering them correctly already:
http://jshin.net/i18n/jamo.html)

		Kind regards
		/kent k


> Soobok 
> 



From owner-idn@ops.ietf.org  Mon Feb 11 14:53: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 OAA15396
	for ; Mon, 11 Feb 2002 14:53:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aMNx-0007pG-00
	for idn-data@psg.com; Mon, 11 Feb 2002 11:45:09 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aMNw-0007p8-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 11:45:08 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16aMNm-0007r8-00; Mon, 11 Feb 2002 19:44:58 +0000
Date: Mon, 11 Feb 2002 14:44:41 -0500
From: John C Klensin 
To: liana Ye 
cc: deng@cnnic.net.cn, jseng@pobox.org.sg, idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <77460165.1013438681@localhost>
In-Reply-To: <20020211.093423.-412797.0.liana.ydisg@juno.com>
References:  <20020211.093423.-412797.0.liana.ydisg@juno.com>
X-Mailer: Mulberry/2.2.0b2 (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, 11 February, 2002 09:34 -0800 liana Ye
 wrote:

> Dear John:
> 
> I appreciate your understanding of all the problems the IDN 
> does not solve. The differences between the WG and the 
> CDN group is not a political issue at its base.

I think I understand that, as do, I think, most of the
participants in the WG.  If I correctly understand what they are
saying when they make comments about political issues, those
comments are based on three things:

(i) Whomever and whatever initiated the process, much of the
IETF reacts very badly to attempts to influence a working group
(or other effort) by letter-writing campaigns that involve a
large number of people sending the same note or notes,
especially when those people have not be participating in the
WG.  Such note-sending campaigns are a political action, not an
engineering one.  They are also considered in such bad taste
that they may damage the position they are trying to advocate:
the reaction is, more or less, "they have completely run out of
technical arguments and  are falling back to creating a lot of
noise; this action indicates that even they do not believe in
their technical arguments".

(ii) We have a continuing communications disconnect in which
some members of the Chinese-speaking community are, apparently,
so astonished that their positions are not immediately accepted
by the WG that they assume that no one [else] in the WG cares
about the impact of this work on names written in Chinese
characters.  Again, that leads to statements being made that
sound to others as if reasoning has been abandoned in favor of
political actions.

(iii) There is also a perception that the CDNC group, and some
others, are ignoring or dismissing the problems with Japanese
and Korean that would be induced by special mappings for Chinese
and, similarly, that many careful explanations of why
specialized TC<->SC handling is not analogous to case-mapping in
alphabetic character sets.  Again, this is a failure to
communicate (perhaps on both sides) at a very fundamental level
that is leading to ill-feeling and beliefs that decision are
being made on a political or emotional basis, rather than with
full understanding and acceptance of the engineering constraints
and tradeoffs.

> WG is trying 
> to push TC/SC out of IDN.  The CDN and the others argue
> for them to be dealt with in IDN. 

Again, let me try to explain this a little bit differently.
There is a very strong conviction in the IETF that one of the
issues, perhaps the key issue, in Internet protocol design is
scaling.  The scaling concerns are usually though of as applying
to "size of the Internet" issues -- e.g., we try to avoid
standardizing anything that can work only in a restricted
environment or under other "small network" constraints.  But
they also apply to partial solutions: if a particular aspect of
a problem or design activity seems to require a comprehensive
solution, but none is immediately available, the IETF will tend
to avoid a partial solution until the comprehensive one and a
migration strategy are well understood.

The other difficulty with the "consumer confusion" aspects of
the CDN discussion is that many of the comments seem to ignore a
point that has been made repeatedly in the WG: these issues
exist, in some form, for almost every language and script we
have investigated. All of the "equivalent character"
discussions, the similarity of some characters among, e.g.,
"Latin", Cyrillic, and Greek scripts, and related issues point
to considerable possibility of user confusion, misrouted
queries, and so on.  One might even suggest that the CDNC
complaints have been inappropriately focused on Chinese
characters and that the statement should have been "this will
cause problems all over the world, and the IDN effort should
just stop".  The people in the WG who have put in huge amounts
of effort trying to get _something_ to work probably would not
accept that either, but the position would more nearly recognize
the realities of likely IDN usage.

And that brings me to what I think it is the real problem here,
and it a problem that many of us, including those taking the
lead on IDNA (and nameprep, etc) have understood for most of the
time that the WG has been working on these problems.  There are
many problems with the use of words in languages that cannot be
dealt with in the DNS and some other solution will be needed.
Full TC<->SC matching (of all combinations) appears to fall into
that category.  So does the Greek-Cyrillic-Latin problem, and
the ASCII 0<->O and 1<->l problems.  So does a really
satisfactory solution to the "invisible character" problem, some
issues with Arabic/Hebrew/Yiddish vowels, and so on.  Mark's
notion of using presentation mechanisms to identify unusual
character combinations is, I think, quite ingenious but it isn't
part of the DNS either.  Your notions about phonetic mappings
fall into this category as well.  But the two things that all of
these problems and approaches have in common is the potential
for user confusion (or fraud) --some of it serious-- and the
fact that none of them can be dealt with by the simplistic
matching rules of the DNS.  Instead, we need user choices, or
likelihood functions, or fairly serious language recognition, or
knowledge the DNS doesn't have, or heuristics of some [other]
variety.  And the problems aren't limited to Chinese, even
though they manifest themselves differently.

Now I suggest that almost everyone who has been participating
actively in this effort knows that by now.  We know that other,
non-DNS, mechanisms are going to be needed to accomplish
satisfactory internationalization.  Given that, the hard problem
is whether it makes sense to tamper with the DNS at all.  And,
if one is going to do that, what the right set of constraints is
to prevent some of the worst possible damage.   My reading of
the consensus in the WG is that they believe that eliminating
(or postponing) every script that raises problems is not a
solution: we would rapidly have to eliminate all scripts,
possibly including the LDH subset of ASCII.

I think the WG believes that there are three options, and that
most of its members has eliminated the third from consideration:

	(a) Use Nameprep, or something very much like it, which
	deals with mappings that are complete (i.e., there is no
	controversy about them and no need for examination of
	surrounding characters, other context, or language
	information to do them properly) and which excludes
	characters that are problematic in any context in which
	they appear.
	
	(b) Adopt a very strict "identifier" rule in which
	nameprep becomes unnecessary: characters from the
	permitted repertoire can be intermixed in any way,
	without restrictions, comparisons are made on those
	characters only, and the users will somehow learn to
	cope with the results.
	
	(c) Give it up, keep text labels in the DNS restricted
	to the LDH rules, and do _all_ internationalization
	"somewhere else".

> If you consider IDN is a part of DNS, then the CDN group 
> say "NO, NO, NO" with force for you and the WG to raise 
> eyeballs.   And I hope they have accomplished it with 
> all their protests.

I fear not.  Many of us were fully aware of the problems, and
very concerned about them, before now, and even before Salt Lake
City.    For some of us, the protests have been successful only
in taking up time that should have gone into the "above DNS"
work.  For others, they have distracted from the effort to
carefully review and adjust the details of what nameprep should
be doing in areas where it can constitute a nearly-100%
solution. And, as I have suggested above and elsewhere, they
have led many people to the conclusion (whether correct or
incorrect) that the real goal of the CDNC protest was to disrupt
the work of the WG without offering real alternatives or a way
forward.

> If you consider IDN is above DNS then you are agreeing 
> with CDN group. 

As I trust you know, I have been suggesting that much critical
IDN work will have to be done "above DNS" since before either
the WG or MINC got started.  But to agree on that principle does
not necessarily imply agreement on details of what the WG should
do.

> If you admit that you are not an expert in dealing with 
> Han charaters processing then you should give a good 
> and hard study regarding what they have been saying 
> all along.
> 
> If you are understand what Xiang Deng is saying then 
> don't introduce political arguements.  It doesn't help the 
> communication at all. 

I didn't raise any political arguments in the note of mine that
you quoted, nor did I use that word.  "Policy" issues and
decisions are another matter entirely.   And, while I assume
neither you nor Xiang Deng did so either, I didn't set off the
letter-writing campaign.

regards,
    john




From owner-idn@ops.ietf.org  Mon Feb 11 15:48: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 PAA16771
	for ; Mon, 11 Feb 2002 15:48:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aNEU-0009qK-00
	for idn-data@psg.com; Mon, 11 Feb 2002 12:39:26 -0800
Received: from gate.sinica.edu.tw ([140.109.4.130])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aNET-0009qE-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 12:39:25 -0800
Received: from itsnb (i2ot1.iis.sinica.edu.tw [140.109.21.153])
	by gate.sinica.edu.tw (8.11.3/8.11.3) with SMTP id g1BKdNs20649
	for ; Tue, 12 Feb 2002 04:39:23 +0800 (CST)
Message-ID: <01ac01c1b33c$42f95250$f1d120a3@itsnb>
From: "Chun-Hsin Wu" 
To: 
Subject: [idn] Comments on Nameprep: incomplete preparation
Date: Tue, 12 Feb 2002 04:39:48 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_01A7_01C1B37F.4D4C2960"
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

This is a multi-part message in MIME format.

------=_NextPart_000_01A7_01C1B37F.4D4C2960
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit

Last call comments to draft-ietf-idn-nameprep-07.txt:

   In Unicode 3.1, unified Han ideographs occupy slightly more than 75%
    of the total encoded characters; CJK is a major subset of Unicode.
   Since Nameprep uses Unicode 3.1 as the repertoire for IDN, CJK-DN
   is also a part of IDN. ( http://www.unicode.org/unicode/reports/tr27/ )

   As demonstrated in:
      http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm
      (referenced by http://www.imc.org/idn/mail-archive/msg05795.html )
      http://www.iis.sinica.edu.tw/~wuch/idn/examples/variant.htm
   Many CJK variants in Unicode 3.1 are similar-looking and
   easy-confusing for typical users, but they were not adequately considered
   in Nameprep. The CJK sub-space of the IDN Identifiable Namespace
   implicitly defined by Nameprep will then make IDN ambiguous and
   disputatious. Even by registration policy, a standardized preparation for
   CJK-DN is still required to maintain the globalness and uniqueness of
   IDN without distrusting the IDN namespace.

So draft-ietf-idn-nameprep-07.txt should be revised
    to explicitly address that this draft is incomplete and another
           preparation for CJK-DN parts is required to achieve
           completely-prepared IDN,
    or to explicitly address that this draft
          does not process Han ideographs of Unicode 31.


Chun-Hsin Wu

------=_NextPart_000_01A7_01C1B37F.4D4C2960
Content-Type: text/plain;
	name="idn-namespace.txt"
Content-Disposition: attachment;
	filename="idn-namespace.txt"
Content-Transfer-Encoding: 7bit

** Identifier

                  Encoded/Represented       Prohibited
        Language           -->   Encoding Set   -->  DNS Identifier Set
        What seen/heard
        (glyph/script/font)        char                 Identifier
        Human name                 String             Domain Name(label)
        (Infinite)                 (Limited)           (Restricted)

  DNS:  English-Only       -->     US-ASCII     -->   LDH [\-A-Za-z0-9]
  IDN:  Multi-lingual      -->   Unicode  3.1   -->  Nameprep-prohibited

        Language-level           Encoding-level       Identifier-level
         conversion                conversion            conversion


** DNS Namespace: based on DNS Identifier Set

                                  Equivalent
          DNS Syntactic Namespace  =======>  DNS Identifiable Namespace
Size~=  Sigma  (26*2+10+1)^i, i<=63           ~= (26+10+1)^i, i<=63
  DNS:                          Case mapping

  NamePrep:                Mapping/Normalization          ?????
                    KC form: CJK Compatibility Ideographs
                    (U+F900 ~ U+FA2D Compatibility Table)

  +TSConv:                Unified CJK Equivalence
                     (TSConv: context-free, identifier-level)

                            Equivalent(IDN1,IDN2)?
              Valid(IDN)?  =======================>  Resolver(IDN)


   Trustable IDN Identifiable Namespace:
      . Finite (Stable)
      . Global (Consistent)
      . Unique (Unambiguous)

   Design constraints:
      . Backward compatibility => ACE-ed
      . Forward compatibility

   A CJK equivalence table is then necessary for IDN to declare
   its IDN identifiable namespace such that it can be trusted and
   globally unique, regardless of where the table should be
   referenced (client/server).

------=_NextPart_000_01A7_01C1B37F.4D4C2960--




From owner-idn@ops.ietf.org  Mon Feb 11 16: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 QAA17481
	for ; Mon, 11 Feb 2002 16:19:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aNjG-000B3A-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:11:14 -0800
Received: from gate.sinica.edu.tw ([140.109.4.130])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aNjE-000B2q-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:11:13 -0800
Received: from itsnb (i2ot1.iis.sinica.edu.tw [140.109.21.153])
	by gate.sinica.edu.tw (8.11.3/8.11.3) with SMTP id g1BLBBs29315
	for ; Tue, 12 Feb 2002 05:11:11 +0800 (CST)
Message-ID: <01f301c1b340$b4017dc0$f1d120a3@itsnb>
From: "Chun-Hsin Wu" 
To: 
Subject: [idn] IDN Charter
Date: Tue, 12 Feb 2002 05:11:35 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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

Dear Friends,

In the approved and published IDN charter at
        http://www.ietf.org/html.charters/idn-charter.html
last modified on Oct 16, 2001,

Description of Working Group:
        The goal of the group is to specify the requirements for
internationalized
        access to domain names and to specify a standards track protocol
based
        on the requirements.

I'm curious whether the lastcall drafts are really based on 'the
requirements'.
Meanwhile, the CDN requirements from JET/CJK consensus are proposed.

Thank you very much for your attention.

Regards,

Chun-Hsin Wu




From owner-idn@ops.ietf.org  Mon Feb 11 16:36: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 QAA17960
	for ; Mon, 11 Feb 2002 16:36:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aNtn-000BUj-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:22:07 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16aNtl-000BUV-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:22:06 -0800
Received: (qmail 7509 invoked by uid 1001); 11 Feb 2002 21:13:43 -0000
Date: 11 Feb 2002 21:13:43 -0000
Message-ID: <20020211211343.24889.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

John C Klensin writes:
> many careful explanations of why specialized TC<->SC handling is not
> analogous to case-mapping in alphabetic character sets.

Here is James Seng's answer to the TC/SC complaints:

   The user behavior education about domain names should be that domain
   names are identifier, not names. They should enter into the computer
   exactly as they seen it or reference it.

This answer destroys the stated reasons for case-mapping. (Case-mapping
was, in turn, the primary excuse for sticking IDNA into applications.)

This is not just an analogy. It is a literal application of Seng's
principle. Do you think that the principle is incorrect? If so, what
exactly is wrong with it?

I agree with your comment that these issues go beyond Chinese. We have
vowels in Hebrew, accents on capital letters in French, o-umlaut and oe
in German, etc. But I do not agree with your claim that this has all
been settled in previous IDN discussions. Nobody has given a coherent
explanation of _why_ IDNA needs to do certain mappings and not others.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Mon Feb 11 16:36: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 QAA17986
	for ; Mon, 11 Feb 2002 16:36:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aO0g-000BoS-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:29:14 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aO0e-000Bnr-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:29:13 -0800
Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA15410
	for ; Mon, 11 Feb 2002 22:29:09 +0100 (MET)
Date: Mon, 11 Feb 2002 22:28:55 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <2279566.1013466535@localhost>
In-Reply-To: <20020211211343.24889.qmail@cr.yp.to>
References: <20020211.093423.-412797.0.liana.ydisg@juno.com>
 <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
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 2002-02-11 21.13 +0000 "D. J. Bernstein"  wrote:

> Nobody has given a coherent
> explanation of _why_ IDNA needs to do certain mappings and not others.

Because we do comparison of Unicode strings.

See http://www.unicode.org/unicode/faq/normalization.html

I.e. not our choice (more than choosing to use Unicode).

   paf




From owner-idn@ops.ietf.org  Mon Feb 11 16:36: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 QAA18036
	for ; Mon, 11 Feb 2002 16:36:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aNxk-000Bft-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:26:12 -0800
Received: from gate.sinica.edu.tw ([140.109.4.130])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aNxi-000Bfl-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:26:11 -0800
Received: from itsnb (i2ot1.iis.sinica.edu.tw [140.109.21.153])
	by gate.sinica.edu.tw (8.11.3/8.11.3) with SMTP id g1BLPxs02502;
	Tue, 12 Feb 2002 05:25:59 +0800 (CST)
Message-ID: <020001c1b342$c53edf90$f1d120a3@itsnb>
From: "Chun-Hsin Wu" 
To: "James Seng/Personal" 
Cc: 
References:  <029f01c1b026$2920dd30$0f01000a@jamessonyvaio> <00b801c1b056$0ade4760$49156d8c@acer603> <072b01c1b058$6bda16f0$0f01000a@jamessonyvaio> <021e01c1b0e5$611d15e0$c5e16d8c@itsnb> <080b01c1b0ff$cfcd93b0$dd00a8c0@jamessonyvaio>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Tue, 12 Feb 2002 05:26:23 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
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 "James Seng/Personal" 
> 1. Lets do away with the personal attack on me. It does nothing to help
> your arguments.
Agree. I'm not interested in personal attack.
 
> 2. I acknowledge I am weaker in my daily chinese compared to people in
> China/Taiwan, this does not mean I do not know the chinese script and
> its orthography. And no, I understand you perfectly well. But I doubt
> you understand (or hear) me - See note 6.
I'd like to learn more experiences from you. :-)

> 3. Have you speak to your IRG and SC2 representives lately and ask them
> about this problem? What is their unambigitous response?

There are differences among name conversion, unicode conversion and
DNS identifier conversion.

> 4. I stand correct in my statement last mail: You can input either TC or
> SC by manually scrolling down the system. Your screen shot represent
> nothing. Different IME will give you different predictive result
> depending on the frequency of a personal usage of the characters.
> Therefore, a screen shot on your computer would be totally different
> from mine.

At least the IMEs used in my last examples do not depend on the
frequency of personal usage. If you do try these examples, you should
be able to see the same screent shot as mine.
This is one of the design points for IME. Other IMEs may depend on
personal usage, but the demonstrated IMEs don't.

> 5. You have only repeated problems that we already knows. You have not
> demonstrated any solution which is technical possible now. This is not a
> 3 months or 30yrs plan thing. It is about what is technically feasible
> and what is not.
Hope IDN friends do really understand the problems.

> 6. Maybe working for another 30yrs time, we might come up with an AI
> that can do TC/SC, and for all the other language issues. But it appears
> you and your colleague continue to ignore (something we been telling you
> again and again):
>     1. DNS is an identifier system. We deal with scripts, not languages.
>     2. Human language is complex. Expect DNS to deal with language
>             is technically impossible right now. (Proof me otherwise).

I think IDN is also complex. :P
Hopefully, we don't expect language-level conversion or complete
Unicode conversion, what we need is identifier-level conversion,
for identifying domain name rather than solve all the conversion issues
in Unicode or human-space.

> 7. . Since TWNIC is so insistent on the solution, I suggest TWNIC (or
> anyone else) put a total ban on all chinese characters in the
> registration system. That will also solve your so-called "2^n" problem
> in your system. Then continue to work with IRNSS (or some other areas)
> for a solution you can accept.
Is it a personal or organizationall attack?
I'm a researcher and I do not stand for TWNIC.
I expect a global unique IDN, not a fragmented DNS nor Internet world.

> 8. Some suggestions: If you want other to consider your issues
> favourably, then
>     1. present your arguments unbiasly.
>     2. consider a broader scope of the problem
>     3. understand other people issues and willingness to compromise
>     4. learn how the process works in IETF
> So far, I have seen all otherwise.

Personal attacks again?  :P

Chun-Hsin Wu




From owner-idn@ops.ietf.org  Mon Feb 11 16:37: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 QAA18065
	for ; Mon, 11 Feb 2002 16:37:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aNxE-000Ber-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:25:40 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aNxD-000Bek-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:25:39 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55241 for idn@ops.ietf.org; Mon, 11 Feb 2002 15:25:01 -0600
Message-ID: <3C6836CE.8A77B0CE@ehsco.com>
Date: Mon, 11 Feb 2002 15:25:34 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@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


[this is part 1 of a multi-part response]

"Adam M. Costello" wrote:

> "Eric A. Hall"  wrote:

> > The point here is that EVERY network service has its own
> > considerations.  Demanding that all services implement a user-level
> > feature is absurd.
> 
> We recommend, we don't demand.

 | 2) ACE labels SHOULD be hidden from users whenever possible.

Just to be clear, is your argument that the use of SHOULD does not impose
mandatory behavior? See 2119:

 | 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.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SHOULD defines *default* behavior, it is mandatory UNLESS there is a
reason NOT to do it.

The word you are looking for is MAY, but I would argue with that as a
default position as well.

> And we don't try to apply the user-level feature in absurd places,
> we say "before a domain name is displayed to a user or is output into
> a context likely to be viewed by users".

The problem I have here is that you apply to ALL places, some of which are
absurd, some of which are not. You need to choose your defaults with
greater position. The default you have chosen results in tremendous
absurdities. Consider the following DEFAULT mandatory interpretation:

  From: 
  To: 

  Please add zz--gobbledygook to your sendmail.cf file

which is converted BY DEFAULT into

  Please add  to your sendmail.cf file

Or, consider a web-based tutorial explaining how IDNA works:

  Ignore all of the munchkins behind the curtain, the basic principle
  is as follows:

    a domain name is encoded per punycode
    a prefix of zz-- is appended to the encoded output
    thus the domain name of  is encoded as zz--gobbledygook

which is converted BY DEFAULT into

    thus the domain name of  is encoded as 

Congratulations on producing a specification that cannot be used to
document itself. Everytime an example is given, the example is
transliterated. :/

> Maybe you think that description is too broad.  Suggest
> some alternative wording.  But we need to give some sort of
> encouragement for ToUnicode to be applied in some situations.

  1) Connection identifiers (as used for forward lookups by
     application clients, or as generated by reverse lookups)
     MAY be transliterated for display purposes, although
     careful consideration is to be given to any effects such a
     conversion may have on any secondary applications.  For
     example, if a utility or library is commonly used by
     multiple applications as part of a network service, a
     separate function call or command-line switch may be needed
     to generate internationalized domain names as output.

  2) Domain names which are provided as protocol data MUST NOT
     be transliterated, except where the governing
     specification  explicitly permits and describes such usage.

  3) Domain names which are provided as structured data (such
     as email addresses, URLs, and other common data-formats)
     MUST NOT be transliterated, except where the governing
     specification explicitly permits and describes such usage.

  4) Domain names which are provided as unstructured data in
     application output MUST NOT be transliterated, except where
     the governing  specification explicitly permits and
     describes such usage.

I think we all agree on 2 and 3. I don't think you have given 1 much
consideration, but think about things like tcpdump or netstat as examples
of where this needs to be treated gingerly. You seem to be suggesting that
an application should be able to intuit where 4 should or should not be
applied. As the two examples above illustrate, rule #4 is also needed if
there is to be any consistency in implementations.

> > CONVERSION MUST ONLY OCCUR WHERE A PROTOCOL OR DATA-FORMAT EXPLICITLY
> > DEFINES THE BEHAVIOR.
> 
> That would defeat the whole point of IDNA, which is to allow
> applications to use internationalized domain names with legacy
> protocols and interfaces, without having to revise those protocols
> and interfaces.

I'm sorry that you are operating under that belief. As I have pointed out
multiple times on the mailing list, IDNA serves a single objective of a
backwards-compatible encoding format. It does not bring i18n domain names
to legacy applications, protocols or data-formats by itself.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Mon Feb 11 16:49: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 QAA18499
	for ; Mon, 11 Feb 2002 16:49:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aO8g-000CDw-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:37:30 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aO8e-000CDo-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:37:28 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aO8d-0006NU-00
	for ; Mon, 11 Feb 2002 13:37:27 -0800
Date: Mon, 11 Feb 2002 21:37:27 +0000
From: "Adam M. Costello" 
To: "'IETF idn working group'" 
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Message-ID: <20020211213726.GB23357@nicemice.net>
Reply-To: IETF idn working group 
References: <20020209150309.GA900@nicemice.net> <000201c1b1b0$e27d0890$e0c11081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000201c1b1b0$e27d0890$e0c11081@chalmers95a69n>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

I wrote:

> IDNA says nothing about the separators between labels except that they
> are "usually" dots.  IDNA says nothing about how to split domain names
> into labels, or join labels into domain names.  It neither requires
> nor prohibits the acceptance of fullwidth full stop as a domain label
> separator.

Kent Karlsson  replied:

> Hmmm, this kind of contradicts your statements in your other e-mail.

I don't see how.  Maybe you're thinking of comments made by someone
else.

> I think something should be said about this, namely that the entier
> IDN is processed the same way before any kind of part splitting.  When
> everything else is so detailed about mappings etc., this should be the
> same.  Otherwise how does anyone know if FULLWIDTH STOP is allowed (as
> a part separator) in an IDN or not?

That is a sensible concern.  The difficulty is that there is no existing
standard for this, even for LDH host names, so we have no starting
point to internationalize.  DNS queries and responses don't use dots at
all, they use length bytes.  DNS master files use ASCII dots as label
separators, and require a trailing dot.  URIs also use dots as label
separators, but the trailing dot is optional.  In email message headers
the trailing dot is forbidden, and the other dots can be surrounded by
optional whitespace and parenthesized comments (no kidding!).

Thus, domain names are defined as a sequence of labels, but the
representation of that sequence is not standardized, so it would be
difficult for IDNA to say precisely how to internationalize this
non-standard.  Furthermore, given that applications often pick domain
names apart and put them together, it is safest if IDNA operates on
labels independently.

However, I suppose we might want to consider having the IDNA spec to say
something vague like:

    Applications that use U+002E (FULL STOP) to separate domain labels
    are encouraged to accept all the full-stop characters as label
    separators:

    U+002E FULL STOP
    U+0589 ARMENIAN FULL STOP
    U+06D4 ARABIC FULL STOP
    U+0701 SYRIAC SUPRALINEAR FULL STOP
    U+0702 SYRIAC SUBLINEAR FULL STOP
    U+1362 ETHIOPIC FULL STOP
    U+166E CANADIAN SYLLABICS FULL STOP
    U+1803 MONGOLIAN FULL STOP
    U+1809 MONGOLIAN MANCHU FULL STOP
    U+3002 IDEOGRAPHIC FULL STOP
    U+FE52 SMALL FULL STOP
    U+FF0E FULLWIDTH FULL STOP
    U+FF61 HALFWIDTH IDEOGRAPHIC FULL STOP

This calls into question the current nameprep prohibition of U+3002.
Why pick on just that one?  If we make a special case for U+3002, why
not do the same for all the other full-stop characters?  On the other
hand, nameprep does *not* prohibit U+002E (and it shouldn't--notice that
STD-13 includes an explicit demonstration of how to put ASCII dots in
domain labels).  U+002E is prohibited for host names in ToASCII, but
allowed for non-host domain names.  Maybe the same should be true of the
other full-stop characters.  Or maybe they should simply be allowed,
and registrants should just be advised that domain labels containing
full-stop characters will be difficult or impossible to use in many
situations.

AMC



From owner-idn@ops.ietf.org  Mon Feb 11 16:54: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 QAA18744
	for ; Mon, 11 Feb 2002 16:54:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aODj-000CSX-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:42:43 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aODg-000CSL-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:42:40 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aODf-0006QB-00
	for ; Mon, 11 Feb 2002 13:42:39 -0800
Date: Mon, 11 Feb 2002 21:42:39 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] last call reminder - Hebrew
Message-ID: <20020211214239.GC23357@nicemice.net>
Reply-To: IETF idn working group 
References: <004501c1ad20$07132b20$0d01000a@jamessonyvaio> <000001c1b24f$0f9b96e0$eb0110ac@qsm3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000001c1b24f$0f9b96e0$eb0110ac@qsm3>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Jonathan Rosenne  wrote:

> Hebrew vowel signs etc. (points) should be stripped (mapped out) by
> nameprep. Unicodes 05B0 to 05B9, 05BB to 05BD, 05BF, 05C1, 05C2, 05C4.
>
> Their presence or absence should not make two host names different.

This is a language-level equivalence issue, similar to
traditional/simplified Chinese or Danish aa/a-with-ring-above or English
color/colour.  Nameprep is not the place to deal with this.  Nameprep
produces canonical-form strings, not canonical-form words.

AMC



From owner-idn@ops.ietf.org  Mon Feb 11 16:55: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 QAA18795
	for ; Mon, 11 Feb 2002 16:55:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aOJQ-000CjJ-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:48:36 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aOJN-000Cj9-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:48:35 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aOJN-0006RY-00
	for ; Mon, 11 Feb 2002 13:48:33 -0800
Date: Mon, 11 Feb 2002 21:48:32 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] stringprep comment 5: hangul conjoining sequence
Message-ID: <20020211214832.GD23357@nicemice.net>
Reply-To: IETF idn working group 
References: <0c0601c1b316$dfc16350$2b19fea9@temp> <001201c1b322$0d156350$d5d61081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001201c1b322$0d156350$d5d61081@chalmers95a69n>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Kent Karlsson  wrote:

> Compatibility (non-conjoining) Hangul letters are best prohibited.

Stringprep does normalization before prohibition, so prohibiting
compatibility characters would have no effect.  After the normalization
step, there are no compatibility characters in the string.

A trick you could play, however, would be to map the characters in
question to an arbitrary prohibited character that survives the
normalization step (like U+0000).

AMC



From owner-idn@ops.ietf.org  Mon Feb 11 16:55: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 QAA18818
	for ; Mon, 11 Feb 2002 16:55:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aOKl-000Cls-00
	for idn-data@psg.com; Mon, 11 Feb 2002 13:49:59 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16aOKi-000Cll-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 13:49:57 -0800
Received: (qmail 2246 invoked by uid 1001); 11 Feb 2002 21:48:55 -0000
Date: 11 Feb 2002 21:48:55 -0000
Message-ID: <20020211214855.11426.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

``Nobody has given a coherent explanation of _why_ IDNA needs to do
certain mappings and not others,'' I wrote.

Patrik responded:
> Because we do comparison of Unicode strings.
> See http://www.unicode.org/unicode/faq/normalization.html
> I.e. not our choice (more than choosing to use Unicode).

Patrik is lying. The web page that he cites does _not_ require, or even
suggest, that uppercase and lowercase should be considered equivalent.
Unicode normalization is about things like e-with-a-separate-egu-accent
matching the combined e-egu character.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Mon Feb 11 17:10: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 RAA19270
	for ; Mon, 11 Feb 2002 17:10:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aOXh-000DOw-00
	for idn-data@psg.com; Mon, 11 Feb 2002 14:03:21 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aOXg-000DOk-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 14:03:20 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4vQqBuUeNHbE7wf8mekFOhA==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GTEAKWC3; Mon, 11 Feb 2002 17:02:54 EST
To: phoffman@imc.org
Cc: idn@ops.ietf.org
Date: Mon, 11 Feb 2002 14:13:01 -0800
Subject: Re: [idn] WG last call documents allowing parallel treatment to different scripts?
Message-ID: <20020211.141302.-81085.1.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-7,9-28
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

One more suggestion:

  Is it possible to add words in IDNA allowing 
parallel treatment to different scripts? Which would
be consistent with phased-in deployment of IDN?

Liana

On Mon, 11 Feb 2002 08:00:37 -0800 Paul Hoffman / IMC 
writes:
> At 4:16 AM +0000 2/11/02, Adam M. Costello wrote:
> >I think the intended title of this document is "Stringprep Profile
> >for Internationalized Domain Names".  The previous IDNA draft was
> >"Internationalizing Host Names in Applications", but the latest 
> IDNA
> >draft is "Internationalizing Domain Names in Applications".  I 
> think
> >when that change was made, the same change should have been to the 
> title
> >of the nameprep draft, but was not due to a simple oversight.  Can 
> the
> >nameprep authors confirm that?
> 
> Yep, that is correct. I worked so hard on getting it right in IDNA 
> that I forgot to be careful in nameprep. This will be fixed.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 



From owner-idn@ops.ietf.org  Mon Feb 11 17:21: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 RAA19447
	for ; Mon, 11 Feb 2002 17:21:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aOiL-000DrG-00
	for idn-data@psg.com; Mon, 11 Feb 2002 14:14:21 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aOiK-000Dqw-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 14:14:20 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55266 for idn@ops.ietf.org; Mon, 11 Feb 2002 16:13:43 -0600
Message-ID: <3C684239.738EE007@ehsco.com>
Date: Mon, 11 Feb 2002 16:14:17 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@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


[this is part 2 of a multi-part response]

"Adam M. Costello" wrote:

> "Eric A. Hall"  wrote:
> 
> >  | Stringprep Profile for Internationalized Host Names
> >
> > Since this profile is specifically for host names, all of the rules
> > that apply to hostnames should be placed here.
> 
> I think the intended title of this document is "Stringprep Profile
> for Internationalized Domain Names".

Based on a cursory analysis, this document is suitable as a standalone
description of i18n domain names, although I would reiterate my belief
that there is room to provide dot-separator character mapping on full
domain names (possibly belonging in a separate super-profile).

However, we still need a separate profile that describes the hostname
rules, in particular including a prohibition against certain leading and
trailing characters, as was discussed at length on the mailing list on
multiple occassions.

> Those apps still need the IDNA spec, because the IDNA spec defines
> what is a valid internationalized domain label.  Nameprep alone cannot
> possibly tell you whether the label is too long; you can know that only
> after applying Punycode.

This co-dependency needs to be called out at the top of the i18n domain
name profile.

> > "generic domain name slot" should be substituted with "STD13 slot".

> Regardless of what we call it, that is the concept that is needed in
> rule 1.  Perhaps you think the term "generic domain name slot" is
> counter-intuitive and should be renamed (but not redefined)?
> 
> I don't think the term "STD13 slot" is appropriate.  I would expect a
> term called "STD13 slot" to be defined in terms of STD13 only, but the
> concept we need here is defined in terms of the IDNA spec.

The use of "generic" is what bothers me, because it implies that the slot
(another word I dislike) can hold any domain name. I would call it STD13
because that is the governing specification (actually, "RFC1035 slot"
would be better since RFC1035 is likely to be supplanted from STD13 at
least a couple of times in our lifetimes).

> > Trying to pipe an STD13 binary domain name through ToUnicode may
> > result in some false-positives.

> You don't need to invoke "binary" domain names to illustrate this
> problem, since it is equally present for ASCII domain names. In either
> case, an accidental ACE label might get displayed (or even transported)
> in an untintended way, but no information will be lost, and the
> original form will be restored before any program attempts to
> interpret the name as intended.

The situation I am thinking about is where one of the NUL replacements
takes place. I admit that I haven't fully explored the possibility of
weaknesses in this area, but deleting input is always risky so I am
keeping it in my mind until I do get around to it.

> >  | B. Design philosophy
> >
> > What value does this section provide?
> 
> It documents the rationale behind the design decisions.  I think it's
> often helpful and/or instructive for people who later read the spec
> and wonder "Why did they do it that way?"

So you have an example of another WG specification where only half the
opinions are provided, and that they provide value towards understanding
the protocol or service? Citations Please

The fact of the matter is that this section is one side of a holy war,
argumentative, does not provide any scientific value, and certainly does
not represent WG consensus. It is also factually in error.

> Has the current prohibition of leading & trailing hyphens been terribly
> helpful?  I think it probably would have been better if the host
> label syntax were simpler--just a set of allowed characters, with no
> restrictions on position.  So I think we should keep any new positional
> restrictions to a minimum.
> 
> But there is one class of characters that might indeed be dreadful at
> the beginning: combining characters.  I recently refered to labels
> that begin with combining characters as invalid Unicode strings, but
> they're not, are they?  They just behave in surprising ways when
> abutted with something else.  Maybe nameprep should prohibit initial
> combining characters.

Note that these are rules for hostnames in particular.

A prohibition against combining characters is not feasible. See
<200111212258.OAA23757@birdie.sybase.com> from K Whistler.

This was resolved without disconsent in <3C0DD610.F50F947B@ehsco.com>:

 | First and last characters in the label MUST NOT be a diacritical
 | mark or hyphen-minus.

[Several other issues with stringprep were not yet addressed, and I still
consider them as unresolved and/or open.]

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Mon Feb 11 17:22: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 RAA19493
	for ; Mon, 11 Feb 2002 17:22:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aOhj-000Dne-00
	for idn-data@psg.com; Mon, 11 Feb 2002 14:13:43 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aOhh-000DnN-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 14:13:42 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aOhh-0006Wm-00
	for ; Mon, 11 Feb 2002 14:13:41 -0800
Date: Mon, 11 Feb 2002 22:13:41 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <20020211221340.GE23357@nicemice.net>
Reply-To: IETF idn working group 
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020211214855.11426.qmail@cr.yp.to>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"D. J. Bernstein"  wrote:

> ``Nobody has given a coherent explanation of _why_ IDNA needs to do
> certain mappings and not others,'' I wrote.
> 
> Patrik responded:
> > Because we do comparison of Unicode strings.
> > See http://www.unicode.org/unicode/faq/normalization.html
> > I.e. not our choice (more than choosing to use Unicode).
> 
> Patrik is lying.

Unlikely.  He probably just didn't understand your question exactly the
way you intended it.  Language isn't perfect, misunderstandings happen.

> The web page that he cites does _not_ require, or even suggest, that
> uppercase and lowercase should be considered equivalent.

Right.

The reason IDNA does case-folding is to be consistent with the existing
standard for domain names, which says they are case-insensitive.  Not
everyone considers that a sufficient reason, and we've been through
all the arguments on both sides, but that is the reason.  There are
many ways IDNA could have been designed differently and still work, and
this is one of them, but at the end of the day we need to use our best
collective judgement and make a choice.  There does not exist a solution
that everyone would agree is the best possible in all respects.

AMC



From owner-idn@ops.ietf.org  Mon Feb 11 18:49: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 SAA20460
	for ; Mon, 11 Feb 2002 18:49:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aPyw-000H3l-00
	for idn-data@psg.com; Mon, 11 Feb 2002 15:35:34 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aPyv-000H3f-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 15:35:33 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4iddsnD//+LprPbPIPga9Bw==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GTEFUJH6; Mon, 11 Feb 2002 18:35:00 EST
To: klensin@jck.com
Cc: liana.ydisg@juno.com, deng@cnnic.net.cn, jseng@pobox.org.sg,
        idn@ops.ietf.org
Date: Mon, 11 Feb 2002 15:44:46 -0800
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <20020211.154447.-81085.2.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-1,3-260
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



On Mon, 11 Feb 2002 14:44:41 -0500 John C Klensin 
writes:
> --On Monday, 11 February, 2002 09:34 -0800 liana Ye
>  wrote:
> 
> > Dear John:
> > 
> > I appreciate your understanding of all the problems the IDN 
> > does not solve. The differences between the WG and the 
> > CDN group is not a political issue at its base.
> 
> I think I understand that, as do, I think, most of the
> participants in the WG.  If I correctly understand what they are
> saying when they make comments about political issues, those
> comments are based on three things:
> 
> (i) Whomever and whatever initiated the process, much of the
> IETF reacts very badly to attempts to influence a working group
> (or other effort) by letter-writing campaigns that involve a
> large number of people sending the same note or notes,
> especially when those people have not be participating in the
> WG.  Such note-sending campaigns are a political action, not an
> engineering one.  They are also considered in such bad taste
> that they may damage the position they are trying to advocate:
> the reaction is, more or less, "they have completely run out of
> technical arguments and  are falling back to creating a lot of
> noise; this action indicates that even they do not believe in
> their technical arguments".

If you recall that the Chinese group tends to take "forget about 
them, it is wasting our time and effort to convence them" attitude? 
They would go back to do their own things, like the case 
in the early MSDOS source code licensing in the early 80's. 
I hope this WG does not make a similar mistake commtted by
MircoSoft then.  

I think it is a progress that CDN group care about what is 
being argued in the IETF now, and trying hard to make the 
IETF to understand their position.  They may not have a fully 
satisfactory solution for IDN, but they know the current 
proposal will not work for Han characters, which is 75%
of UCS code points. 

> (ii) We have a continuing communications disconnect in which
> some members of the Chinese-speaking community are, apparently,
> so astonished that their positions are not immediately accepted
> by the WG that they assume that no one [else] in the WG cares
> about the impact of this work on names written in Chinese
> characters.  Again, that leads to statements being made that
> sound to others as if reasoning has been abandoned in favor of
> political actions.

You have misread the protest.  Please recall what Martin Luther 
King. Jr holiday is about.  I  think everyone at that time 
understood what the Blacks are asking for equal rights in taken 
a bus, but not everyone thought it is an issue to put that into law!

 
> (iii) There is also a perception that the CDNC group, and some
> others, are ignoring or dismissing the problems with Japanese
> and Korean that would be induced by special mappings for Chinese
> and, similarly, that many careful explanations of why
> specialized TC<->SC handling is not analogous to case-mapping in
> alphabetic character sets.  Again, this is a failure to
> communicate (perhaps on both sides) at a very fundamental level
> that is leading to ill-feeling and beliefs that decision are
> being made on a political or emotional basis, rather than with
> full understanding and acceptance of the engineering constraints
> and tradeoffs.
 
They are not ignoring Japanese and Korean!  They are not 
Japanese or Korean, so they don't think they are qualified
to argue on behave of them.   They know there are plenty 
problems in Chinese already, which they have dealt with
without the help of IETF in the past.  They know the theortical 
limit of digital computational technology, and realy concern
about extenting the current limit to include Japanese and 
Korean users. 


> > WG is trying 
> > to push TC/SC out of IDN.  The CDN and the others argue
> > for them to be dealt with in IDN. 
> 
> Again, let me try to explain this a little bit differently.
> There is a very strong conviction in the IETF that one of the
> issues, perhaps the key issue, in Internet protocol design is
> scaling.  The scaling concerns are usually though of as applying
> to "size of the Internet" issues -- e.g., we try to avoid
> standardizing anything that can work only in a restricted
> environment or under other "small network" constraints.  But
> they also apply to partial solutions: if a particular aspect of
> a problem or design activity seems to require a comprehensive
> solution, but none is immediately available, the IETF will tend
> to avoid a partial solution until the comprehensive one and a
> migration strategy are well understood.
> 

The scaling you are thinking of is to put all UCS codepoints 
in a sequencial filter, and let Latin code block coming out 
at the end of the sequencial filter.  Which is what the CDN 
has to process with TC/SC conversion, and the 1-1 TC/SC
mapping should come out of this filter at the end too!  


> The other difficulty with the "consumer confusion" aspects of
> the CDN discussion is that many of the comments seem to ignore a
> point that has been made repeatedly in the WG: these issues
> exist, in some form, for almost every language and script we
> have investigated. All of the "equivalent character"
> discussions, the similarity of some characters among, e.g.,
> "Latin", Cyrillic, and Greek scripts, and related issues point
> to considerable possibility of user confusion, misrouted
> queries, and so on.  One might even suggest that the CDNC
> complaints have been inappropriately focused on Chinese
> characters and that the statement should have been "this will
> cause problems all over the world, and the IDN effort should
> just stop".  The people in the WG who have put in huge amounts
> of effort trying to get _something_ to work probably would not
> accept that either, but the position would more nearly recognize
> the realities of likely IDN usage.
 
So every script or script group has to have some types of
sequencial filtering, and should come out of the [nameprep]
at the end which is not confused with other code blocks.


> And that brings me to what I think it is the real problem here,
> and it a problem that many of us, including those taking the
> lead on IDNA (and nameprep, etc) have understood for most of the
> time that the WG has been working on these problems.  There are
> many problems with the use of words in languages that cannot be
> dealt with in the DNS and some other solution will be needed.
> Full TC<->SC matching (of all combinations) appears to fall into
> that category.  So does the Greek-Cyrillic-Latin problem, and
> the ASCII 0<->O and 1<->l problems.  So does a really
> satisfactory solution to the "invisible character" problem, some
> issues with Arabic/Hebrew/Yiddish vowels, and so on.  Mark's
> notion of using presentation mechanisms to identify unusual
> character combinations is, I think, quite ingenious but it isn't
> part of the DNS either.  Your notions about phonetic mappings
> fall into this category as well.  But the two things that all of
> these problems and approaches have in common is the potential
> for user confusion (or fraud) --some of it serious-- and the
> fact that none of them can be dealt with by the simplistic
> matching rules of the DNS.  Instead, we need user choices, or
> likelihood functions, or fairly serious language recognition, or
> knowledge the DNS doesn't have, or heuristics of some [other]
> variety.  And the problems aren't limited to Chinese, even
> though they manifest themselves differently.
>

This is precise the reason, that I have proposed to use 
langue tags, and keep these tags transperent in DNS.
 
> Now I suggest that almost everyone who has been participating
> actively in this effort knows that by now.  We know that other,
> non-DNS, mechanisms are going to be needed to accomplish
> satisfactory internationalization.  Given that, the hard problem
> is whether it makes sense to tamper with the DNS at all.  And,
> if one is going to do that, what the right set of constraints is
> to prevent some of the worst possible damage.   My reading of
> the consensus in the WG is that they believe that eliminating
> (or postponing) every script that raises problems is not a
> solution: we would rapidly have to eliminate all scripts,
> possibly including the LDH subset of ASCII.

That is what I mean by the Latin code block is the only one 
comes out of the filter at the end.  I think you are more fair at 
recognizing the current discussion direction.

> 
> I think the WG believes that there are three options, and that
> most of its members has eliminated the third from consideration:
> 
> 	(a) Use Nameprep, or something very much like it, which
> 	deals with mappings that are complete (i.e., there is no
> 	controversy about them and no need for examination of
> 	surrounding characters, other context, or language
> 	information to do them properly) and which excludes
> 	characters that are problematic in any context in which
> 	they appear.

I think Nameprep can be extented for a parallel processing 
fashion.  Thus Latin is done, and leave other code blocks open
to be handled by their seperated preprocessing routines.

> 	(b) Adopt a very strict "identifier" rule in which
> 	nameprep becomes unnecessary: characters from the
> 	permitted repertoire can be intermixed in any way,
> 	without restrictions, comparisons are made on those
> 	characters only, and the users will somehow learn to
> 	cope with the results.

This has to be used to sequencialize each script group. Thus,
it appears to users that it is a complete, 100% solution at Layer
3, but in IDN they are very strict "identifiers".

> 	
> 	(c) Give it up, keep text labels in the DNS restricted
> 	to the LDH rules, and do _all_ internationalization
> 	"somewhere else".

Yes, this is what I am arguing for. 


> > If you consider IDN is a part of DNS, then the CDN group 
> > say "NO, NO, NO" with force for you and the WG to raise 
> > eyeballs.   And I hope they have accomplished it with 
> > all their protests.
> 
> I fear not.  Many of us were fully aware of the problems, and
> very concerned about them, before now, and even before Salt Lake
> City.    For some of us, the protests have been successful only
> in taking up time that should have gone into the "above DNS"
> work.  For others, they have distracted from the effort to
> carefully review and adjust the details of what nameprep should
> be doing in areas where it can constitute a nearly-100%
> solution. And, as I have suggested above and elsewhere, they
> have led many people to the conclusion (whether correct or
> incorrect) that the real goal of the CDNC protest was to disrupt
> the work of the WG without offering real alternatives or a way
> forward.
> 
> > If you consider IDN is above DNS then you are agreeing 
> > with CDN group. 
> 
> As I trust you know, I have been suggesting that much critical
> IDN work will have to be done "above DNS" since before either
> the WG or MINC got started.  But to agree on that principle does
> not necessarily imply agreement on details of what the WG should
> do.
> 
> > If you admit that you are not an expert in dealing with 
> > Han charaters processing then you should give a good 
> > and hard study regarding what they have been saying 
> > all along.
> > 
> > If you are understand what Xiang Deng is saying then 
> > don't introduce political arguements.  It doesn't help the 
> > communication at all. 
> 
> I didn't raise any political arguments in the note of mine that
> you quoted, nor did I use that word.  "Policy" issues and
> decisions are another matter entirely.   And, while I assume
> neither you nor Xiang Deng did so either, I didn't set off the
> letter-writing campaign.
> 
> regards,
>     john

I think the last part of our conversation shows the difference
resulted from previous technical issues.  I shall be silent 
to futher them.

Regards,

Liana
  



From owner-idn@ops.ietf.org  Mon Feb 11 19:50: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 TAA21158
	for ; Mon, 11 Feb 2002 19:50:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aR21-000JjN-00
	for idn-data@psg.com; Mon, 11 Feb 2002 16:42:49 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aR20-000JjH-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 16:42:48 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55305 for idn@ops.ietf.org; Mon, 11 Feb 2002 18:42:11 -0600
Message-ID: <3C686505.9A49BF56@ehsco.com>
Date: Mon, 11 Feb 2002 18:42:45 -0600
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: Inputting mixed SC/TC (Re: [idn] A question...)
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to> <20020211221340.GE23357@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:

> The reason IDNA does case-folding is to be consistent with the
> existing standard for domain names, which says they are
> case-insensitive.

More specifically, the encoded representation of an uppercase i18n domain
name is different than the encoded representation of a lowercase i18n
domain name, so the only way that case-neutral matching of the encoding
sequence can work is if the i18n domain name is case-neutered before it is
encoded.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Mon Feb 11 21:15: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 VAA22020
	for ; Mon, 11 Feb 2002 21:15:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aSFY-000MqT-00
	for idn-data@psg.com; Mon, 11 Feb 2002 18:00:52 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aSFX-000MqN-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 18:00:51 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aSFW-00077X-00
	for ; Mon, 11 Feb 2002 18:00:50 -0800
Date: Tue, 12 Feb 2002 02:00:50 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020212020050.GA26818@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C684239.738EE007@ehsco.com> <3C6836CE.8A77B0CE@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> [this is part 1 of a multi-part response]
> [this is part 2 of a multi-part response]

Do I have the last part yet?  I don't know, I'll just respond now...

> > We recommend, we don't demand.
> 
> SHOULD defines *default* behavior, it is mandatory UNLESS there is a
> reason NOT to do it.

Yes, I understand.  We don't demand that implementors apply ToUnicode,
we recommend it.  Or seen another way, we demand that they either apply
ToUnicode or think of a good reason not to.

I can see your point that maybe even that is a little too strong.

> Consider the following DEFAULT mandatory interpretation:
> 
>   From: 
>   To: 
> 
>   Please add zz--gobbledygook to your sendmail.cf file
> 
> which is converted BY DEFAULT into
> 
>   Please add  to your sendmail.cf file

It was never our intention that applications should go digging into text
directed at humans (as opposed to protocol messages, which are directed
at the application itself) and convert things that they guess might be
domain names.

This is probably not clear from the current wording.

>   1) Connection identifiers (as used for forward lookups by
>      application clients, or as generated by reverse lookups)
>      MAY be transliterated for display purposes, although
>      careful consideration is to be given to any effects such a
>      conversion may have on any secondary applications.
> 
>   2) Domain names which are provided as protocol data MUST NOT
>      be transliterated, except where the governing
>      specification  explicitly permits and describes such usage.
> 
>   3) Domain names which are provided as structured data (such
>      as email addresses, URLs, and other common data-formats)
>      MUST NOT be transliterated, except where the governing
>      specification explicitly permits and describes such usage.
> 
>   4) Domain names which are provided as unstructured data in
>      application output MUST NOT be transliterated, except where
>      the governing  specification explicitly permits and
>      describes such usage.
>
> I think we all agree on 2 and 3.

Assuming "transliterated" means "converted from ACE to Unicode" (as
opposed to the other way around), then yes I agree on points 2 and 3,
and in fact the IDNA spec already implies points 2 and 3 in requirement
1 of section 3 (domain labels inserted into generic domain name slots
must contain only ASCII).

Point 4 could be taken care of by limiting requirement 2 to ACE labels
obtained from domain name slots (as opposed to ACE labels guessed at in
plain text).  Point 1 could be taken care of by explicitly allowing for
exceptions.

What do you think of this wording:

    2) 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.  Given an
    internationalized domain name, an equivalent domain name containing
    no ACE labels can be obtained by applying the ToUnicode operation
    (see section 4) to each label.  When requirements 1 and 2 both
    apply, requirement 1 takes precedence.

I could live with that.  I don't know about Patrik and Paul.

> > That would defeat the whole point of IDNA, which is to allow
> > applications to use internationalized domain names with legacy
> > protocols and interfaces, without having to revise those protocols
> > and interfaces.
>
> I'm sorry that you are operating under that belief.  As I have pointed
> out multiple times on the mailing list, IDNA serves a single objective
> of a backwards-compatible encoding format.  It does not bring i18n
> domain names to legacy applications, protocols or data-formats by
> itself.

It does not bring i18n to legacy applications, but it *does* bring i18n
to legacy protocols and data formats.  One of the main examples driving
the design of IDNA was this one:  We should be able to update mail
user agents (like Pine) and immediately be able to use IDNs in email
addresses without having to touch mail transfer agents (like sendmail)
or DNS servers (like bind), and without having to wait for any updates
to protocol specifications (like the DNS spec and the SMTP spec) or data
format specifications (like RFC 2822).

> > ...the IDNA spec defines what is a valid internationalized domain
> > label.  Nameprep alone cannot possibly tell you whether the label is
> > too long; you can know that only after applying Punycode.
>
> This co-dependency needs to be called out at the top of the i18n
> domain name profile.

The last sentence of the nameprep abstract is:

    This profile of the stringprep protocol is used as part of a suite
    of on-the-wire protocols for internationalizing the DNS.

I agree that there should be a citation to IDNA at the end of the
abstract.  Nameprep is useless without IDNA.  I'd also like to see "the
DNS" changed to "domain names", since we're not actually doing anything
to the DNS.

> > Perhaps you think the term "generic domain name slot" is
> > counter-intuitive and should be renamed (but not redefined)?
>
> The use of "generic" is what bothers me, because it implies that the
> slot (another word I dislike) can hold any domain name.

Some domain name slots are explicitly internationalized and are thus
special; all other domain name slots, being non-special, are "generic".
That's the way I intended the word to be understood.  Other words that
could serve the same purpose are "vanilla" and "ordinary".  Would either
of those be better?  Or maybe "non-internationalized".

"RFC-1035 slot" is not inclusive enough.  If a protocol/interface
spec says that a field/argument is a domain name, and says nothing
else (makes no mention of RFC 1035 or any other standard for domain
names), then that is a generic domain name slot.  Or if it cites various
standards that govern the slot, but IDNA is not one of them, then it's a
generic domain name slot.

As for the word "slot", would you like to suggest some other word?  Here
is the concept that the term "domain name thingamabob" needs to stand
for: "a protocol element or a function argument or a return value (and
so on) explicitly designated for carrying a domain name."

> So you have an example of another WG specification where only half
> the opinions are provided, and that they provide value towards
> understanding the protocol or service? Citations Please

Not an IETF spec, but the PNG spec includes a rationale appendix, and
we've received comments saying that it was helpful and it would be nice
if other specs did the same.  I don't think we ever received comments
saying it should not have been included.

> It is also factually in error.

If that's true, it should be fixed.

> A prohibition against combining characters is not feasible. See
> <200111212258.OAA23757@birdie.sybase.com> from K Whistler.

He said that we could not simply prohibit combining characters, and
I agree.  I was suggesting that we might want to prohibit *initial*
combining characters.  Combining characters combine with the character
preceeding them, so a label beginning with a combining character is a
strange beast, and might cause bizarre and suprising behavior.

AMC



From owner-idn@ops.ietf.org  Mon Feb 11 21:30: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 VAA22132
	for ; Mon, 11 Feb 2002 21:30:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aSYx-000Nfl-00
	for idn-data@psg.com; Mon, 11 Feb 2002 18:20:55 -0800
Received: from smtp24.singnet.com.sg ([165.21.101.204])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aSYv-000Nff-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 18:20:54 -0800
Received: from jamessonyvaio (tns00802.singnet.com.sg [165.21.185.192])
	by smtp24.singnet.com.sg (8.12.2/8.12.2) with SMTP id g1C2KodO031881
	for ; Tue, 12 Feb 2002 10:20:51 +0800
Message-ID: <085501c1b36b$f6e32b40$cfc615a5@jamessonyvaio>
From: "James Seng/Personal" 
To: 
Subject: [idn] protest mails update
Date: Tue, 12 Feb 2002 10:21:21 +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 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: 7bit

There is a total of 355 protest mails (including dups) as of today.

I am unable to provide the summary as promise with the conectivity I
have right now. Please give me a few days.

-James Seng




From owner-idn@ops.ietf.org  Mon Feb 11 21:45: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 VAA23254
	for ; Mon, 11 Feb 2002 21:45:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aSr1-000OSr-00
	for idn-data@psg.com; Mon, 11 Feb 2002 18:39:35 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aSr0-000OSl-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 18:39:34 -0800
Received: from iis.sinica.edu.tw (i2ot1 [140.109.21.153])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g1C2YUT19679;
	Tue, 12 Feb 2002 10:34:33 +0800 (CST)
Message-ID: <3C6880DB.7549F426@iis.sinica.edu.tw>
Date: Tue, 12 Feb 2002 10:41:31 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: James Seng/Personal 
CC: idn@ops.ietf.org
Subject: Re: [idn] Interesting links
References: <000501c1b0b1$1d69d6a0$dd00a8c0@jamessonyvaio>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Most of the articles are based on arguments already presented on
the mailing list. What happen in the WG will bring damage the
community. Thus these IDN work is more than just engineering
work. Thus some documents must be prepared for general
Chinese-speaking public to access. As an intellectual figure of
the community, this is our responsibility.

I'll be happy to translate the web pages into English if necessary.

-- Janming Ho

James Seng/Personal gJG

> Wondering where all the protest mails come from (there is 120 of them
> right now in my mail box)? See these links.
>
> http://isoc.iis.sinica.edu.tw/
> http://www.iis.sinica.edu.tw/~hoho/idn/
> http://140.109.18.202/RescueCDN/
>
> Unfortunately, it is in Chinese but most will be able to understand the
> last link at least. Sorry, I am not in a position to do this
> translation.
>
> -James Seng




From owner-idn@ops.ietf.org  Mon Feb 11 21:56: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 VAA23336
	for ; Mon, 11 Feb 2002 21:56:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aT2p-000P10-00
	for idn-data@psg.com; Mon, 11 Feb 2002 18:51:47 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16aT2n-000P0u-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 18:51:46 -0800
Received: (qmail 11596 invoked by uid 1001); 12 Feb 2002 02:50:05 -0000
Date: 12 Feb 2002 02:50:05 -0000
Message-ID: <20020212025005.26938.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to> <20020211221340.GE23357@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Adam M. Costello writes:
> The reason IDNA does case-folding is to be consistent with the existing
> standard for domain names, which says they are case-insensitive.

What the existing standard actually says is ``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.''

Similarly, the Internet mail standards specifically require that bytes
in message headers---including domain names---be interpreted as ASCII
characters.

Complete consistency with the existing standards would mean continuing
to use only bytes 0-127, continuing to interpret those bytes as ASCII,
and continuing to compare names as case-insensitive ASCII names.

But we don't _want_ to follow those rules. We want to see glyphs that
simply aren't available in the ASCII character set.

Of course, we have to maintain INTEROPERABILITY with all strings used
today, so we'll have to continue accepting A-Z and a-z as equivalent.
But there are many possible equivalence rules for non-ASCII strings.
Here are several examples---certainly not a complete list:

   (1) Exactly what software uses now: no equivalences outside ASCII.

   (2) Equivalence of characters that have duplicate glyphs but that
       were kept separate by Unicode for one of the reasons described in
       http://www.unicode.org/unicode/standard/where.

   (3) American-biased equivalences according to Mark Davis's UTR 21,
       which is _not_ part of the Unicode standard.

   (4) German equivalences: for example, o-umlaut equivalent to oe, and
       the German ss equivalent to the two-byte Latin sequence SS, which
       in turn is equivalent to the two-byte Latin sequence ss.

   (5) Hebrew equivalences: for example, aleph-bar equivalent to aleph.

   (6) Various Chinese equivalences for the benefit of Chinese users.

   (7) Some combination of the above.

All of these are INTEROPERABLE with the existing use of ASCII. None of
them are CONSISTENT with the existing standards. One of them, #1, has
the advantage of being by far the easiest to implement---but provides
the most opportunities for confusion and fraud.

What exactly is the rational line between, for example, #3 and #4? For
ASCII characters they both boil down to A-Z matching a-z. Why is #3 a
better extension of the current situation than #4, or #3+#4?

James Seng states that #6 is pointless because ``domain names are
identifier ... should enter into the computer exactly as they seen it or
reference it.'' Under exactly the same principle, #3 and #4 and #5 are
all pointless, so IDNA has no excuse for the costs of #3.

Another approach, allowing the software simplicity of #1 but eliminating
user confusion, is to allow _selected_ non-ASCII characters. We don't
have to map all characters to the selected set; we simply have to make
sure that the selected characters won't be confused by the users. This
neatly dodges the difficulty of defining a broad equivalence rule.

The decisions here have to be based on rational assessments of costs and
benefits. Costello's notion of ``consistency'' is obviously not helpful:
it leads to such huge costs for Chinese users that it has already drawn
objections from _three hundred_ people.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Mon Feb 11 23: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 XAA25029
	for ; Mon, 11 Feb 2002 23:09:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aU7e-0001pC-00
	for idn-data@psg.com; Mon, 11 Feb 2002 20:00:50 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aU7c-0001p6-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 20:00:49 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55389 for idn@ops.ietf.org; Mon, 11 Feb 2002 22:00:11 -0600
Message-ID: <3C68936E.602B7B7@ehsco.com>
Date: Mon, 11 Feb 2002 22:00:46 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@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:

> What do you think of this wording:
> 
>   2) 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.  Given an
>   internationalized domain name, an equivalent domain name containing
>   no ACE labels can be obtained by applying the ToUnicode operation
>   (see section 4) to each label.  When requirements 1 and 2 both
>   apply, requirement 1 takes precedence.

Was there a problem with the explicit text I provided? The text presented
here still encourages a default behavior of transliterating anything that
looks like a domain name, when it should be the opposite.

We seem to have a disconnect here. You're concerned with the symptoms, I'm
talking about the root cause. Every protocol and data-format has its own
specific considerations, and it is not possible to mandate (or strongly
suggest, if you prefer) that every Internet service change its behavior to
suit IDNA. It's absurd. The only thing you can do here is say "don't do
anything until the masters of the spec say how to do it".

Again, consider WHOIS output. Should a WHOIS server transliterate output?
Should it be performed at the client so that negotiation is not required?
And you have described the protocol negotiation or client behavior where?

Or consider HTML, which has a limited notion of PDU structures. Should
domain names enclosed in HREF tags be transliterated? or should IDNA never
be transliterated, and if a user wants an i18n domain name to be displayed
then they should use the charset capabilities for this? And you have
documented this behavior for the W3C developer community where?

Even if you want to limit this behavior to a very specific community,
something small and syntactically precise such as email header fields,
which header fields should do this? Should this be limited to the
originator and recipient header fields only? And you have documented this
extension to RFC 2822 where? I mean, even RFC 2047 is restricted to
specific data-types.

You only have one choice here: nobody transliterates nothing until the
governing specifications for the network service in question clearly
describe how it should be done.

The exception is local presentation of connection identifers. There is no
reason that ping shouldn't be able to handle IDN<->IDNA conversion,
although even that has to be handled with care. Look, I can't even tell
one of my newsreaders to use an i18n domain name since the .newsrc files
are shared by multiple clients.

> the design of IDNA was this one:  We should be able to update mail
> user agents (like Pine) and immediately be able to use IDNs in email
> addresses without having to touch mail transfer agents (like sendmail)
> or DNS servers (like bind), and without having to wait for any updates
> to protocol specifications (like the DNS spec and the SMTP spec) or
> data format specifications (like RFC 2822).

Not possible. See above.

> > The use of "generic" is what bothers me, because it implies that the
> > slot (another word I dislike) can hold any domain name.

> Other words that could serve the same purpose are "vanilla" and
> "ordinary".  Would either of those be better?  Or maybe
> "non-internationalized".

"LDH slot"?

> > So you have an example of another WG specification where only half
> > the opinions are provided, and that they provide value towards
> > understanding the protocol or service? Citations Please
> 
> Not an IETF spec, but the PNG spec includes a rationale appendix, and
> we've received comments saying that it was helpful and it would be nice
> if other specs did the same.  I don't think we ever received comments
> saying it should not have been included.

If it wasn't lop-sided opinion (aka religion), you probably wouldn't have
gotten the two complaints you got here either.

> > It is also factually in error.
> 
> If that's true, it should be fixed.

 | Many proposals for IDN protocols have required that DNS servers be
 | updated to handle internationalized domain names.

Do you honestly seriously believe that IDNA will not require upgraded
servers to handle transliteration on input? That it *CAN* work without an
upgrade does not mean that it *WILL* work without an upgrade. Which of
those words is a property of "required"? Both.

 | Because of this, a person who wanted to use an internationalized
 | domain name would have to be sure that their request went to a DNS
 | server that had been updated for IDN.

The two dual-mode proposals before this WG have both allowed legacy
servers to provide answers. False.

Etc. The logic-path is entirely corrupt and based on nothing more than an
opinion that an encoding which appears nowhere else in the known universe
is somehow better than embracing the pain of an incremental upgrade.

> > A prohibition against combining characters is not feasible. See
> > <200111212258.OAA23757@birdie.sybase.com> from K Whistler.
> 
> He said that we could not simply prohibit combining characters, and
> I agree.  I was suggesting that we might want to prohibit *initial*
> combining characters.  Combining characters combine with the character
> preceeding them, so a label beginning with a combining character is a
> strange beast, and might cause bizarre and suprising behavior.

When rendered, it will combine with the dot separator. However, that's
only half the complaint. Also consider that leading punctuation is often
used as a command-line qualifer (-verbose). The prohibition needs to be
against all punctuation. When I looked (very briefly, that was composed at
a hotel room), the characteristic that seemed most useful was a property
of diacritical mark or dashes. I don't think there is a property of
punctuation. I should look.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Mon Feb 11 23:22: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 XAA25139
	for ; Mon, 11 Feb 2002 23:22:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aUI5-0002Hp-00
	for idn-data@psg.com; Mon, 11 Feb 2002 20:11:37 -0800
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aUI4-0002Hg-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 20:11:37 -0800
Received: from zetnet.co.uk (bts-1012.dialup.zetnet.co.uk [194.247.51.244])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g1C4BXI14918
        for ; Tue, 12 Feb 2002 04:11:33 GMT
Message-ID: <3C674474.7AF370A8@zetnet.co.uk>
Date: Mon, 11 Feb 2002 04:11:32 +0000
From: David Hopwood 
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: Re: [idn] last call reminder - Hebrew (and Arabic)
References: <000001c1b24f$0f9b96e0$eb0110ac@qsm3>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

Jonathan Rosenne wrote:
> The proposals are inadequate for Hebrew domain names as follows:
> 
> Hebrew vowel signs etc. (points) should be stripped (mapped out) by
> nameprep. Unicodes 05B0 to 05B9, 05BB to 05BD, 05BF, 05C1, 05C2, 05C4.
> 
> Explanation: These marks in Hebrew are optional, one may or may not use
> them, for example to clarify a possible ambiguity. They should be
> allowed but they should be ignored. Their presence or absence should not
> make two host names different.

The following paper:

  Steven Atkin, Ryan Stansifer, Mohsen Alsharif,
  Bidirectional Domain Names,
  19th International Unicode Conference.

takes the position that the Arabic and Hebrew points should be
disallowed. I'm not familiar with Arabic or Hebrew, but from a
technical point of view there is nothing to exclude either solution,
and no additional difficulties from mapping them out. The question
is simply whether we want to allow them in encoded domain names, for
example URI links in HTML, email, etc.

I can't find the above paper on the web any more, so it is temporarily
at .
Here is the relevant section (I'm not necessarily agreeing with it;
just quoting it for discussion):

# There are a number of Arabic characters that can be safely
# excluded from domain names. Specifically, these include the
# Arabic presentation forms, U+FB50-U+FDFF and U+FE70-U+FEFC.
# It is safe to exclude these characters, as they only represent
# ligatures and glyph variants of the base nominal Arabic
# characters. Additionally, the Arabic points U+064B-U+0652,
# U+0653-U+0655, and U+0670 should also be excluded. In
# most cases the Arabic points are only used as pronunciation
# guides. If the points were to be included, then names that
# differed only in their use of points would be treated as if
# they were distinct and different names. This is like the
# English homograph "bow" (the arrow) and "bow" (the ship) which
# are ambiguous. Removing the Arabic points eliminates such
# problems, with the understanding that not every Arabic word
# would be able to be represented. The Koranic annotation signs
# U+06D6-U+06ED can also be eliminated from domain names, as
# they are not used to distinguish one name from another.
# In Hebrew the cantillation marks U+0591-U+05AF and Hebrew
# points UFB0-U5C4 can be excluded as they are predominately
# used as pronunciation guides and for indicating the underlying
# structure of text. Additionally, the Arabic and Hebrew
# punctuation characters are also excluded from domain names as
# they are currently not permitted. The list of acceptable
# Arabic and Hebrew characters are listed in Table2.
#
# Table 2: Acceptable Arabic and Hebrew characters
#
# Unicode Range         Script   Notes
# U+05D0-U+05F4         Hebrew   ISO8859-8
# U+0621-U+064A         Arabic   ISO8859-6
# U+0660-U+0669         Arabic   Arabic-Indic digits
# U+0671-U+06D3,U+06D5  Arabic   Extended Arabic letters
# U+06F0-U+06FE         Arabic   Persian, Urdu, and Sindhi


> Note: This implies that FB2A to FB4E and FB1D should be mapped to their
> base letters in nameprep.

With nameprep as it is now, yes. However, if NFC-normalisation was done
before mapping (there are other good reasons to do that), then it wouldn't
be necessary, because these characters are canonically equivalent to the
base character followed by the point character. Since they also have a
composition exclusion, they will never occur in NFC (or NFKC).

- -- 
David Hopwood 

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPGdENTkCAxeYt5gVAQH8dwgAsuXM8mNz/pa5Wb93CKbzLW0ezYXaAiwI
DgP3TpZdFlArNvV2LS7ITkZ9/TMBluP8HikgLR4mmvpuoptzt142OksAIDh9K7n5
v+VwxdwqXGXS3Xoxl/4M9kUJC9qXeN/BwGla8J7rL+tIsuthyTuaRHnEQI2h92iX
pgCf3I7YCsePr9jY5lE5rVCaQjOhGWP5sRasaMKiFWagfEv+X0kxhQVuGFmv6YTZ
D5qmFqPDIXqdFZEOXmF/EI4GJM5f1qVDm76YFw2ivhuIN6BNnjUTG6z6DZ9UxKny
VQnc/zKXxBaWXR7REWScIeHklGL64q65YlLWoLBaprb8Fl3PCcb8+g==
=CRxe
-----END PGP SIGNATURE-----



From owner-idn@ops.ietf.org  Mon Feb 11 23:45: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 XAA25756
	for ; Mon, 11 Feb 2002 23:45:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aUkk-0003WZ-00
	for idn-data@psg.com; Mon, 11 Feb 2002 20:41:14 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aUkj-0003WN-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 20:41:14 -0800
Received: from [] (modemcable094.128-130-66.que.mc.videotron.ca [66.130.128.94])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1C50aa53333
	for ; Tue, 12 Feb 2002 00:00:36 -0500 (EST)
Date: Mon, 11 Feb 2002 23:40:48 -0500
From: Marc Blanchet 
To: idn@ops.ietf.org
Subject: [idn] few comments on nameprep
Message-ID: <110370000.1013488848@localhost>
X-Mailer: Mulberry/2.2.0b2 (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 XAA25756

Few comments on nameprep

- 1. Introduction
 + I think we should add a sentence at the end of the section that 
"stringprep is mandatory to implement": i.e. read it carefully,
  specially the discussion on versioning.



------------------------------------------
Marc Blanchet
Viagnie
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  Mon Feb 11 23:47: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 XAA25785
	for ; Mon, 11 Feb 2002 23:47:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aUkK-0003Vl-00
	for idn-data@psg.com; Mon, 11 Feb 2002 20:40:48 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aUkJ-0003VF-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 20:40:47 -0800
Received: from [] (modemcable094.128-130-66.que.mc.videotron.ca [66.130.128.94])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1C509a53327
	for ; Tue, 12 Feb 2002 00:00:09 -0500 (EST)
Date: Mon, 11 Feb 2002 23:40:20 -0500
From: Marc Blanchet 
To: idn@ops.ietf.org
Subject: [idn] Few comments on idna
Message-ID: <109960000.1013488820@localhost>
X-Mailer: Mulberry/2.2.0b2 (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 XAA25785

Hi,
 here is few comments on idna.

Marc.

- p2. "To allow such a label to be handled by existing applications, an 
"ACE label" is defined ..."
 + ACE should be spelled: ASCII Compatible Encoding.

- 3. 2). "When requirements 1 and 2 both apply, requirement 1 takes 
precedence".
 + My understanding is the inverse: i.e. requirement 2 takes precedence. I 
might be wrong.

- 4.1 ToASCII and 4.2 ToUnicode
 + the algorithm should more clearly state what happens when the "Verify 
actions" result to fail.

- 5 ACE prefix.
 "The ACE prefix, used in the conversion operations (section 4), will be 
specified in a future revision of this document.
 It will be two alphanumeric ASCII characters followed by two 
hyphen-minuses. ... "

 + I think IANA should specify the prefix in the IANA registry. Also the 
specification of the prefix (i.e. xx--) should not
 be included in this document, but is left to IANA. Or, it could be instead 
put in an IANA section in the document.

- 5 ACE prefix.
 + At the end of this section, there should be some words about the fact 
that in the long term, we might have a different prefix.
 The intent of this is only to tell developers that one way to change this 
"protocol" is through a new prefix. So implementations
 will be prepared to behave. Suggestion of wording:
 "Future revisions of this specification may involve using a different ACE 
prefix."

- 6.1 Entry and display in applications.
 "if it does, rendering the ACE SHOULD NOT be the default."
 + we should make it clear that the prefix MUST be shown if the ACE version 
is shown.  This is probably obvious for us, but the
 document is not clear about the fact that when "ACE" is used, it means 
with or without the prefix.  This comment is actually for
 most of the document. 6.4 second paragraph has the same ambiguity.

- after 8, should have an IANA considerations section. Here is a suggestion.
 IANA Considerations
 This specification requires the IANA to define a prefix that would be used 
for identifying an ACE label in a domain name.
 The prefix should be chosen to be not used at the time of the choice by 
any label in any depth of the dns tree. This might
 be impractical to find. The IANA should consult the IESG and the wg chairs 
to define such a prefix.

- 9. Security Considerations
 s/Much of the security of the Internet relies/Security on the Internet 
partly relies/


- General comment about normative references:
 + IDNA is the core/root of the documents.  It is right now not mentioning 
stringprep at all.
 It MUST clearly have a paragraph on stringprep and clearly reference it, 
with a clear "Mandatory to implement" statement.
  This is because stringprep contains important data for developers (for 
example, how to deal with versioning).





------------------------------------------
Marc Blanchet
Viagnie
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  Mon Feb 11 23: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 XAA25812
	for ; Mon, 11 Feb 2002 23:48:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aUlT-0003Zc-00
	for idn-data@psg.com; Mon, 11 Feb 2002 20:41:59 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aUlS-0003ZV-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 20:41:59 -0800
Received: from [] (modemcable094.128-130-66.que.mc.videotron.ca [66.130.128.94])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1C51La53387
	for ; Tue, 12 Feb 2002 00:01:21 -0500 (EST)
Date: Mon, 11 Feb 2002 23:41:32 -0500
From: Marc Blanchet 
To: idn@ops.ietf.org
Subject: [idn] few comments on stringprep
Message-ID: <111160000.1013488892@localhost>
X-Mailer: Mulberry/2.2.0b2 (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 XAA25812


 Few comments on stringprep

3. Mapping.
 + typo: s/database should used to/database should be used to/

4. Normalizatoin
 + there is an inline comment to be taken out. "[[[[[ Patrick asks: ..."

6. Unassigned code points
 + typo: s/repertoire named in the stringprep/repertoire named in a 
stringprep/

 6. 3rd paragraph.
 " prevents the need for versioning in protocols...".
 + I think we should put some reference to either 
draft-ietf-idn-versioning-00.txt
 or to some idn meeting minutes to refer the reader to the discussion on 
this topic.

6.1
+ typo:  on MN line: s/because they are never appear/because they never 
appear/


Annex B. IANA Considerations
+ this section should be completed and the in-line comment removed.

------------------------------------------
Marc Blanchet
Viagnie
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  Mon Feb 11 23:48: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 XAA25824
	for ; Mon, 11 Feb 2002 23:48:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aUl9-0003Z6-00
	for idn-data@psg.com; Mon, 11 Feb 2002 20:41:39 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aUl8-0003Yz-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 20:41:38 -0800
Received: from [] (modemcable094.128-130-66.que.mc.videotron.ca [66.130.128.94])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1C511a53373
	for ; Tue, 12 Feb 2002 00:01:01 -0500 (EST)
Date: Mon, 11 Feb 2002 23:41:12 -0500
From: Marc Blanchet 
To: idn@ops.ietf.org
Subject: [idn] few comments on punycode
Message-ID: <110820000.1013488872@localhost>
X-Mailer: Mulberry/2.2.0b2 (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 XAA25824

Few comments on punycode

- title: Punycode version 0.3.3.
 + the title should be changed to something like punycode version 1.0. 
version 0.3.3 does not look a stable specification.
  I would also argue to have a more descriptive name in the title, 
something like: "Punycode: an encoding designed for use iwth
  Internationalized Domain Names (idn)."

- 3.2 typo:  s/but should insead/but should instead/

- Annex B.
 + to me, this is not clear if it is mandatory to implement or not. We 
should put a clear statement about this.

= Annex D.
 + I would erase the first 8 lines in comments. The author is already 
identified in the draft (author section). Also
 the numbering of the versions is inconsistent!!!.


------------------------------------------
Marc Blanchet
Viagnie
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 Feb 12 00:12: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 AAA26079
	for ; Tue, 12 Feb 2002 00:12:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aV5J-0004cH-00
	for idn-data@psg.com; Mon, 11 Feb 2002 21:02:29 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aV5J-0004cB-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 21:02:29 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP
	id DEC3A160F; Tue, 12 Feb 2002 14:02:07 +0900 (JST)
Message-Id: <4.2.0.58.J.20020212110638.0454aba8@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 12 Feb 2002 11:07:42 +0900
To: Roozbeh Pournader , bidi@unicode.org,
        IDN 
From: Martin Duerst 
Subject: [idn] Re: [bidi] END OF AYAH vs NAMEPREP
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Hello Roozbeh,

At 04:54 02/02/08 +0330, Roozbeh Pournader wrote:

>I was wondering about our (Unicode bidi committee's) suggested change to
>the character category of U+06DD ARABIC END OF AYAH to a formatting
>character ("Cf" instead of "Me"), and how that could affect nameprep.
>Section 5.2 of the latest nameprep document marks all formatting
>characters prohibited, and this character may become a formatting
>character very soon...

Are you worried about a change to a property that will not be
tracked by nameprep? Or are you worrying that END OF AYAH
won't be usable in domain names?

Regards,    Martin.



>roozbeh
>
>--
>Note: If you want me to read a message, please make sure you include my
>address in "To" or "CC" fields. I may not be able to follow all the
>discussions on the mailing lists I subscribe. Sorry. (No, there's no problem
>to receive duplicates.)
>kl;klkl




From owner-idn@ops.ietf.org  Tue Feb 12 00:21: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 AAA26163
	for ; Tue, 12 Feb 2002 00:21:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aVFG-000549-00
	for idn-data@psg.com; Mon, 11 Feb 2002 21:12:46 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aVFF-000542-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 21:12:45 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020212051244.IWJS2951.rwcrmhc53.attbi.com@c1340594a>;
          Tue, 12 Feb 2002 05:12:44 +0000
Message-ID: <001e01c1b384$3b2e2760$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "D. J. Bernstein" , 
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to> <20020211221340.GE23357@nicemice.net> <20020212025005.26938.qmail@cr.yp.to>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Mon, 11 Feb 2002 21:15:04 -0800
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

>    (3) American-biased equivalences according to Mark Davis's UTR
21,
>        which is _not_ part of the Unicode standard.

(a) These are not American-biased equivalences.
(b) It is hardly "my" UTR. I'm the author, but the content is produced
under direction of the UTC and is approved at every stage by the UTC.
(c) UTR 21 was approved by the UTC for incorporation into Unicode 3.2.
Its new status will be reflected in Unicode 3.2, which will be final
very shortly.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "D. J. Bernstein" 
To: 
Sent: Monday, February 11, 2002 18:50
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)


> Adam M. Costello writes:
> > The reason IDNA does case-folding is to be consistent with the
existing
> > standard for domain names, which says they are case-insensitive.
>
> What the existing standard actually says is ``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.''
>
> Similarly, the Internet mail standards specifically require that
bytes
> in message headers---including domain names---be interpreted as
ASCII
> characters.
>
> Complete consistency with the existing standards would mean
continuing
> to use only bytes 0-127, continuing to interpret those bytes as
ASCII,
> and continuing to compare names as case-insensitive ASCII names.
>
> But we don't _want_ to follow those rules. We want to see glyphs
that
> simply aren't available in the ASCII character set.
>
> Of course, we have to maintain INTEROPERABILITY with all strings
used
> today, so we'll have to continue accepting A-Z and a-z as
equivalent.
> But there are many possible equivalence rules for non-ASCII strings.
> Here are several examples---certainly not a complete list:
>
>    (1) Exactly what software uses now: no equivalences outside
ASCII.
>
>    (2) Equivalence of characters that have duplicate glyphs but that
>        were kept separate by Unicode for one of the reasons
described in
>        http://www.unicode.org/unicode/standard/where.
>
>    (3) American-biased equivalences according to Mark Davis's UTR
21,
>        which is _not_ part of the Unicode standard.
>
>    (4) German equivalences: for example, o-umlaut equivalent to oe,
and
>        the German ss equivalent to the two-byte Latin sequence SS,
which
>        in turn is equivalent to the two-byte Latin sequence ss.
>
>    (5) Hebrew equivalences: for example, aleph-bar equivalent to
aleph.
>
>    (6) Various Chinese equivalences for the benefit of Chinese
users.
>
>    (7) Some combination of the above.
>
> All of these are INTEROPERABLE with the existing use of ASCII. None
of
> them are CONSISTENT with the existing standards. One of them, #1,
has
> the advantage of being by far the easiest to implement---but
provides
> the most opportunities for confusion and fraud.
>
> What exactly is the rational line between, for example, #3 and #4?
For
> ASCII characters they both boil down to A-Z matching a-z. Why is #3
a
> better extension of the current situation than #4, or #3+#4?
>
> James Seng states that #6 is pointless because ``domain names are
> identifier ... should enter into the computer exactly as they seen
it or
> reference it.'' Under exactly the same principle, #3 and #4 and #5
are
> all pointless, so IDNA has no excuse for the costs of #3.
>
> Another approach, allowing the software simplicity of #1 but
eliminating
> user confusion, is to allow _selected_ non-ASCII characters. We
don't
> have to map all characters to the selected set; we simply have to
make
> sure that the selected characters won't be confused by the users.
This
> neatly dodges the difficulty of defining a broad equivalence rule.
>
> The decisions here have to be based on rational assessments of costs
and
> benefits. Costello's notion of ``consistency'' is obviously not
helpful:
> it leads to such huge costs for Chinese users that it has already
drawn
> objections from _three hundred_ people.
>
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
>
>




From owner-idn@ops.ietf.org  Tue Feb 12 00:55: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 AAA26813
	for ; Tue, 12 Feb 2002 00:55:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aVpi-0006iH-00
	for idn-data@psg.com; Mon, 11 Feb 2002 21:50:26 -0800
Received: from imo-m06.mx.aol.com ([64.12.136.161])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aVph-0006ht-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 21:50:25 -0800
Received: from DougEwell2@cs.com
	by imo-m06.mx.aol.com (mail_out_v32.5.) id i.153.8c70495 (25511);
	Tue, 12 Feb 2002 00:50:20 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <153.8c70495.299a071b@cs.com>
Date: Tue, 12 Feb 2002 00:50:19 EST
Subject: Re: [idn] Interesting links
To: idn@ops.ietf.org
CC: hoho@iis.sinica.edu.tw, jseng@pobox.org.sg
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-11 18:48:00 Pacific Standard Time, 
hoho@iis.sinica.edu.tw writes:

> What happen in the WG will bring damage the
> community.

I keep seeing this word, "damage."

Is it really true that providing domain names in Chinese characters, but 
requiring users to enter them exactly as presented (without TC/SC 
equivalencing), would be more damaging to the Chinese user community than the 
current system, which provides no support at all for Chinese characters?

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Tue Feb 12 01:05: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 BAA26874
	for ; Tue, 12 Feb 2002 01:05:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aVyU-00077u-00
	for idn-data@psg.com; Mon, 11 Feb 2002 21:59:30 -0800
Received: from imo-m03.mx.aol.com ([64.12.136.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aVyT-00077n-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 21:59:29 -0800
Received: from DougEwell2@cs.com
	by imo-m03.mx.aol.com (mail_out_v32.5.) id u.16c.8af9791 (25511);
	Tue, 12 Feb 2002 00:58:57 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <16c.8af9791.299a0920@cs.com>
Date: Tue, 12 Feb 2002 00:58:56 EST
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
To: djb@cr.yp.to, idn@ops.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-11 18:58:32 Pacific Standard Time, djb@cr.yp.to 
writes:

> Costello's notion of ``consistency'' is obviously not helpful:
> it leads to such huge costs for Chinese users that it has already drawn
> objections from _three hundred_ people.

It has already drawn three hundred objections from people.  Some writers have 
apparently sent the chain letter more than once.

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Tue Feb 12 01:17: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 BAA26934
	for ; Tue, 12 Feb 2002 01:17:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aW90-0007Zm-00
	for idn-data@psg.com; Mon, 11 Feb 2002 22:10:22 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aW8z-0007ZU-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 22:10:21 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aW8y-0007st-00
	for ; Mon, 11 Feb 2002 22:10:20 -0800
Date: Tue, 12 Feb 2002 06:10:20 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020212061019.GL26818@nicemice.net>
Reply-To: IETF idn working group 
References: <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C68936E.602B7B7@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

I wrote:

> What do you think of this wording:
> 
>   2) 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.  Given an
>   internationalized domain name, an equivalent domain name containing
>   no ACE labels can be obtained by applying the ToUnicode operation
>   (see section 4) to each label.  When requirements 1 and 2 both
>   apply, requirement 1 takes precedence.

"Eric A. Hall"  replied:

> Was there a problem with the explicit text I provided?

I prefer to be more concise.  I tried to incorporate all the points I
agreed with.  The above wording is significantly less strong that the
wording in the current draft.

> The text presented here still encourages a default behavior of
> transliterating anything that looks like a domain name,

Not things that look like domain names, things that are known to be
domain names.  That's what the "obtained from a domain name slot" is
for.  And I added "except when the use of the non-ASCII form would cause
problems".  But yes, I still want users to be shown the non-ASCII form
except when there's a reason for them to be shown the ACE form.

> when it should be the opposite.

I'm afraid I disagree.  People have said in the past that IDNA is
pointless if users always see the ACE form.  The world you seem to be
envisioning is one in which users would be seeing the ACE form an awful
lot.

> > We should be able to update mail user agents (like Pine) and
> > immediately be able to use IDNs in email addresses without having
> > to touch mail transfer agents (like sendmail) or DNS servers (like
> > bind), and without having to wait for any updates to protocol
> > specifications (like the DNS spec and the SMTP spec) or data format
> > specifications (like RFC 2822).
>
> Not possible.
>
> We seem to have a disconnect here.

Apparently.

> "LDH slot"?

Many generic domain name slots allow all ASCII characters, not just LDH
characters.  But "ASCII slot" is not appropriate either, because the
essence of the concept is not what the slot allows or what standard it
cites; the essence of the concept is what standard the slot does *not*
cite, namely the IDNA spec.  So the term needs to convey non-specialness
or non-i18n-ness.  If you don't like "generic" or "vanilla" or
"ordinary" or "non-internationalized" or anything along those lines,
then we're probably not going to find common ground.

> The prohibition needs to be against all punctuation.

For host names, right, not domain names in general?  I think I like this
model:  Just as ASCII host names exclude many of the characters allowed
in ASCII domain names, internationalized host names would exclude
many of the characters allowed in internationalized domain names (the
same sorts of characters: punctuation and symbols).  There would be
two stringprep profiles, nameprep with a small prohibition table, and
hostprep with a large prohibition table.

However, I think it's probably too late for this.  I very much doubt
that most people would be interested in making such drastic changes at
this late date.  Non-ASCII punctuation is not threatening enough to
warrant derailing the process.

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 01:51: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 BAA27218
	for ; Tue, 12 Feb 2002 01:51:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aWbf-0008qx-00
	for idn-data@psg.com; Mon, 11 Feb 2002 22:39:59 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aWbe-0008qr-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 22:39:58 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55454 for idn@ops.ietf.org; Tue, 12 Feb 2002 00:39:21 -0600
Message-ID: <3C68B8BB.8E49A530@ehsco.com>
Date: Tue, 12 Feb 2002 00:39:55 -0600
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] WG last call documents
References: <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@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:

> > when it should be the opposite.
> 
> I'm afraid I disagree.  People have said in the past that IDNA is
> pointless if users always see the ACE form.

I'm not saying that the ACE form is the only form that should EVER be
used, what I'm saying is that the default mandate is dysfunctional.

The only thing that IDNA provides is a backwards-compatible encoding. The
benefit will come when the protocols and data-formats are extended to
support it. I know this violates the religious doctrine section that
promises milk honey and sunshine for everybody immediately. Sorry.

But hey, prove me wrong. I've given you plenty of examples, so you should
be able to come up with one. Please list the RFC822 header fields that
IDNA should be transliterated versus the header fields that should not be
transliterated. Any such list will by nature not conform with the default
mandate. The mandate is dysfunctional. You cannot prove otherwise.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Tue Feb 12 01:57: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 BAA27394
	for ; Tue, 12 Feb 2002 01:57:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aWis-0009Bv-00
	for idn-data@psg.com; Mon, 11 Feb 2002 22:47:26 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aWir-0009Bf-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 22:47:25 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aWiq-0007yQ-00
	for ; Mon, 11 Feb 2002 22:47:24 -0800
Date: Tue, 12 Feb 2002 06:47:24 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] Few comments on idna
Message-ID: <20020212064724.GM26818@nicemice.net>
Reply-To: IETF idn working group 
References: <110820000.1013488872@localhost> <111160000.1013488892@localhost> <109960000.1013488820@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <110820000.1013488872@localhost> <111160000.1013488892@localhost> <109960000.1013488820@localhost>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Marc Blanchet  wrote:

> here is few comments on idna.
> 
> - p2. "To allow such a label to be handled by existing applications, an 
> "ACE label" is defined ..."
> + ACE should be spelled: ASCII Compatible Encoding.

Good catch, "ASCII Compatible Encoding" never appears anywhere in the
IDNA draft.  It's awkward to insert in the middle of "ACE label", but we
could add "(ACE stands for ASCII Compatible Encoding)" at the end of the
sentence.

> - 3. 2). "When requirements 1 and 2 both apply, requirement 1 takes 
> precedence".
> + My understanding is the inverse: i.e. requirement 2 takes precedence. I 
> might be wrong.

You are wrong.  :)

The ASCII form might be ugly, but software won't choke on it.  The
non-ASCII form is pretty, but some software will choke on it, and that's
more important.  So requirement 1 takes precedence.  It basically says
don't pass non-ASCII domain names to software that might choke on it.

> - 4.1 ToASCII and 4.2 ToUnicode
> + the algorithm should more clearly state what happens when the "Verify 
> actions" result to fail.

Section 4.1 says "ToASCII fails if any step of it fails.  Failure
means that the original sequence cannot be used as a label in an IDN."
Section 4.2 says "ToUnicode never fails.  If any step fails, then the
original input sequence is returned immediately in that step."  How can
we be any clearer?

> - 6.1 Entry and display in applications.
> "if it does, rendering the ACE SHOULD NOT be the default."
> + we should make it clear that the prefix MUST be shown if the ACE
> version is shown.  This is probably obvious for us, but the document
> is not clear about the fact that when "ACE" is used, it means with
> or without the prefix.

Section 2 says "The 'ACE prefix' is defined in this document to be
a string of ASCII characters that appears at the beginning of every
ACE label." and "The conversion of labels to and from the ACE form is
specified in section 4.", and in section 4 ToASCII is defined in such a
way that ACE labels always begin with the ACE prefix.  Section 5 "ACE prefix"
even gives an example:

    For example, the eventual ACE prefix might be the string "jk--".
    In this case, an ACE label might be "jk--r3c2a-qc902xs", where
    "r3c2a-qc902xs" is the part of the ACE label that is generated by
    the encoding steps in [PUNYCODE].

I have a hard time imagining what would lead someone to think that "ACE"
refers to the part after the prefix.  But if Patrik or Paul wants to
make an editorial change emphasizing that, I don't see what harm it
would cause.

> - title: Punycode version 0.3.3.
> + the title should be changed to something like punycode version 1.0. 

Agreed.  In the next revision it will be 1.0.0.

>  I would also argue to have a more descriptive name in the title,
> something like: "Punycode: an encoding designed for use iwth
> Internationalized Domain Names (idn)."

Agreed.  How about "Punycode: An encoding of Unicode for use with IDNA"?
(I think it's significant that it's for use with IDNA as opposed to IDN.
I could expand IDNA if you like, but that would get very long.)

> - 3.2 typo:  s/but should insead/but should instead/

Thanks.

> - Annex B.
> + to me, this is not clear if it is mandatory to implement or not. We 
> should put a clear statement about this.

The introduction says "Punycode can support an optional feature
described in appendix B", and the third (== last) paragraph of appendix
B is "Punycode encoders and decoders are not required to support these
annotations, and higher layers need not use them."  Is that not clear
enough?  Should I add a third such statement at the beginning of the
appendix?  Or move the last paragraph to the beginning of the appendix
(which means it would contain forward references)?

> = Annex D.
> + I would erase the first 8 lines in comments. The author is already 
> identified in the draft (author section).

You would, but I wouldn't. :) The first thing most people are going to
do with the sample code is save it to a .c file, and I want the version
information to be kept with it, along with the URL pointing at possibly
newer versions of the sample code.

> Also the numbering of the versions is inconsistent!!!.

The sample code has its own version number.  The version numbers of both
the spec and the sample code will become 1.0.0 in the next revision,
but they could diverge after that.  Editorial changes to the spec don't
cause changes in the sample code.  Also, an interface change in the
sample code could cause a large jump in the sample code version (to
1.1.0 or 2.0.0) while causing only a small jump in the spec version (to
1.0.1).

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 02:16: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 CAA05346
	for ; Tue, 12 Feb 2002 02:16:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aX3v-000A9H-00
	for idn-data@psg.com; Mon, 11 Feb 2002 23:09:11 -0800
Received: from pheriche.sun.com ([192.18.98.34])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aX3u-000A9B-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 23:09:10 -0800
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16614;
	Tue, 12 Feb 2002 00:09:08 -0700 (MST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1C793M13117;
	Tue, 12 Feb 2002 08:09:04 +0100 (MET)
Date: Tue, 12 Feb 2002 01:41:36 +0100 (CET)
From: Erik Nordmark 
Reply-To: Erik Nordmark 
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
To: Kent Karlsson 
Cc: idn@ops.ietf.org
In-Reply-To: "Your message with ID" <000201c1b02e$b9b7cfe0$cfc11081@chalmers95a69n>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> 1. stringprep and nameprep should be rejoined to a
> hostnameprep. They are only about host name preparation,
> not any other name preparation.  Similar preparations
> may still take advantage of the hostnameprep document,
> by declaring "deltas", small changes that may be needed
> for other (Internet, DNS) names.  That would likely
> minimise the size of the "reuse" documents.

Kent,

There is work going you in other WGs to use stringprep (that you might not
be aware of).
Is the high-order bit of this comment that you'd like nameprep
be renamed hostnameprep?


> 6. Hangul syllables (with conjoining characters, not
> non-conjoining compatiblity characters) that represent
> the same syllable must be mapped to the same representation.
> Due to unfortunate historic reasons, this does no longer
> happen automatically with NFKC (though for drafts for
> NFKC it did).  Mappings should be added so that "syllabically"
> equivalent Hangul conjoning characters are mapped to a common
> representation.  Hangul compatibility letters should be
> prohibited though.  Correctly mapping those is more complicated
> than can be expressed in the (current form of) (host)nameprep
> mappings. Hangul compatibility letters should instead be
> prohibited. (Mapping table for Jamos, and prohibition table for
> Hangul compatibility characters, are available upon request.)
> Future keyboard, e.g., input may generate only single letter
> Jamos, rather than any "cluster letter" Jamos or precomposed
> Hangul syllable characters.  At the very least, hostnameprep
> should not prevent such a development.

This sounds like you are proposing to fix/change a decision made by the
Unicode consortium. Why is that in scope?

> 9. User interfaces that encounter mixed script hostname *parts*
> should be recommended to "flag" them (ballon warning, color
> differentiate, make blinking, bounce automatic registratations, ...).

By "*parts*" do you mean labels or something else?

  Erik




From owner-idn@ops.ietf.org  Tue Feb 12 02:23: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 CAA05379
	for ; Tue, 12 Feb 2002 02:23:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aXCe-000AVU-00
	for idn-data@psg.com; Mon, 11 Feb 2002 23:18:12 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aXCd-000AVO-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 23:18:11 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16aXCd-00086n-00
	for ; Mon, 11 Feb 2002 23:18:11 -0800
Date: Tue, 12 Feb 2002 07:18:11 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020212071810.GO26818@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C68B8BB.8E49A530@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> Please list the RFC822 header fields that IDNA should be
> transliterated versus the header fields that should not be
> transliterated.

When an application is displaying header fields to the user, it should
apply ToUnicode to domain labels found in domain name slots.  RFC 822
defines the syntax of every header field, and some of those fields have
 in their definition.  Those s are the domain name
slots.  Anything else in the header is not a domain name slot.

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 02:34: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 CAA05477
	for ; Tue, 12 Feb 2002 02:34:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aXOT-000BAn-00
	for idn-data@psg.com; Mon, 11 Feb 2002 23:30:25 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aXOS-000BAR-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 23:30:24 -0800
Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA16953;
	Tue, 12 Feb 2002 08:30:19 +0100 (MET)
Date: Tue, 12 Feb 2002 08:24:46 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
To: "Eric A. Hall" ,
        IETF idn working group 
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <2686645.1013502286@localhost>
In-Reply-To: <3C686505.9A49BF56@ehsco.com>
References: <20020211.093423.-412797.0.liana.ydisg@juno.com>
 <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to>
 <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to>
 <20020211221340.GE23357@nicemice.net> <3C686505.9A49BF56@ehsco.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
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 2002-02-11 18.42 -0600 "Eric A. Hall"  wrote:

> "Adam M. Costello" wrote:
> 
>> The reason IDNA does case-folding is to be consistent with the
>> existing standard for domain names, which says they are
>> case-insensitive.
> 
> More specifically, the encoded representation of an uppercase i18n domain
> name is different than the encoded representation of a lowercase i18n
> domain name, so the only way that case-neutral matching of the encoding
> sequence can work is if the i18n domain name is case-neutered before it is
> encoded.

Correct. Thanks Eric.

What I should have said.

  paf




From owner-idn@ops.ietf.org  Tue Feb 12 02:35: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 CAA05491
	for ; Tue, 12 Feb 2002 02:35:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aXOP-000BA0-00
	for idn-data@psg.com; Mon, 11 Feb 2002 23:30:21 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aXOO-000B9e-00
	for idn@ops.ietf.org; Mon, 11 Feb 2002 23:30:21 -0800
Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA16940
	for ; Tue, 12 Feb 2002 08:30:18 +0100 (MET)
Date: Tue, 12 Feb 2002 08:22:16 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Message-ID: <2677666.1013502136@localhost>
In-Reply-To: <20020211214855.11426.qmail@cr.yp.to>
References: <20020211.093423.-412797.0.liana.ydisg@juno.com>
 <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to>
 <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
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 2002-02-11 21.48 +0000 "D. J. Bernstein"  wrote:

> Patrik responded:
>> Because we do comparison of Unicode strings.
>> See http://www.unicode.org/unicode/faq/normalization.html
>> I.e. not our choice (more than choosing to use Unicode).
> 
> Patrik is lying. The web page that he cites does _not_ require, or even
> suggest, that uppercase and lowercase should be considered equivalent.
> Unicode normalization is about things like e-with-a-separate-egu-accent
> matching the combined e-egu character.

You just asked for "certain mappings and no others". I pointed to the
source for nameprep mappings. You did _not_ say "arguments for case
folding".

I don't understand where you get "lying" from?

I took for granted you knew that case folding is done already in DNS, and
that people has asked for case folding to continue to be valid also for
other scripts.

   paf




From owner-idn@ops.ietf.org  Tue Feb 12 03:48: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 DAA06269
	for ; Tue, 12 Feb 2002 03:48:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aYSk-000ESC-00
	for idn-data@psg.com; Tue, 12 Feb 2002 00:38:54 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16aYSj-000ES5-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 00:38:53 -0800
Received: (qmail 11284 invoked by uid 1001); 12 Feb 2002 08:37:47 -0000
Date: 12 Feb 2002 08:37:47 -0000
Message-ID: <20020212083747.24793.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to> <2677666.1013502136@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Patrik writes:
> You just asked for "certain mappings and no others".

Liar. I started by quoting two lines from Klensin saying that TC/SC was
``not analogous to case-mapping.'' I then quoted Seng's TC/SC response,
and said ``This answer destroys the stated reasons for case-mapping.''

> I don't understand where you get "lying" from?

I attribute your behavior to malice because it cannot be adequately
explained by stupidity. It is simply not possible to read my message
without observing that I was talking about case-mapping.

This is not the first time that you have blatantly misrepresented the
statements of people who object to IDNA.

I have heard, by the way, that some of your company's products are not
8-bit-clean: in particular, they fail to handle UTF-8 transparently. Is
this true? Your position on the IESG gives you substantial power to
elevate your company's interests above the interests of the community;
you have a clear conflict of interest if you are making decisions on
proposals that affect your company's products.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Tue Feb 12 04:17: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 EAA06619
	for ; Tue, 12 Feb 2002 04:17:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aYws-000FxX-00
	for idn-data@psg.com; Tue, 12 Feb 2002 01:10:02 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16aYwr-000Fx9-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 01:10:01 -0800
Received: (qmail 27739 invoked by uid 1001); 12 Feb 2002 09:09:00 -0000
Date: 12 Feb 2002 09:09:00 -0000
Message-ID: <20020212090900.13619.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: IETF idn working group 
Subject: [idn] IDNA interoperability failures, once again
References: <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Adam M. Costello writes:
> When an application is displaying header fields to the user,

Define your terminology. How does a UNIX program figure out whether it
is displaying something ``to the user''? (Anyone who doesn't understand
this question should read ``The UNIX Philosophy,'' by Mike Gancarz.)

One of many examples: Surely you are familiar with the ``dig'' program.
The output of ``dig soa berkeley.edu'' includes all the SOA information
for berkeley.edu. This output might be

   * piped to the ``less'' program, a generic text viewer that (usually)
     displays the results to the user; or

   * piped to a script that extracts the hostmaster address and invokes
     the ``sendmail'' program to send email; or

   * saved to a file, later viewed with ``less''; or

   * saved to a file, later piped to that script.

Yes or no: Should ``dig'' convert its results from your 7-bit encoding
to the local character set? (Assume the LANG=en_US.UTF-8 locale, so that
the conversion is at least theoretically doable.)

An answer of ``no'' means that you're failing to display the desired
non-ASCII glyphs to the user. In other words, you're missing the whole
point of IDNs.

An answer of ``yes'' creates an interoperability failure, just like the
copy-and-paste interoperability failure that you've been ignoring for
months. The mail will bounce.

If you try to dodge this question by drawing some silly distinction
between ``dig'' and other programs, I'll start asking about those other
programs. The nmh mail-handling system leaps to mind.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Tue Feb 12 06:21: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 GAA07827
	for ; Tue, 12 Feb 2002 06:21:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aanq-000LO6-00
	for idn-data@psg.com; Tue, 12 Feb 2002 03:08:50 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aanp-000LO0-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 03:08:49 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1CB8kh23210
	for ; Tue, 12 Feb 2002 12:08:46 +0100 (MET)
From: "Kent Karlsson" 
To: 
Subject: [idn] a few more comments on the last call documents
Date: Tue, 12 Feb 2002 12:05:51 +0100
Message-ID: <000301c1b3b5$3cea6010$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA07827

Some smaller comments (most, but not all, editorial):


IDNA:
  clause 1:
	"src attribute in an HTML  tag" --> "'src' attribute in an XHTML 'img' tag" 
		(promote XHTML instad of HTML, and quoting attribute and tag names)

  clause 6.1:
	"and can display domain names in any charset"; apart from that "any"
	here is a very strong assumption, I cannot make sense of that sentence.

  clause 6.2:
	"not only domain names in Unicode, but also in local script"; that
	does not make sense

  clause 6.3:
	"this memo", memo?

  clause 6.4:
	"displaying the name with the replacement character"?  The replacement
	character does not figure in displaying any other character (except
	in Linux xterm, but that's twisted); a (or or one of the) replacement
	glyph(s) is used however, when a proper glyph cannot be found.

	"...SHOULD show the name in ACE format... This is to make is to make it
	easier to transfer the name correctly to other programs"; cut and paste
	works very well also for strings that contain characters not in the
	font used at the moment, using an ACE display will be more of problem
	than help.  Please remove that UNHELPFUL recommendation.

	"show...replacement character"; same error; display is done via glyphs
	not via characters (the mapping is non-trivial)

  clause 6.4: "all Unicode text is stored in logical order".  I wish,
	but this does not hold for the "logical_order_exception" characters,
	nor for Khmer ROBAT, and need not hold for the Arabic presentation
	forms.

  General: There should be opening for transition to a long-term non-ACE
	solution (probably based on UTF-8).  The ACE based solution should
	be explicitly declared to be short-term.



stringprep:
  clause 1.1: "aepfel" is a *fallback* for "äpfel", they are not equivalent
	at all.  They sometimes (only sometimes) collate the same in German.
	(One could argue that combining diaeresis and combining latin small
	letter e are "more equivalent" (than the given example); but small
	letter e as a diacritic above has fallen out of use.)

  clause 3: [case] "mapping"; nameprep does not do case mapping, it does
	case folding (not quite the same).

  clause 4: "for KC" --> "form KC"



nameprep:
  clause 1.2: "SYMBOLS" does not occur in the tables; though it should
	[as I mentioned in another comment]...

  clause 3.1: Khmer "INHERENT" vowels are invisible, and should in most
	cases (if not all cases) be ignored, in IDNs in particular;
	there may be a few mappings that should be done for Khmer for
	mistaken encodings as characters)

  clause 5.3: the replacement character is not used or display, it works
	on the character level, not at the glyph level

  clause 5.8: 10646 does not deprecate any characters; but Unicode does
	deprecate those characters.



		Kind regards
		/kent k




From owner-idn@ops.ietf.org  Tue Feb 12 06:21: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 GAA07841
	for ; Tue, 12 Feb 2002 06:21:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aag5-000L21-00
	for idn-data@psg.com; Tue, 12 Feb 2002 03:00:49 -0800
Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aag2-000L1h-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 03:00:47 -0800
Received: from bamdad.org (IDENT:root@bamdad.org [194.225.42.242])
	by sina.sharif.edu (8.11.6/8.11.6) with ESMTP id g1CB0ed14966;
	Tue, 12 Feb 2002 14:30:40 +0330
Received: from localhost (roozbeh@localhost)
	by bamdad.org (8.11.6/8.11.6) with ESMTP id g1CB8VH01466;
	Tue, 12 Feb 2002 14:38:31 +0330
X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs
Date: Tue, 12 Feb 2002 14:38:31 +0330 (IRT)
From: Roozbeh Pournader 
X-X-Sender: roozbeh@gilas.bamdad.org
To: Martin Duerst 
cc: bidi@unicode.org, IDN 
Subject: [idn] Re: [bidi] END OF AYAH vs NAMEPREP
In-Reply-To: <4.2.0.58.J.20020212110638.0454aba8@localhost>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Tue, 12 Feb 2002, Martin Duerst wrote:

> Are you worried about a change to a property that will not be
> tracked by nameprep? Or are you worrying that END OF AYAH
> won't be usable in domain names?

The first. We will then be allowing a control character pass nameprep.

roozbeh




From owner-idn@ops.ietf.org  Tue Feb 12 06:48: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 GAA08192
	for ; Tue, 12 Feb 2002 06:48:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16abH6-000MpK-00
	for idn-data@psg.com; Tue, 12 Feb 2002 03:39:04 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16abH5-000MpE-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 03:39:03 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1CBcxh24431;
	Tue, 12 Feb 2002 12:38:59 +0100 (MET)
From: "Kent Karlsson" 
To: "'Erik Nordmark'" 
Cc: 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Tue, 12 Feb 2002 12:36:04 +0100
Message-ID: <000401c1b3b9$75428560$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: 
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
...
> > 1. stringprep and nameprep should be rejoined to a
> > hostnameprep. They are only about host name preparation,
> > not any other name preparation.  Similar preparations
> > may still take advantage of the hostnameprep document,
> > by declaring "deltas", small changes that may be needed
> > for other (Internet, DNS) names.  That would likely
> > minimise the size of the "reuse" documents.
> 
> Kent,
> 
> There is work going you in other WGs to use stringprep (that 
> you might not
> be aware of).
> Is the high-order bit of this comment that you'd like nameprep
> be renamed hostnameprep?

Both the title and abstract of nameprep says that it is about
host names (or even host name parts).

However, the gist of the comment you are referring to is that:

There should be a basic approach (currently stringprep)
*and* a basic table of mappings and prohibitions, and that
deltas should be made from that.  Currently each use of stringprep
must have complete tables, and cannot reuse a common basic
table (per version of Unicode).

The idea is to have more reuse through having such a common
table.  It would make the similar (in other WGs) uses easier to
review and (once approved) use.

To make that workable, the basic table should be very restrictive
and not allow any punctuation or symbols (other than full stops,
and hyphen-like characters).  The latter can then be taken into
use as either syntax around domain names or be included in
certain other kinds of domain names than hostnames on a per
punctation/symbol basis.

Going the other way around (as seems to be suggested by the
authors), frezes at time of first deployment which
punctuation/symbols can and cannot be used in future
syntaxes that embed domain names.  In particular, the current
suggestion *forbids* as special use (i.e. surrounding syntax or
use in special purpose (non-host) domain names) any non-ASCII
symbol/punctuation.

> > 6. Hangul syllables (with conjoining characters, not
> > non-conjoining compatiblity characters) that represent
> > the same syllable must be mapped to the same representation.
> > Due to unfortunate historic reasons, this does no longer
> > happen automatically with NFKC (though for drafts for
> > NFKC it did).  Mappings should be added so that "syllabically"
> > equivalent Hangul conjoning characters are mapped to a common
> > representation.  Hangul compatibility letters should be
> > prohibited though.  Correctly mapping those is more complicated
> > than can be expressed in the (current form of) (host)nameprep
> > mappings. Hangul compatibility letters should instead be
> > prohibited. (Mapping table for Jamos, and prohibition table for
> > Hangul compatibility characters, are available upon request.)
> > Future keyboard, e.g., input may generate only single letter
> > Jamos, rather than any "cluster letter" Jamos or precomposed
> > Hangul syllable characters.  At the very least, hostnameprep
> > should not prevent such a development.
> 
> This sounds like you are proposing to fix/change a decision 
> made by the Unicode consortium. Why is that in scope?

Even though e.g. [gg] and [g][g] (there are a few hundred other examples)
are not canonically or compatibility equivalent, they still represent
the same sequence of Hangul letters, and thus "mean" the same.
Even though not all systems display the decompostions correctly yet,
there is no reason to believe that that they will not be supported
by most rendering engines for Hangul.  Unfortunately, the normal
forms cannot be changed at this time, even though that would have
been better.  There have been many misconceptions around about,
e.g., where Hangul syllable break are, which may have lead
to the current situation.  Once those misconceptions are cleared
up, you will likely see more comments to the fact that [gg] and [g][g]
(etc.!) are in fact equivalent from a Hangul perspective.

> > 9. User interfaces that encounter mixed script hostname *parts*
> > should be recommended to "flag" them (ballon warning, color
> > differentiate, make blinking, bounce automatic 
> registratations, ...).
> 
> By "*parts*" do you mean labels or something else?

stringprep: "DNS domain name parts";

idna: "A label is an individual part of a domain name";

nameprep: "This document describes how to prepare
	internationalized host name parts" (I think that's the
	wrong approach, e.g. it should apply to the entire name,
	but I'm just quoting for the term here.)

		Kind regards
		/kent k


>   Erik
> 



From owner-idn@ops.ietf.org  Tue Feb 12 06:50: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 GAA08215
	for ; Tue, 12 Feb 2002 06:50:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16abMS-000N6q-00
	for idn-data@psg.com; Tue, 12 Feb 2002 03:44:36 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16abMR-000N6h-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 03:44:35 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1CBiXh24719
	for ; Tue, 12 Feb 2002 12:44:33 +0100 (MET)
From: "Kent Karlsson" 
To: "'IETF idn working group'" 
Subject: RE: [idn] stringprep comment 5: hangul conjoining sequence
Date: Tue, 12 Feb 2002 12:41:39 +0100
Message-ID: <000701c1b3ba$3cbbbcb0$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <20020211214832.GD23357@nicemice.net>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: owner-idn@ops.ietf.org 
> [mailto:owner-idn@ops.ietf.org]On Behalf Of
> Adam M. Costello
> Sent: den 11 februari 2002 22:49
> To: idn@ops.ietf.org
> Subject: Re: [idn] stringprep comment 5: hangul conjoining sequence
> 
> 
> Kent Karlsson  wrote:
> 
> > Compatibility (non-conjoining) Hangul letters are best prohibited.
> 
> Stringprep does normalization before prohibition, so prohibiting
> compatibility characters would have no effect.  After the 
> normalization
> step, there are no compatibility characters in the string.


Ouch!  That leads to results that are completely off the board:
NFKC or NFKD on Hangul compatibility letter sequences leads
to completely wrong results; in particular the distinction between
lead and trail consonants becomes just plain wrong.


> A trick you could play, however, would be to map the characters in
> question to an arbitrary prohibited character that survives the
> normalization step (like U+0000).

Ok, consider that my revised suggestion.

		Kind regards
		/kent k


> AMC
> 



From owner-idn@ops.ietf.org  Tue Feb 12 07:09: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 HAA08996
	for ; Tue, 12 Feb 2002 07:09:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16abf1-000O4A-00
	for idn-data@psg.com; Tue, 12 Feb 2002 04:03:47 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16abez-000O44-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 04:03:46 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1CC3bh26029;
	Tue, 12 Feb 2002 13:03:37 +0100 (MET)
From: "Kent Karlsson" 
To: "'Eric A. Hall'" ,
        "'IETF idn working group'" 
Subject: RE: [idn] WG last call documents
Date: Tue, 12 Feb 2002 13:00:42 +0100
Message-ID: <000801c1b3bc$e642de10$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <3C684239.738EE007@ehsco.com>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

 
> > But there is one class of characters that might indeed be 
> dreadful at
> > the beginning: combining characters.  I recently refered to labels
> > that begin with combining characters as invalid Unicode strings, but
> > they're not, are they?  They just behave in surprising ways when
> > abutted with something else.  Maybe nameprep should prohibit initial
> > combining characters.
> 
> Note that these are rules for hostnames in particular.
> 
> A prohibition against combining characters is not feasible. See
> <200111212258.OAA23757@birdie.sybase.com> from K Whistler.
> 
> This was resolved without disconsent in <3C0DD610.F50F947B@ehsco.com>:
> 
>  | First and last characters in the label MUST NOT be a diacritical
>  | mark or hyphen-minus.



I agree that having a combining character as the first character
in a hostname part (label) is a bad idea (nominally it combines with what
is before it and can in rare cases be "absorbed" into syntax before
the acutal string (like in >/, for xhtml, where / is combining long solidus;
after NFC (applied blindly to the entire text) there will be a precomposed
negated greater than character there...)

But I see absolutely no reason to prohibit combining characters
at the end of a label (unless applied to a hyphen-like character...).

		Kind regards
		/kent k




From owner-idn@ops.ietf.org  Tue Feb 12 07:09: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 HAA09021
	for ; Tue, 12 Feb 2002 07:09:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16abew-000O40-00
	for idn-data@psg.com; Tue, 12 Feb 2002 04:03:42 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16abev-000O3p-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 04:03:41 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP
	id 0D02ADEE; Tue, 12 Feb 2002 21:03:18 +0900 (JST)
Message-Id: <4.2.0.58.J.20020212205636.03d404f0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 12 Feb 2002 21:00:29 +0900
To: "Kent Karlsson" , 
From: Martin Duerst 
Subject: Re: [idn] a few more comments on the last call documents
In-Reply-To: <000301c1b3b5$3cea6010$b4e21081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

At 12:05 02/02/12 +0100, Kent Karlsson wrote:
>Some smaller comments (most, but not all, editorial):

>stringprep:
>   clause 1.1: "aepfel" is a *fallback* for "$BC$(Bpfel", they are not equivalent
>         at all.  They sometimes (only sometimes) collate the same in German.
>         (One could argue that combining diaeresis and combining latin small
>         letter e are "more equivalent" (than the given example); but small
>         letter e as a diacritic above has fallen out of use.)

This is definitely true. Some more details:

The text says

     "aepfel" vs. "pfel.com"

thus equating apples with oranges. It should either be

     "aepfel.com vs. pfel.com"

or it should be

     "Aepfel" vs. "pfel"

(nouns are always written in upper case in German).


Regards,    Martin.





From owner-idn@ops.ietf.org  Tue Feb 12 07:10: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 HAA09094
	for ; Tue, 12 Feb 2002 07:10:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16abex-000O42-00
	for idn-data@psg.com; Tue, 12 Feb 2002 04:03:43 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16abev-000O3o-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 04:03:41 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP
	id 54E3BCFB; Tue, 12 Feb 2002 21:03:17 +0900 (JST)
Message-Id: <4.2.0.58.J.20020212205258.03c10650@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 12 Feb 2002 20:54:09 +0900
To: Roozbeh Pournader 
From: Martin Duerst 
Subject: Re: [idn] Re: [bidi] END OF AYAH vs NAMEPREP
Cc: bidi@unicode.org, IDN 
In-Reply-To: 
References: <4.2.0.58.J.20020212110638.0454aba8@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

You have a much better idea about END OF AYAH than I have.
If you think it should not be part of IDN, then just
propose to put it on the 'prohibited' list.

Regards,   Martin.

At 14:38 02/02/12 +0330, Roozbeh Pournader wrote:
>On Tue, 12 Feb 2002, Martin Duerst wrote:
>
> > Are you worried about a change to a property that will not be
> > tracked by nameprep? Or are you worrying that END OF AYAH
> > won't be usable in domain names?
>
>The first. We will then be allowing a control character pass nameprep.
>
>roozbeh




From owner-idn@ops.ietf.org  Tue Feb 12 08:05: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 IAA10089
	for ; Tue, 12 Feb 2002 08:05:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16acT4-0000X5-00
	for idn-data@psg.com; Tue, 12 Feb 2002 04:55:30 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16acT3-0000WZ-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 04:55:29 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP
	id B4AB08F4; Tue, 12 Feb 2002 21:54:54 +0900 (JST)
Message-Id: <4.2.0.58.J.20020212085644.0316e990@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 12 Feb 2002 21:40:16 +0900
To: Paul Hoffman / IMC 
From: Martin Duerst 
Subject: Re: [idn] Last call comments to nameprep/stringprep: BIDI
Cc: mark.davis@us.ibm.com, mark@macchiato.com (Mark Davis), atkin@us.ibm.com,
        Patrik Faltstrom , idn@ops.ietf.org, ietf-bidi@imc.org,
        bidi@unicode.org
In-Reply-To: 
References: <4.2.0.58.J.20020211203223.042e8090@localhost>
 <4.2.0.58.J.20020211203223.042e8090@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Hello Paul,

At 15:29 02/02/11 -0800, Paul Hoffman / IMC wrote:
>I am replying to all minus the IDN mailing list. I have added Patrik to 
>the Cc list.

I have added the IDN mailing list back in. Please keep it.
I have also included the other relevant mailing lists in
the cc, to bring things to a quick conclusion.


>At 8:45 PM +0900 2/11/02, Martin Duerst wrote:
>>Currently, neither draft-ietf-idn-nameprep-07.txt nor
>>draft-hoffman-stringprep-00.txt deal with bidirectionality
>>(mixing right-to-left (Arabic/Hebrew) and left-to-right
>>writing directions) issues. This should be changed as soon
>>as possible.
>
>You didn't say why this should be one as part of nameprep or stringprep. 
>What about bidi makes the issue a preparation issue, particularly for 
>prohibition?

See below.


>>If a label can contain both right-to-left and left-to-right
>>characters, how it will be displayed, and how displayed
>>labels will be entered and looked up in the DNS, is highly
>>context-dependent. This is obviously very undesirable.
>
>This is a display issue; it has absolutely nothing to do with how names 
>are entered or looked up in the DNS.

It is not a display issue, it is an issue of conversion
between display and backing store.

Assume there were two labels inside the DNS, one reading ABCdef
and the other reading defABC, and both would be displayed
CBAdef. Who would consider that usable for the DNS?

With the current nameprep, this and similar situations will
happen if e.g. upper-case is in a right-to-left script, and
lower case in a left-to-right script.

Many similar issues have been discussed on this list. But please
note that it is not an issue of different characters in Unicode
looking the same or similar. It's exactly the same characters!

Also, please note that while for similar issues discussed on this
list, the problem was that there was not really a workable solution,
this is not the case here. Two main solutions have been proposed.


>>The following is a proposal written up by Mark Davis,
>>based on input from others:
>
>This has barely been discussed in the BIDI community; there has been 
>almost no review of it. Further, there was disagreement on it when Mark 
>presented it.

There is wide agreement among all the BIDI experts that have considered
this problem that a restriction of the combination of allowed characters
in each label is unavoidable independent of any other aspects of the
solution.

And you are right that there were two different main solutions,
and nobody was really sure which one to chose. But there was wide
agreement that a solution is needed.

The two main solutions differ in how they handle sequences of labels.

The solution described in draft-duerst-iri-bidi-00.txt tries to make
sure that the sequence of labels always goes the same way, left to right.
So something that is logically FTP.HEBREW.COM will show up as
PTF.WERBEH.MOC. In order for this to happen, special characters called
LRM have to be inserted around the '.'. It would be no problem check
for their presence and strip them in nameprep, but it is difficult
to have them inserted when typing a domain name in or when getting a
domain name back from a protocol.

The other solution, with which Mati Allouche has come up after
reading my draft in detail, is to give the sequences of labels
their 'natural' order. The above example would turn into
MOC.WERBEH.PTF. This may look very strange, but is actually
quite natural for native Arabic or Hebrew users, because that's
the way they read text. On various occasions that I have seen
examples of Arabic domain names, they were always displayed
that way.
It leads to a few strange effects, such as an inversion of
components of different nature in URIs
(example: http://ftp.HEBREW.COM/PATH/file.html turns into
http://ftp.HTAP/WERBEH.MOC/file.html), but these can be
read naturally as well. The main advantage is that it requires
less intervention/magic for input and for taking domain names
from a protocol and putting them into a textual context. This
is a big advantage.

Incidentally, it's also how at least some OS handles directory
paths. The only case I was able to confirm is (Japanese)
Windows 2000, where a folder ABCD (shows as DCBA) with a folder
EFGH (shows as HGFE) inside is shown as follows in the top
bar of the explorer:

D:\
D:\temp
D:\temp\DCBA
D:\temp\HGFE\DCBA

Looks really weird when you see it the first time, but bidirectional
writing comes with quite a few surprises.

Mark's proposal (just following) worked out the details of the
restrictions necessary for individual labels in order to work
with Mati's proposal. It's the best I know, and it's an
enormous improvement over just doing nothing at all and regretting
it later.


>>B. In any field that contains any RTL characters:
>>B0. no LTR characters can occur.
>>C1. a sequence of characters of type DIG can only occur at the end.
>>C2. a sequence of characters of type OTHER can occur only between 
>>characters of type RTL.
>>
>>I propose that this be added as an additional step after the current
>>'prohibition' step.
>
>Why would this be considered part of nameprep? That is, why are you 
>prohibiting the strings on the user side instead of on the server side?

As far as I understand, nameprep is for both sides. There is a single
difference, namely the treatment of unassigned codepoints, which go
through on the client side, but are checked on the server side (at
the time of registration). Except for this difference, both sides
are the same.

The reason for this, as far as I understand, is to make double sure
that no illegal things get into the DNS: If illegal names won't be
reachable from the client, there is no incentive for the registrars
to cheat.

Also, if this is handled as a 'policy' issue, different
registrations may choose to use different restriction policies
(if they become aware of the problem at all). This will
not work because it is then impossible to provide appropriate
support on the client side (browsers, mailers,...).


>This is the first time that the proposal has been seen by the WG.
>There is no Internet Draft

There is
http://www.ietf.org/internet-drafts/draft-duerst-iri-bidi-00.txt,
for the more general problem of bidi in URIs. The WG has been told
about it at http://www.imc.org/idn/mail-archive/msg03271.html.

And there is no need for a separate Internet Draft for DNS.
It should go into nameprep.


>and no examples of its use.

What kinds of examples are you looking for? More examples to explain
the issues? A list of examples that could be used for testing?
Examples for the draft itself? How many other examples are there
in the nameprep draft?


Regards,    Martin.



From owner-idn@ops.ietf.org  Tue Feb 12 10: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 KAA15753
	for ; Tue, 12 Feb 2002 10:46:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aevw-0007Ih-00
	for idn-data@psg.com; Tue, 12 Feb 2002 07:33:28 -0800
Received: from sina.sharif.ac.ir ([194.225.40.9] helo=sina.sharif.edu)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aevu-0007Hq-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 07:33:27 -0800
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 g1CFXHd18534;
	Tue, 12 Feb 2002 19:03:17 +0330
Received: from localhost (roozbeh@localhost)
	by bamdad.org (8.11.6/8.11.6) with ESMTP id g1CFf9103686;
	Tue, 12 Feb 2002 19:11:11 +0330
X-Authentication-Warning: gilas.bamdad.org: roozbeh owned process doing -bs
Date: Tue, 12 Feb 2002 19:11:09 +0330 (IRT)
From: Roozbeh Pournader 
X-X-Sender: roozbeh@gilas.bamdad.org
To: Martin Duerst 
cc: bidi@unicode.org, IDN 
Subject: [idn] Re: END OF AYAH vs NAMEPREP
In-Reply-To: <4.2.0.58.J.20020212205258.03c10650@localhost>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Tue, 12 Feb 2002, Martin Duerst wrote:

> You have a much better idea about END OF AYAH than I have.
> If you think it should not be part of IDN, then just
> propose to put it on the 'prohibited' list.

I don't know much if it should be part of IDN. There are many characters 
that are part of IDN and should be prohibited or ignored in my opinion.

But it was IDN's policy to prohibit control characters, and this character
may become a control character soon. This is what I was worrying about.

roozbeh




From owner-idn@ops.ietf.org  Tue Feb 12 11:03: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 LAA16383
	for ; Tue, 12 Feb 2002 11:03:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16afDW-0007my-00
	for idn-data@psg.com; Tue, 12 Feb 2002 07:51:38 -0800
Received: from kathmandu.sun.com ([192.18.98.36])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16afDV-0007ms-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 07:51:37 -0800
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09451;
	Tue, 12 Feb 2002 08:51:35 -0700 (MST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CFpXM09733;
	Tue, 12 Feb 2002 16:51:33 +0100 (MET)
Date: Tue, 12 Feb 2002 16:47:23 +0100 (CET)
From: Erik Nordmark 
Reply-To: Erik Nordmark 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
To: Kent Karlsson 
Cc: "'Erik Nordmark'" , idn@ops.ietf.org
In-Reply-To: "Your message with ID" <000401c1b3b9$75428560$b4e21081@chalmers95a69n>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> To make that workable, the basic table should be very restrictive
> and not allow any punctuation or symbols (other than full stops,
> and hyphen-like characters).  The latter can then be taken into
> use as either syntax around domain names or be included in
> certain other kinds of domain names than hostnames on a per
> punctation/symbol basis.

I understand that alternative.

> Going the other way around (as seems to be suggested by the
> authors), frezes at time of first deployment which
> punctuation/symbols can and cannot be used in future
> syntaxes that embed domain names.  In particular, the current
> suggestion *forbids* as special use (i.e. surrounding syntax or
> use in special purpose (non-host) domain names) any non-ASCII
> symbol/punctuation.

I don't understand this issue - stringprep is likely to be used for
many things that use Unicode and need ways to test for equality etc
and not all of these are domain names.
I think (but would gladly accept to be corrected) that the IPS use of
stringprep is intended to be for names of storage volumes (or something
like that).
Given that this intent exists your concern about freezing the set
of punctuation can't possibly be something that the people working
on non-host/domain name use of stringprep see as a problem.

> Even though e.g. [gg] and [g][g] (there are a few hundred other examples)
> are not canonically or compatibility equivalent, they still represent
> the same sequence of Hangul letters, and thus "mean" the same.

Yes, same argument is used for SC/TC needing to be addressed in IDN.

> Even though not all systems display the decompostions correctly yet,
> there is no reason to believe that that they will not be supported
> by most rendering engines for Hangul.  Unfortunately, the normal
> forms cannot be changed at this time, even though that would have
> been better.  There have been many misconceptions around about,
> e.g., where Hangul syllable break are, which may have lead
> to the current situation.  Once those misconceptions are cleared
> up, you will likely see more comments to the fact that [gg] and [g][g]
> (etc.!) are in fact equivalent from a Hangul perspective.

I still don't see why you think this adjustment/fix to Unicode is in scope
for IDN.

> > > 9. User interfaces that encounter mixed script hostname *parts*
> > > should be recommended to "flag" them (ballon warning, color
> > > differentiate, make blinking, bounce automatic 
> > registratations, ...).
> > 
> > By "*parts*" do you mean labels or something else?
> 
> stringprep: "DNS domain name parts";
> 
> idna: "A label is an individual part of a domain name";
> 
> nameprep: "This document describes how to prepare
> 	internationalized host name parts" (I think that's the
> 	wrong approach, e.g. it should apply to the entire name,
> 	but I'm just quoting for the term here.)

I didn't ask what semantics others assign to "parts" - I asked specifically
what you meant in your use of the term.

  Erik




From owner-idn@ops.ietf.org  Tue Feb 12 12:10: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 MAA18793
	for ; Tue, 12 Feb 2002 12:10:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ag9D-0009Jm-00
	for idn-data@psg.com; Tue, 12 Feb 2002 08:51:15 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ag9C-0009Jg-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 08:51:14 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55567 for idn@ops.ietf.org; Tue, 12 Feb 2002 10:50:37 -0600
Message-ID: <3C6947FF.D252D4A8@ehsco.com>
Date: Tue, 12 Feb 2002 10:51:11 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@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:
> 
> > Please list the RFC822 header fields that IDNA should be
> > transliterated versus the header fields that should not be
> > transliterated.
> 
> When an application is displaying header fields to the user, it should
> apply ToUnicode to domain labels found in domain name slots.  RFC 822
> defines the syntax of every header field, and some of those fields have
>  in their definition.  Those s are the domain name
> slots.  Anything else in the header is not a domain name slot.

Are you SURE you want to do this with Received? or rather, are you SURE
you want to mandate this behavior with Received on behalf of the other
communities, even though copy-and-paste with transliterated Received
headers will get ugly.

Does your list include all of those data-types which have domain names as
a subordinate element? I will assume that your list also includes "slots"
that hold email addresses since that is one of your other religious
doctrines, and since those hold domain names they are candidates.

Are URLs in header fields therefore also candidates? Are you SURE you want
to do this with List-* and Content-Location header fields?

Are message identifiers also candidates, since they are structured the
same as email addresses? Are you SURE you want to do this with Message-ID?

Sweeping rules that affect every instance of every domain name across
every network service in use on the Internet are absurd.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Tue Feb 12 12:56: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 MAA20190
	for ; Tue, 12 Feb 2002 12:56:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ah3z-000AjL-00
	for idn-data@psg.com; Tue, 12 Feb 2002 09:49:55 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ah3y-000AjF-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 09:49:54 -0800
Received: from iis.sinica.edu.tw (i2ot2 [140.109.21.154])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g1CHirT28530;
	Wed, 13 Feb 2002 01:44:53 +0800 (CST)
Message-ID: <3C695616.41C2B215@iis.sinica.edu.tw>
Date: Wed, 13 Feb 2002 01:51:18 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: DougEwell2@cs.com
CC: idn@ops.ietf.org, jseng@pobox.org.sg
Subject: Re: [idn] Interesting links
References: <153.8c70495.299a071b@cs.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Dear Dough,

As several members of the list tried to explain to the group, it is
very difficult to ask a user to enter a Chinese domain names exactly 
in a Unicode input environment. This is because the complexity of 
getting the exact domain name is exponential in the length of a 
domain name. In other words, if there are 10 characters with variants
in a domain name, then there are at least 1,024 different Unicode 
strings corresponding to the same name. It is frustrated for users to
deal with such a high complexity.

Nevertheless,  if ITEF  does approve an IDN technology which does
not solve the variant problem, we believe that there are domain name
holders who pays the registries. This is because they want to keep
their own name and, furthermore, IETF is a respectful organization.
It is going to take a while before they realize that technology is 
not ready.

As for the current system, we have been using it for so many years.
It would be excellent if we could live with domain names in our own 
language. But, it makes no harm even if we have to wait for some 
time before a reasonable solution is provided.

-- Janming Ho


DougEwell2@cs.com gJG

> In a message dated 2002-02-11 18:48:00 Pacific Standard Time,
> hoho@iis.sinica.edu.tw writes:
>
> > What happen in the WG will bring damage the
> > community.
>
> I keep seeing this word, "damage."
>
> Is it really true that providing domain names in Chinese characters, but
> requiring users to enter them exactly as presented (without TC/SC
> equivalencing), would be more damaging to the Chinese user community than the
> current system, which provides no support at all for Chinese characters?
>
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Tue Feb 12 12:57: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 MAA20229
	for ; Tue, 12 Feb 2002 12:57:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ah4o-000Am3-00
	for idn-data@psg.com; Tue, 12 Feb 2002 09:50:46 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ah4n-000Alx-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 09:50:45 -0800
Received: from [] (modemcable094.128-130-66.que.mc.videotron.ca [66.130.128.94])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1CIACa60923
	for ; Tue, 12 Feb 2002 13:10:12 -0500 (EST)
Date: Tue, 12 Feb 2002 12:50:12 -0500
From: Marc Blanchet 
To: idn@ops.ietf.org
Subject: [idn] WG last call period is now over
Message-ID: <413390000.1013536212@localhost>
X-Mailer: Mulberry/2.2.0b2 (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 MAA20229

Hi,
 The WG last call period is now over. The authors with the co-chairs will 
try to summarize the 400+ mails... Will take a few days ;-))

Marc.

------------------------------------------
Marc Blanchet
Viagnie
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 Feb 12 12:59: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 MAA20261
	for ; Tue, 12 Feb 2002 12:59:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ah1r-000AgY-00
	for idn-data@psg.com; Tue, 12 Feb 2002 09:47:43 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ah1q-000AgS-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 09:47:42 -0800
Received: from [] (modemcable094.128-130-66.que.mc.videotron.ca [66.130.128.94])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1CI78a60865
	for ; Tue, 12 Feb 2002 13:07:08 -0500 (EST)
Date: Tue, 12 Feb 2002 12:47:09 -0500
From: Marc Blanchet 
To: IETF idn working group 
Subject: Re: [idn] Few comments on idna
Message-ID: <411080000.1013536029@localhost>
In-Reply-To: <20020212064724.GM26818@nicemice.net>
References: <110820000.1013488872@localhost>
 <111160000.1013488892@localhost> <109960000.1013488820@localhost>
 <20020212064724.GM26818@nicemice.net>
X-Mailer: Mulberry/2.2.0b2 (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 MAA20261


-- mardi, fvrier 12, 2002 06:47:24 +0000 "Adam M. Costello" 
 wrote/a crit:

> Marc Blanchet  wrote:
>
>> here is few comments on idna.
>>
>> - 3. 2). "When requirements 1 and 2 both apply, requirement 1 takes
>> precedence".
>> + My understanding is the inverse: i.e. requirement 2 takes precedence.
>> I  might be wrong.
>
> You are wrong.  :)
>
> The ASCII form might be ugly, but software won't choke on it.  The
> non-ASCII form is pretty, but some software will choke on it, and that's
> more important.  So requirement 1 takes precedence.  It basically says
> don't pass non-ASCII domain names to software that might choke on it.

Well, I had a hard time to clearly understand those two paragraphs.
I'll try to come up with a suggestion on writing.

>
>> - 4.1 ToASCII and 4.2 ToUnicode
>> + the algorithm should more clearly state what happens when the "Verify
>> actions" result to fail.
>
> Section 4.1 says "ToASCII fails if any step of it fails.  Failure
> means that the original sequence cannot be used as a label in an IDN."
> Section 4.2 says "ToUnicode never fails.  If any step fails, then the
> original input sequence is returned immediately in that step."  How can
> we be any clearer?

I read those statements. But the way the steps are written, it is not clear 
what to do if verification fails. There is an implicit rule in what you 
wrote about the fact that you continue to the next step. I would add at the 
end of all verify steps a simple sentence to make it clearer. Something 
like: "If verification fails, exit".

>
>> - 6.1 Entry and display in applications.
>> "if it does, rendering the ACE SHOULD NOT be the default."
>> + we should make it clear that the prefix MUST be shown if the ACE
>> version is shown.  This is probably obvious for us, but the document
>> is not clear about the fact that when "ACE" is used, it means with
>> or without the prefix.
>
> Section 2 says "The 'ACE prefix' is defined in this document to be
> a string of ASCII characters that appears at the beginning of every
> ACE label." and "The conversion of labels to and from the ACE form is
> specified in section 4.", and in section 4 ToASCII is defined in such a
> way that ACE labels always begin with the ACE prefix.  Section 5 "ACE
> prefix" even gives an example:
>
>     For example, the eventual ACE prefix might be the string "jk--".
>     In this case, an ACE label might be "jk--r3c2a-qc902xs", where
>     "r3c2a-qc902xs" is the part of the ACE label that is generated by
>     the encoding steps in [PUNYCODE].
>
> I have a hard time imagining what would lead someone to think that "ACE"
> refers to the part after the prefix.  But if Patrik or Paul wants to
> make an editorial change emphasizing that, I don't see what harm it
> would cause.

I tried to "forget" about my "involvement" in idn and then read the drafts 
with an implementor perspective new to idn. With this twist, I found not 
clear where the prefix was implied, when it was not.

>
>> - title: Punycode version 0.3.3.
>> + the title should be changed to something like punycode version 1.0.
>
> Agreed.  In the next revision it will be 1.0.0.
>
>>  I would also argue to have a more descriptive name in the title,
>> something like: "Punycode: an encoding designed for use iwth
>> Internationalized Domain Names (idn)."
>
> Agreed.  How about "Punycode: An encoding of Unicode for use with IDNA"?
> (I think it's significant that it's for use with IDNA as opposed to IDN.
> I could expand IDNA if you like, but that would get very long.)

That would be much better at least than the current title.
I'm fine with your proposal.
However, I would expand the IDNA word (even if it costs extra bits...). 
Make things more clearer.

>
>> - Annex B.
>> + to me, this is not clear if it is mandatory to implement or not. We
>> should put a clear statement about this.
>
> The introduction says "Punycode can support an optional feature
> described in appendix B", and the third (== last) paragraph of appendix
> B is "Punycode encoders and decoders are not required to support these
> annotations, and higher layers need not use them."  Is that not clear
> enough?  Should I add a third such statement at the beginning of the
> appendix?  Or move the last paragraph to the beginning of the appendix
> (which means it would contain forward references)?


I don't know. I would probably add a sentence just after "Punycode can 
support ...", something like: "However, it MUST NOT be implemented for 
IDNA."

>
>> = Annex D.
>> + I would erase the first 8 lines in comments. The author is already
>> identified in the draft (author section).
>
> You would, but I wouldn't. :) The first thing most people are going to
> do with the sample code is save it to a .c file, and I want the version
> information to be kept with it, along with the URL pointing at possibly
> newer versions of the sample code.

The version will be freezed with the RFC number. i.e. the version of the 
code is the RFC number.

>
>> Also the numbering of the versions is inconsistent!!!.
>
> The sample code has its own version number.


well, the draft was more interesting than that: See:

title of the draft: "Punycode version 0.3.3"
then annex D:

/*
punycode.c 0.4.0 (2001-Nov-17-Sat)

/* This is ANSI C code (C89) implementing Punycode version 0.3.x. */


How relevent to a specification is the date you made the code?

> The version numbers of both
> the spec and the sample code will become 1.0.0 in the next revision,
> but they could diverge after that.  Editorial changes to the spec don't
> cause changes in the sample code.  Also, an interface change in the
> sample code could cause a large jump in the sample code version (to
> 1.1.0 or 2.0.0) while causing only a small jump in the spec version (to
> 1.0.1).

Again, the version now will be the RFC number.

I think your version numbering management is all fine for yourself. I don't 
think it is appropriate for an RFC.

I would suggest that you refer between your new versions of the code to the 
"Punycode version RFCXXXX". And leave the RFC "clean" of your internal 
numbering schemes.  For example, we don't put CVS tags in RFCs, even if 
they are useful for document management.

Marc.

>
> AMC
>



------------------------------------------
Marc Blanchet
Viagnie
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 Feb 12 15:28: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 PAA25191
	for ; Tue, 12 Feb 2002 15:28:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ajKb-000E0G-00
	for idn-data@psg.com; Tue, 12 Feb 2002 12:15:13 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ajKa-000E0A-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 12:15:12 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CKF8314643
	for ; Tue, 12 Feb 2002 12:15:09 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <20020212064724.GM26818@nicemice.net>
References: <110820000.1013488872@localhost>
 <111160000.1013488892@localhost> <109960000.1013488820@localhost>
 <20020212064724.GM26818@nicemice.net>
Date: Tue, 12 Feb 2002 12:10:58 -0800
To: IETF idn working group 
From: Paul Hoffman / IMC 
Subject: Re: [idn] Few comments on idna
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

>  > Also the numbering of the versions is inconsistent!!!.
>
>The sample code has its own version number.

Then you should say next to the version number what that version 
number is for. "This is code version foo, which matches Punycode 
specification version bar."

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Tue Feb 12 16:27: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 QAA28063
	for ; Tue, 12 Feb 2002 16:27:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16akLc-000FeU-00
	for idn-data@psg.com; Tue, 12 Feb 2002 13:20:20 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16akLb-000FeO-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 13:20:19 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16akLY-0001TN-00
	for ; Tue, 12 Feb 2002 13:20:16 -0800
Date: Tue, 12 Feb 2002 21:20:16 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020212212015.GA3881@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C6947FF.D252D4A8@ehsco.com> <20020212090900.13619.qmail@cr.yp.to>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[This message replies to both D. J. Bernstein and Eric A. Hall regarding
similar issues.]

"D. J. Bernstein"  wrote:

> > When an application is displaying header fields to the user,
> 
> Define your terminology.  How does a UNIX program figure out whether it
> is displaying something ``to the user''?

(To anyone who doesn't use UNIX:  We're talking about a program that
outputs text to standard output.  Standard output usually gets displayed
on a terminal emulator unless the user has redirected it to a file or
to the input of another program.  Some programs are intended to be
redirected and have human-unfriendly machine-friendly output.  Some are
intended to be viewed and have human-friendly machine-unfriendly output.
Some are somewhere in between, which motivates the question here.)

> Yes or no:  Should ``dig'' convert its results from your 7-bit
> encoding to the local character set? (Assume the LANG=en_US.UTF-8
> locale, so that the conversion is at least theoretically doable.)

Yes.  The second sentence of the man page for dig is "It performs DNS
lookups and displays the answers..."  Furthermore, the man page does
not specify the output format of dig, so the output does not contain
any domain name slots.  Clearly it's primary purpose is to display
information to humans, and any program that attempts to parse the output
of dig is assuming the risk that someday this undocumented output format
might change.

Any user clever enough to use dig and to use programs that
parse its output is probably also clever enough to prepend "env
LANG=en_US.US-ASCII" to the command line if necessary, or to use the
--no-idna option of dig that would almost surely have been added at the
same time IDNA support was added.

Another option for any application would be to have IDNA support
completely disabled by default, and enabled only at the user's request.

"Eric A. Hall"  wrote:

> > When an application is displaying header fields to the user, it should
> > apply ToUnicode to domain labels found in domain name slots.  RFC 822
> > defines the syntax of every header field, and some of those fields have
> >  in their definition.  Those s are the domain name
> > slots.  Anything else in the header is not a domain name slot.
> 
> Are you SURE you want to do this with Received?

Yes.

> or rather, are you SURE you want to mandate this behavior
> with Received on behalf of the other communities, even though
> copy-and-paste with transliterated Received headers will get ugly.

Novice users never even see Received headers.  Users who know enough to
request to see Received headers will also know enough to request ASCII
if they need it.

As for "mandate", keep in mind this sentence from the IDNA introduction:

    This document does not require any applications to conform to IDNA,
    but applications can elect to use IDNA in order to support IDN while
    maintaining interoperability with existing infrastructure.

If IDNA is more trouble than it's worth for particular applications,
those applications can just ignore it.

> Does your list include all of those data-types which have domain names
> as a subordinate element?

Yes.

> I will assume that your list also includes "slots" that hold email
> addresses

The list you requested was a list of header fields.  The list includes
header fields that contain , because  ultimately
contains a .  The  is the domain name slot.

> Are URLs in header fields therefore also candidates?

If a header field is defined to contain a URL, and the URL scheme
indicates that it contains a domain name, then that is a domain name
slot.

> Are you SURE you want to do this with List-* and Content-Location
> header fields?

Content-Location is an HTTP header field, and HTTP responses are not
normally displayed, but if an application wanted to display an HTTP
response, then it should display the non-ASCII form of the domain name
if it can (unless the user requests otherwise or special circumstances
make this problematic).

I don't know what List-* fields are, but if they are defined to contain
domain names, then it's the same story as Content-Location.

> Are message identifiers also candidates, since they are structured
> the same as email addresses?  Are you SURE you want to do this with
> Message-ID?

Same story as Received.

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 16:53: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 QAA28768
	for ; Tue, 12 Feb 2002 16:53:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16akgu-000G95-00
	for idn-data@psg.com; Tue, 12 Feb 2002 13:42:20 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16akgt-000G8y-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 13:42:19 -0800
Received: from chalmers95a69n (dynamic-193-202.dialup.chalmers.se [129.16.193.202])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1CLgDh09522;
	Tue, 12 Feb 2002 22:42:13 +0100 (MET)
From: "Kent Karlsson" 
To: "'Erik Nordmark'" 
Cc: 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Tue, 12 Feb 2002 22:39:15 +0100
Message-ID: <000301c1b40d$b8bfda00$0100007f@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


> > Going the other way around (as seems to be suggested by the
> > authors), frezes at time of first deployment which
> > punctuation/symbols can and cannot be used in future
> > syntaxes that embed domain names.  In particular, the current
> > suggestion *forbids* as special use (i.e. surrounding syntax or
> > use in special purpose (non-host) domain names) any non-ASCII
> > symbol/punctuation.
> 
> I don't understand this issue - stringprep is likely to be used for
> many things that use Unicode and need ways to test for equality etc
> and not all of these are domain names.

Yes, sorry for sayin "domain" there.

> I think (but would gladly accept to be corrected) that the IPS use of
> stringprep is intended to be for names of storage volumes (or 
> something like that).

In the scenario I suggest, "volume names", "file names", or even 
programming language identifers should be able to use a tailoring
of a common talbe (that carries most of the data).  Things like
case fold or not case fold should be made easy to express in a
tailoring (delta).


> Given that this intent exists your concern about freezing the set
> of punctuation can't possibly be something that the people working
> on non-host/domain name use of stringprep see as a problem.

"freezing the set of punctuation"?  Where did I say or imply that?
What I said was that punctuation should be disallowed by the default
(but some, selectively, punctuation may be allowed by a delta/tailoring).




> > Even though e.g. [gg] and [g][g] (there are a few hundred other examples)
> > are not canonically or compatibility equivalent, they still represent
> > the same sequence of Hangul letters, and thus "mean" the same.
> 
> Yes, same argument is used for SC/TC needing to be addressed in IDN.

No, no, no!!  This issue is comparable to the *canonical* equivalences
that already exist for Hangul syllable characters, and for other 
characters that have a canonical decomposition (some "double latin
letters" have compatibility decompositions, but the relationship here
is much stronger; and it is much much stronger than case insensitivity).
Unfortunately, due to historic events, that equivalence is no longer
recorded in Unicode 3.0 and later property data.

This is in no way comparable to the SC/TC issue which is a spelling
preference issue, where the "spellings" are actually different.
Here it is just about the underlying representation for the **same**
spelling (in terms of sequence of letters; there is not even any
case difference or font variant difference [for correctly constructed
fonts that cover Hangul]).

> > Even though not all systems display the decompostions correctly yet,
> > there is no reason to believe that that they will not be supported
> > by most rendering engines for Hangul.  Unfortunately, the normal
> > forms cannot be changed at this time, even though that would have
> > been better.  There have been many misconceptions around about,
> > e.g., where Hangul syllable break are, which may have lead
> > to the current situation.  Once those misconceptions are cleared
> > up, you will likely see more comments to the fact that [gg] 
> > and [g][g] (etc.!) are in fact equivalent from a Hangul perspective.
> 
> I still don't see why you think this adjustment/fix to 
> Unicode is in scope for IDN.

Since it can no longer be corrected by changing the normalisation
forms, just about everything else has to do the correction instead.


> > > > 9. User interfaces that encounter mixed script hostname *parts*
> > > > should be recommended to "flag" them (ballon warning, color
> > > > differentiate, make blinking, bounce automatic 
> > > registratations, ...).
> > > 
> > > By "*parts*" do you mean labels or something else?
> > 
> > stringprep: "DNS domain name parts";
> > 
> > idna: "A label is an individual part of a domain name";
> > 
> > nameprep: "This document describes how to prepare
> > 	internationalized host name parts" (I think that's the
> > 	wrong approach, e.g. it should apply to the entire name,
> > 	but I'm just quoting for the term here.)
> 
> I didn't ask what semantics others assign to "parts" - I 
> asked specifically
> what you meant in your use of the term.

The quotes motivated not only how, but why I used that term.
Except for the definition in the idna document, why don't
you complain when others use the same term without definition?

Suggestion: All the documents should include a sufficiently
complete "definitions of terms" clause, where all technical
terms are defined in a dictionary like format (not with the
term inlined into a paragraph).

		Kind regards
		/kent k


>   Erik
> 




From owner-idn@ops.ietf.org  Tue Feb 12 17:25: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 RAA29454
	for ; Tue, 12 Feb 2002 17:25:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16alGp-000GwZ-00
	for idn-data@psg.com; Tue, 12 Feb 2002 14:19:27 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16alGo-000GwT-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 14:19:26 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55652 for idn@ops.ietf.org; Tue, 12 Feb 2002 16:18:49 -0600
Message-ID: <3C6994EA.B4D87EC6@ehsco.com>
Date: Tue, 12 Feb 2002 16:19:23 -0600
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 interoperability failures, once again
References: <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <20020212212015.GA3881@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:

> > Are you SURE you want to do this with Received?
> 
> Yes.

> Novice users never even see Received headers.  Users who know enough to
> request to see Received headers will also know enough to request ASCII
> if they need it.

Spam complaints are the common example of normal users seeing received
header fields, when they are copied and pasted into complaint messages,
the encoded representation (your default) will be what's sent.
Administrators blocking sender domains are the common example of advanced
users seeing domains. In many cases (such as ISP mail systems) the only
view to this information will be through a web UI.

Nowhere in your specification does it state that encoded and non-encoded
views of a domain name should be provided. Do you plan on adding this,
since you won't back away from the claim that it is safe to mandate the
automatic transliteration of ACE sequences?

> > Are you SURE you want to do this with List-* and Content-Location
> > header fields?
> 
> Content-Location is an HTTP header field, and HTTP responses are not
> normally displayed, but if an application wanted to display an HTTP
> response, then it should display the non-ASCII form of the domain name
> if it can (unless the user requests otherwise or special circumstances
> make this problematic).

> I don't know what List-* fields are, but if they are defined to contain
> domain names, then it's the same story as Content-Location.

Content-Location is a MIME header field (see RFC 2557). The List-* header
fields defined in RFC 2369 provide URLs for common list-management
functions. The point of this question is to see if you would dive in and
embrace transliteration of URLs as well, which you seem to think is also a
good idea. Have you documented the use of i18n domain names in URLs
somewhere? I mean, as hard as some of your peers argued against this very
issue, I'm surprised that you're inviting it without any sort of
documentation for review.

> > Are message identifiers also candidates, since they are structured
> > the same as email addresses?  Are you SURE you want to do this with
> > Message-ID?
> 
> Same story as Received.

Message-ID values are frequently referenced in multiple locations, not all
of which are in structured fields. By allowing them to be transliterated
for display, you are inviting them to be converted. This is, in turn,
implicitly expanding the structured header fields that will allow them.

For example, I have cited previous messages by Message-ID throughout this
very thread, and your default interpretation would have made it so that
those values were only seen (and therefore copied and pasted) in their
encoded form. In conjunction with a SeeAlso header field or a RFC822-style
References header field, this would not only mean that I was now
generating illegal header fields but that I was poisoning the entire
thread and every copy of those messages (including archives), AND THIS
WOULD BE ENTIRELY DUE TO YOUR DEFAULT MANDATE.

In short, mandates such as this one encourage bleed-over inside of
structured data-formats, ACCELERATE ENTROPY ON THE INTERNET. That this is
all being done without any documentation on the affected elements, without
any viable justification whatsoever (supporting the promise of your
religious text is not viable justification), and without any authority
over the affected network services is the very paragon of opinioneering
and absurdity.

> As for "mandate", keep in mind this sentence from the IDNA
> introduction:
> 
>   This document does not require any applications to conform to IDNA,
>   but applications can elect to use IDNA in order to support IDN while
>   maintaining interoperability with existing infrastructure.
> 
> If IDNA is more trouble than it's worth for particular applications,
> those applications can just ignore it.

Then why are you defending it? Declare IDNA as a method for encoding i18n
domain names into an ASCII-compatible encoding, step away from the foolery
of mandating its use with everything that looks like a domain name, and
leave the integration work to the governing bodies that actually have the
authority, expertise and bandwidth to deal with the associated issues.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Tue Feb 12 18:05: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 SAA00291
	for ; Tue, 12 Feb 2002 18:05:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16altK-000HbL-00
	for idn-data@psg.com; Tue, 12 Feb 2002 14:59:14 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16altJ-000HbF-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 14:59:13 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16altJ-0001kb-00
	for ; Tue, 12 Feb 2002 14:59:13 -0800
Date: Tue, 12 Feb 2002 22:59:13 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] a few more comments on the last call documents
Message-ID: <20020212225912.GC3881@nicemice.net>
Reply-To: IETF idn working group 
References: <111160000.1013488892@localhost> <109960000.1013488820@localhost> <20020212064724.GM26818@nicemice.net>  <110820000.1013488872@localhost> <111160000.1013488892@localhost> <109960000.1013488820@localhost> <20020212064724.GM26818@nicemice.net> <411080000.1013536029@localhost> <000301c1b3b5$3cea6010$b4e21081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:  <411080000.1013536029@localhost> <000301c1b3b5$3cea6010$b4e21081@chalmers95a69n>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[This message contains responses to Kent Karlsson, Marc Blanchet, and
Paul Hoffman.]

Kent Karlsson  wrote:

>  "...SHOULD show the name in ACE format... This is to make is to make
>  it easier to transfer the name correctly to other programs"; cut and
>  paste works very well also for strings that contain characters not
>  in the font used at the moment, using an ACE display will be more of
>  problem than help.

It depends on the platform and the GUI.  Sometimes copy/paste retrieves
a string from the application, but sometimes it just retrieves a string
from the GUI corresponding to exactly what is displayed.  Maybe the
language in the draft should be sensitive to this.

> There should be opening for transition to a long-term non-ACE solution
> (probably based on UTF-8).

The draft already says:

    If a signalling 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.

> The ACE based solution should be explicitly declared to be short-term.

No, because the draft then says:

    The question whether or not this should be used is, however, a
    separate problem and is not discussed in this memo.

Marc Blanchet  wrote:

> > How about "Punycode: An encoding of Unicode for use with IDNA"?
> 
> I would expand the IDNA word (even if it costs extra bits...). 

Okay.

> I would probably add a sentence just after "Punycode can support ...",
> something like: "However, it MUST NOT be implemented for IDNA."

A Punycode encoder/decoder that implements mixed-case annotation will
behave exactly the same as a Punycode encoder/decoder that does not
implement mixed-case annotation, except that the encoder can accept
flags and the decoder can return flags.  But those flags don't alter
the output of the encoder except for the case of ASCII letters (which
doesn't matter for domain labels), and they don't alter the sequence of
code points returned by the decoder at all.  So there is no reason to
forbid the Punycode encoder/decoder from implementing this feature.

I will, however, add explicit language to that effect:

    Mixed-case annotation MUST NOT alter the encoder output as defined
    in section 6.3 except for affecting the case of ASCII letters, and
    mixed-case annotation MUST NOT alter the sequence of code points
    returned by the decoder as defined in section 6.2.

> The version will be freezed with the RFC number. i.e. the version of
> the code is the RFC number.

It's possible that I might continue to develop the code after the RFC is
published.  For example, I might make stylistic changes or add comments
or slightly change the interface.  Those later versions of the sample
code won't appear in an RFC, so they'll need their own version number,
and it will be nice if the sample code in the RFC has a version number
that can be compared with the version number in the more recent sample
code.

> title of the draft: "Punycode version 0.3.3"
> then annex D:
> 
> /*
> punycode.c 0.4.0 (2001-Nov-17-Sat)
> 
> /* This is ANSI C code (C89) implementing Punycode version 0.3.x. */

What's wrong with that?  Version 0.4.0 of punycode.c implements version
0.3.anything of Punycode.  I can use a wildcard like that because all
0.3.x versions are equivalent, with only editorial differences.

> How relevent to a specification is the date you made the code?

It's not, but the the date is relevant to the code itself.  We are
embedding a file inside a document, and that file contains its version
number and date stamp.

> I think your version numbering management is all fine for yourself. I
> don't think it is appropriate for an RFC.

Lots of RFCs have version numbers:

RFC-1950 ZLIB compressed data format specification version 3.3
RFC-1951 DEFLATE compressed data format specification version 1.3
RFC-1952 GZIP file format specification version 4.3
RFC-2060 Internet Message Access Protocol - version 4rev1
RFC-2246 The TLS protocol version 1.0
RFC-2437 PKCS #1: RSA cryptography specifications version 2.0
RFC-2616 Hypertext Transfer Protocol -- HTTP/1.1

Paul Hoffman / IMC  wrote:

> Then you should say next to the version number what that version
> number is for. "This is code version foo, which matches Punycode
> specification version bar."

Okay, I'll make that more clear.

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 18:54: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 SAA01089
	for ; Tue, 12 Feb 2002 18:54:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16amfT-000IgE-00
	for idn-data@psg.com; Tue, 12 Feb 2002 15:48:59 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16amfQ-000Ig6-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 15:48:58 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16amfQ-0001sK-00
	for ; Tue, 12 Feb 2002 15:48:56 -0800
Date: Tue, 12 Feb 2002 23:48:56 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020212234856.GD3881@nicemice.net>
Reply-To: IETF idn working group 
References: <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <20020212212015.GA3881@nicemice.net> <3C6994EA.B4D87EC6@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C6994EA.B4D87EC6@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> Nowhere in your specification does it state that encoded and
> non-encoded views of a domain name should be provided.

IDNA section 6.1 says:

    Because name labels encoded as ACE name labels can be rendered
    either as the encoded ASCII characters or the proper decoded
    characters, the application MAY have an option for the user to
    select the preferred method of display;

If there is a demand for this ability, applications will tend to provide
it.

> Have you documented the use of i18n domain names in URLs somewhere?

IDNA.  It documents how to use IDNs anywhere you can use regular domain
names.

> In conjunction with a SeeAlso header field or a RFC822-style
> References header field, this would not only mean that I was now
> generating illegal header fields

I don't know what a SeeAlso header field is.  A References header field
contains a list of s and s, which can be distinguished
syntactically because the s begin and end with angle brackets
while the s do not.  If the mail program is IDNA-compliant, then
when it constructs the References field (or when it checks the field
that the user has suggested) it obeys IDNA section 3 requirement 1 and
makes sure that the s inside the s are ASCII-only (it
can apply ToASCII if needed).

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 18:56: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 SAA01115
	for ; Tue, 12 Feb 2002 18:56:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16amfh-000IgW-00
	for idn-data@psg.com; Tue, 12 Feb 2002 15:49:13 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16amfg-000IgQ-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 15:49:12 -0800
Received: (qmail 17329 invoked by uid 1001); 12 Feb 2002 23:43:59 -0000
Date: 12 Feb 2002 23:43:59 -0000
Message-ID: <20020212234359.7250.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: IETF idn working group 
Subject: Re: [idn] IDNA interoperability failures, once again
References: <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Adam M. Costello writes:
> "D. J. Bernstein"  wrote:
> > Yes or no:  Should ``dig'' convert its results from your 7-bit
> > encoding to the local character set? (Assume the LANG=en_US.UTF-8
> > locale, so that the conversion is at least theoretically doable.)
> Yes.

That will cause interoperability failures. It will break other programs,
even though those programs are fully compliant with today's standards.
Mail will bounce!

Costello persists in claiming that IDNA will allow IDNs to be deployed
right now _without_ any failures other than incorrect displays. That
claim is simply not true. Mail will bounce. Web links will fail.

If IDNA's special-purpose 7-bit encoding is supported by _no_ networking
programs, or (in a fully Unicode world) by _all_ networking programs,
then mail won't bounce. In the intermediate stage, when the encoding is
supported by _some_ networking programs, mail will bounce.

> Any user clever enough to use dig and to use programs that
> parse its output is probably also clever enough to prepend "env
> LANG=en_US.US-ASCII" to the command line if necessary,

Costello is weaseling.

He is saying that mail won't bounce _if_ the program invoking dig (in
this case, a shell script) is changed _before_ the dig program is
changed. But the IDNA specification does not impose any such ordering.
Costello wants the dig authors to change their code right now.

More importantly, there _does not exist_ an ordering compatible with all
of today's cross-program data transfers. Addresses are copied from mail
programs to browsers; addresses are also copied from browsers to mail
programs.

> the man page does not specify the output format of dig

Actually, the dig manual page clearly states that dig prints answers
from name servers. There is only one printed DNS record format in BIND,
namely BIND's zone-file format, which is documented in detail and meant
to be machine-parsed.

The format is very badly engineered---it requires far too much effort to
parse completely---but that's a side issue. The point is that programs
_do_ read it.

In fact, the current dig man page explicitly mentions at one point that,
to simplify machine parsing, dig avoids one feature of the format by
default. Costello is simply wrong when he claims that the dig output is
meant only for display and that programs shouldn't be looking at it.

> Some programs are intended to be
> redirected and have human-unfriendly machine-friendly output.  Some are
> intended to be viewed and have human-friendly machine-unfriendly output.
> Some are somewhere in between, which motivates the question here.

The line that Costello is attempting to draw is directly contrary to the
UNIX philosophy. UNIX programs are _designed_ to be ``in between.''

This is explained in detail in Gancarz's book. Here, for example, is an
excerpt from the ``Make Every Program A Filter'' section:

   When you assume that the receptacle of a program's data flow might be
   another program instead of a human being, you eliminate those biases
   we all have in trying to make an application user friendly. You stop
   thinking in terms of menu choices and start looking at the possible
   places your data may eventually wind up. Try not to focus inward on
   what your program can do. Look instead at where your program may go.
   You'll then begin to see the much larger picture of which your
   program is a part.

These ideas are most fully developed in UNIX, but they can also be seen
in other operating systems, in tools ranging from copy-and-paste to
object-linking frameworks. Some of these tools have a side channel for
character-set information, but most of them are designed for a world
with a unified character encoding---ASCII yesterday, UTF-8 tomorrow.

The bottom line is that the ``dig'' problem is shared by _thousands_ of
UNIX programs. They deliberately provide output in a format that can be
viewed by the user, or sent to another program, or both.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Tue Feb 12 20:20: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 UAA02474
	for ; Tue, 12 Feb 2002 20:20:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ansz-000KQg-00
	for idn-data@psg.com; Tue, 12 Feb 2002 17:07:01 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ansy-000KQa-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 17:07:00 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55674 for idn@ops.ietf.org; Tue, 12 Feb 2002 19:06:23 -0600
Message-ID: <3C69BC31.EB0F7B1C@ehsco.com>
Date: Tue, 12 Feb 2002 19:06:57 -0600
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 interoperability failures, once again
References: <20020211041601.GB14664@nicemice.net> <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <20020212212015.GA3881@nicemice.net> <3C6994EA.B4D87EC6@ehsco.com> <20020212234856.GD3881@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:

> > Have you documented the use of i18n domain names in URLs somewhere?
> 
> IDNA.  It documents how to use IDNs anywhere you can use regular domain
> names.

With all of the authority and justification afforded to the authors by the
IETF and W3C, no doubt.

> > In conjunction with a SeeAlso header field or a RFC822-style
> > References header field, this would not only mean that I was now
> > generating illegal header fields
> 
> I don't know what a SeeAlso header field is.  A References header field
> contains a list of s and s, which can be distinguished
> syntactically because the s begin and end with angle brackets
> while the s do not.

Ok, let's go there (sticking with 822 for context):

 | msg-id      =  "<" addr-spec ">"
 | addr-spec   =  local-part "@" domain
 | domain      =  sub-domain *("." sub-domain)
 | sub-domain  =  domain-ref / domain-literal
 | domain-ref  =  atom
 | atom        =  1*
 | CHAR        =          ; (  0-177,  0.-127.)

As we can see, a Message-ID header field that includes decoded output from
an ACE-encoded IDN is not a valid Message-ID.

Although you may believe that this data-type only has relevant definition
when it is encapsulated within an email message, I can assure you that the
data-type is used in several locations, and that the values will come and
go in and out of messages. Yes, a messaging application should check
before it accepts the value, but it should also check before it
TRANSLITERATES THE ENCODED VALUE. The DEFAULT behavior should be to NEVER
GENERATE THE DECODED OUTPUT.

IDNA provides a encoding of an i18n domain name which is safe for transfer
within the Message-ID header field. That is all. It is not safe for
anything to transliterate the encoded sequence. You must not encourage
such foolishness with a "requirement".

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Tue Feb 12 20:23: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 UAA02532
	for ; Tue, 12 Feb 2002 20:23:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16anzq-000KZd-00
	for idn-data@psg.com; Tue, 12 Feb 2002 17:14:06 -0800
Received: from smtp21.singnet.com.sg ([165.21.101.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16anzp-000KZX-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 17:14:05 -0800
Received: from jamessonyvaio (tns00648.singnet.com.sg [165.21.185.118])
	by smtp21.singnet.com.sg (8.12.2/8.12.2) with SMTP id g1D1Dx6n024334;
	Wed, 13 Feb 2002 09:13:59 +0800
Message-ID: <09aa01c1b42b$c9d4e290$cfc615a5@jamessonyvaio>
From: "James Seng/Personal" 
To: "D. J. Bernstein" , 
References: <20020211.093423.-412797.0.liana.ydisg@juno.com> <77460165.1013438681@localhost> <20020211211343.24889.qmail@cr.yp.to> <2279566.1013466535@localhost> <20020211214855.11426.qmail@cr.yp.to> <2677666.1013502136@localhost> <20020212083747.24793.qmail@cr.yp.to>
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Wed, 13 Feb 2002 09:10:30 +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 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: 7bit

Dan,

It is my responsibility to remind you of your language in the group.

Disagreement is okay. Arguments over technical point is typical. But
lets keep it away from ad hominem attack.

-James Seng

----- Original Message -----
From: "D. J. Bernstein" 
To: 
Sent: Tuesday, February 12, 2002 4:37 PM
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)


> Patrik writes:
> > You just asked for "certain mappings and no others".
>
> Liar. I started by quoting two lines from Klensin saying that TC/SC
was
> ``not analogous to case-mapping.'' I then quoted Seng's TC/SC
response,
> and said ``This answer destroys the stated reasons for case-mapping.''
>
> > I don't understand where you get "lying" from?
>
> I attribute your behavior to malice because it cannot be adequately
> explained by stupidity. It is simply not possible to read my message
> without observing that I was talking about case-mapping.
>
> This is not the first time that you have blatantly misrepresented the
> statements of people who object to IDNA.
>
> I have heard, by the way, that some of your company's products are not
> 8-bit-clean: in particular, they fail to handle UTF-8 transparently.
Is
> this true? Your position on the IESG gives you substantial power to
> elevate your company's interests above the interests of the community;
> you have a clear conflict of interest if you are making decisions on
> proposals that affect your company's products.
>
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
>







From owner-idn@ops.ietf.org  Tue Feb 12 21:17: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 VAA03676
	for ; Tue, 12 Feb 2002 21:17:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aopH-000Lhc-00
	for idn-data@psg.com; Tue, 12 Feb 2002 18:07:15 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aopG-000LhT-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 18:07:14 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1D26wR06064;
	Wed, 13 Feb 2002 11:06:59 +0900
Message-ID: <100b01c1b433$0fd9ac60$2b19fea9@temp>
From: "Soobok Lee" 
To: "Kent Karlsson" ,
        "'Erik Nordmark'" 
Cc: 
References: <000301c1b40d$b8bfda00$0100007f@chalmers95a69n>
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Date: Wed, 13 Feb 2002 11:06:32 +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

Thanks, Kent.

----- Original Message ----- 
From: "Kent Karlsson" 
 > 
> > > Even though e.g. [gg] and [g][g] (there are a few hundred other examples)
> > > are not canonically or compatibility equivalent, they still represent
> > > the same sequence of Hangul letters, and thus "mean" the same.
> > 
> > Yes, same argument is used for SC/TC needing to be addressed in IDN.
> 
> No, no, no!!  This issue is comparable to the *canonical* equivalences
> that already exist for Hangul syllable characters, and for other 
> characters that have a canonical decomposition (some "double latin
> letters" have compatibility decompositions, but the relationship here
> is much stronger; and it is much much stronger than case insensitivity).
> Unfortunately, due to historic events, that equivalence is no longer
> recorded in Unicode 3.0 and later property data.
> 
> This is in no way comparable to the SC/TC issue which is a spelling
> preference issue, where the "spellings" are actually different.
> Here it is just about the underlying representation for the **same**
> spelling (in terms of sequence of letters; there is not even any
> case difference or font variant difference [for correctly constructed
> fonts that cover Hangul]).
> 


True. the canonical equivalence between [gg] and [g][g] is defined in the
unicode 3.0 . They should have been unified by NFC, but haven't correctly.

Too late to be changed. and It should be solved in new normalizatio forms.
But If applications use the new normalization before nameprep,
As i warned  in the last call comments, the following condition will be
 trigerred silently,

  stringprep(newnormalization(Hangul)) != stringprep(Hangul) 

If stringprep would be neutral to new normalization adopted by applications,
 stringprep should be perfect and inclusive of all kinds of mature normaliztions,
that is,  the universal set of all kinds of normalizations built upon unicode.
Impossible?

Applications implementors should be cautious when applying normalizations forms
to data/texts portions that contain IDN. If some applications already adopted some
normalizations forms that are not compatible to stringprep as above,
backward compatibility requirements are not met in that case.
IDNA's backward compatibility claim doesn't come without costs.

Don't build our grand castle on the moving sand dune, on which a tiny tent is more adequate
and wise choice. :-)

Soobok Lee
 




From owner-idn@ops.ietf.org  Tue Feb 12 21:37: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 VAA05022
	for ; Tue, 12 Feb 2002 21:37:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16apDh-000MHx-00
	for idn-data@psg.com; Tue, 12 Feb 2002 18:32:29 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16apDg-000MHq-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 18:32:28 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16apDf-0002Dy-00
	for ; Tue, 12 Feb 2002 18:32:27 -0800
Date: Wed, 13 Feb 2002 02:32:27 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020213023227.GA8158@nicemice.net>
Reply-To: IETF idn working group 
References: <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C69BC31.EB0F7B1C@ehsco.com> <20020212234359.7250.qmail@cr.yp.to>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[This message contains responses to D. J. Bernstein and Eric A. Hall
regarding related issues.]

"D. J. Bernstein"  wrote:

> > the man page does not specify the output format of dig
>
> Actually, the dig manual page clearly states that dig prints answers
> from name servers.  There is only one printed DNS record format in
> BIND, namely BIND's zone-file format, which is documented in detail
> and meant to be machine-parsed.

I don't see any mention of RFC 1035 or "master file" or "zone file" in
the dig man page, but let's go ahead and suppose that the output format
of dig is indeed the RFC 1035 master file format.

In that case, IDNA section 3 requirement 1 *prohibits* dig from
outputing the non-ASCII form of domain names.  So there's no problem,
mail does not bounce, the sky does not fall.

"Eric A. Hall"  wrote:

> As we can see, a Message-ID header field that includes decoded output
> from an ACE-encoded IDN is not a valid Message-ID.

Exactly right.  Therefore RFC-822 compliant mail programs will not put
non-ASCII domain names in a Message-ID field.  An RFC-822 compliant
program faced with the task of putting a non-ASCII domain name into a
Message-ID field will call ToASCII if it's IDNA-aware, otherwise it will
have no option left but to return an error to whatever handed it the
non-ASCII domain name.  It was the calling program's error for passing
a non-ASCII domain name to a non-IDNA-aware program, or it was a human
error for piping data into a program that doesn't understand the data
format.

As in the dig example, any program with a well-defined pre-existing
output format that includes domain names is prohibited by IDNA from
outputting the non-ASCII form (unless it redefines the output format).
But if the program does not define its output format, then making
assumptions about the output format (like assuming that it won't change
in the next version) is an inherently risky business, and people who
write scripts that pipe such output into other programs are deliberately
choosing to take that risk.  (I'm not saying they shouldn't write
such scripts, just that they should accept responsibility for the
consequences of their unfounded assumptions.)

AMC



From owner-idn@ops.ietf.org  Tue Feb 12 23:01: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 XAA07196
	for ; Tue, 12 Feb 2002 23:01:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aqVJ-000O2E-00
	for idn-data@psg.com; Tue, 12 Feb 2002 19:54:45 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aqVI-000O28-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 19:54:44 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55694 for idn@ops.ietf.org; Tue, 12 Feb 2002 21:54:07 -0600
Message-ID: <3C69E381.1B7A554D@ehsco.com>
Date: Tue, 12 Feb 2002 21:54:41 -0600
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 interoperability failures, once again
References: <3C6836CE.8A77B0CE@ehsco.com> <20020212020050.GA26818@nicemice.net> <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <20020213023227.GA8158@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:
> 
> [This message contains responses to D. J. Bernstein and Eric A. Hall
> regarding related issues.]

Please stop doing that, we are on about two totally different things.

> "Eric A. Hall"  wrote:
> 
> > As we can see, a Message-ID header field that includes decoded output
> > from an ACE-encoded IDN is not a valid Message-ID.
> 
> Exactly right.  Therefore RFC-822 compliant mail programs will not put
> non-ASCII domain names in a Message-ID field.

You have completely missed the point. Message-ID is unique in that it
provides a serial number for a message. The decoded output for a
Message-ID header field MUST NEVER be presented, since it would be a
functionally different identifier whenever it was used. For example,
searching Google or an IMAP server for all of the messages associated with
the Message-ID of nn@zz--gobbledygook is completely different than
searching for a Message-ID of nn@. Shall all such services be
upgraded to suit IDNA, even though many of these operations take place
outside of RFC [2]822 data-space?

The problem of pollution will also happen despite any mandate to the
contrary. This will most noticably occur with email addresses, where an
address is copied from say Pine to Hotmail; note that 2047 pollution also
occurs in this way, but since 2047 doesn't pollute the actual address, it
isn't actually fatal. You can say that applications shouldn't do that and
I'd agree with you. The secondary point is that we shouldn't be knocking
these applications over in the first place.

Regardless, I'm tired of chasing down your escape clauses. The idea that
you can somehow dictate a "requirement" (your word) that applications
SHOULD (your word) rewrite domain names regardless of functionality or
form is absurd. You have only ever had one option here, which is to defer
any and all such processing to those groups which actually define and
control those specifications. As much as you would like to believe
otherwise, you have zero authority to impose such behavior on anybody or
anything. Encouraging it is completely irresponsible. Until you remove
that requirement, this spec is broken. Period.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Tue Feb 12 23:02: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 XAA07208
	for ; Tue, 12 Feb 2002 23:01:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aqX5-000O50-00
	for idn-data@psg.com; Tue, 12 Feb 2002 19:56:35 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16aqX4-000O4e-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 19:56:34 -0800
Received: (qmail 28073 invoked by uid 1001); 13 Feb 2002 03:55:31 -0000
Date: 13 Feb 2002 03:55:31 -0000
Message-ID: <20020213035531.13155.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: IETF idn working group 
Subject: Re: [idn] IDNA interoperability failures, once again
References: <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Adam M. Costello flip-flops:
> In that case, IDNA section 3 requirement 1 *prohibits* dig from
> outputing the non-ASCII form of domain names. So there's no problem,

The problem, of course, is that your so-called ``internationalized
domain names'' are being presented to the user as gobbledygook.

Let's try another example: the ``show'' program in the UNIX MH/NMH
mail-handling system. Yes or no: Should this program convert domain
names from your special-purpose 7-bit character set to the local
character set? Again assume LANG=en_US.UTF-8, so this can be done.

Your newly invented ``well-defined pre-existing output format''
criterion says that ``show'' is not allowed to convert. But this means
that MH/NMH users, such as Keith Moore, will see gobbledygook instead of
IDNs.

How is Keith Moore supposed to see IDNs displayed properly in his email?
Let's assume that he has the current version of X, with Unicode fonts
and a UTF-8 xterm. Where exactly are your PunyCode IDNs converted to
UTF-8? Which programs do the conversion?

You keep dodging these questions because you know that any conversion
will trigger interoperability failures. The output that you think is
going to a user may actually be going to another program that does a
domain-name lookup without knowing anything about IDNA. Kaboom.

(To forestall any ``check for a tty'' weaseling: Programs such as Emacs
and Expect will give you a tty anyway; and tools such as copy-and-paste
are on the other side of xterm's tty.)

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Wed Feb 13 00:11: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 AAA08993
	for ; Wed, 13 Feb 2002 00:11:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ard7-000PPc-00
	for idn-data@psg.com; Tue, 12 Feb 2002 21:06:53 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ard6-000PPW-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 21:06:52 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16ard5-0002wz-00
	for ; Tue, 12 Feb 2002 21:06:51 -0800
Date: Wed, 13 Feb 2002 05:06:51 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020213050651.GC8158@nicemice.net>
Reply-To: IETF idn working group 
References: <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <20020213023227.GA8158@nicemice.net> <3C69E381.1B7A554D@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C69E381.1B7A554D@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> The decoded output for a Message-ID header field MUST NEVER be
> presented, since it would be a functionally different identifier
> whenever it was used.  For example, searching Google or an IMAP
> server for all of the messages associated with the Message-ID of
> nn@zz--gobbledygook is completely different than searching for a
> Message-ID of nn@.

I might also search for a From: field, or a To: field.  In fact, I can
search Google for pretty much anything.  So therefore all ACE labels
MUST NEVER be decoded.  Wonderful.

> you have zero authority to impose such behavior on anybody or
> anything.

Right, as IDNA section 1 says, "This document does not require any
applications to conform to IDNA..."

I think this thread has probably outlasted its usefulness, but you are
welcome to have the last word.

AMC



From owner-idn@ops.ietf.org  Wed Feb 13 01:08: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 BAA11513
	for ; Wed, 13 Feb 2002 01:08:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16asQz-0000OO-00
	for idn-data@psg.com; Tue, 12 Feb 2002 21:58:25 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16asQy-0000OG-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 21:58:24 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 1E6698F2
	for ; Wed, 13 Feb 2002 14:57:54 +0900 (JST)
Message-Id: <4.2.0.58.J.20020213145015.0402b938@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Wed, 13 Feb 2002 14:53:42 +0900
To: IETF idn working group 
From: Martin Duerst 
Subject: URIs and IDN (was: Re: [idn] IDNA interoperability failures,
  once again)
In-Reply-To: <20020212234856.GD3881@nicemice.net>
References: <3C6994EA.B4D87EC6@ehsco.com>
 <20020211041601.GB14664@nicemice.net>
 <3C6836CE.8A77B0CE@ehsco.com>
 <20020212020050.GA26818@nicemice.net>
 <3C68936E.602B7B7@ehsco.com>
 <20020212061019.GL26818@nicemice.net>
 <3C68B8BB.8E49A530@ehsco.com>
 <20020212071810.GO26818@nicemice.net>
 <20020212090900.13619.qmail@cr.yp.to>
 <20020212212015.GA3881@nicemice.net>
 <3C6994EA.B4D87EC6@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 23:48 02/02/12 +0000, Adam M. Costello wrote:
>"Eric A. Hall"  wrote:

> > Have you documented the use of i18n domain names in URLs somewhere?
>
>IDNA.  It documents how to use IDNs anywhere you can use regular domain
>names.

Upgrading URIs consistent with URI guidelines and internationalization
is described in:

http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-01.txt

Regards,     Martin.



From owner-idn@ops.ietf.org  Wed Feb 13 01:08: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 BAA11526
	for ; Wed, 13 Feb 2002 01:08:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16asQy-0000OH-00
	for idn-data@psg.com; Tue, 12 Feb 2002 21:58:24 -0800
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16asQx-0000OA-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 21:58:23 -0800
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201])
	by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP
	id 00E72E01; Wed, 13 Feb 2002 14:57:49 +0900 (JST)
Message-Id: <4.2.0.58.J.20020213144513.04000608@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Wed, 13 Feb 2002 14:48:37 +0900
To: "Eric A. Hall" ,
        IETF idn working group 
From: Martin Duerst 
Subject: Re: [idn] IDNA interoperability failures, once again
In-Reply-To: <3C69BC31.EB0F7B1C@ehsco.com>
References: <20020211041601.GB14664@nicemice.net>
 <3C6836CE.8A77B0CE@ehsco.com>
 <20020212020050.GA26818@nicemice.net>
 <3C68936E.602B7B7@ehsco.com>
 <20020212061019.GL26818@nicemice.net>
 <3C68B8BB.8E49A530@ehsco.com>
 <20020212071810.GO26818@nicemice.net>
 <20020212090900.13619.qmail@cr.yp.to>
 <20020212212015.GA3881@nicemice.net>
 <3C6994EA.B4D87EC6@ehsco.com>
 <20020212234856.GD3881@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 19:06 02/02/12 -0600, Eric A. Hall wrote:

>"Adam M. Costello" wrote:
>
> > > Have you documented the use of i18n domain names in URLs somewhere?
> >
> > IDNA.  It documents how to use IDNs anywhere you can use regular domain
> > names.
>
>With all of the authority and justification afforded to the authors by the
>IETF and W3C, no doubt.

Disclaimer, just to make sure:

The IDN WGs' work, including IDNA, is done in the IETF. W3C does not
'afford' any authority or justification to this work.

Regards,    Martin.

#-#-#  Martin J. Du"rst, I18N Activity Lead, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org/People/D%C3%BCrst



From owner-idn@ops.ietf.org  Wed Feb 13 02:28: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 CAA21423
	for ; Wed, 13 Feb 2002 02:28:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16atiD-000206-00
	for idn-data@psg.com; Tue, 12 Feb 2002 23:20:17 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16atiD-000200-00
	for idn@ops.ietf.org; Tue, 12 Feb 2002 23:20:17 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 55707 for idn@ops.ietf.org; Wed, 13 Feb 2002 01:19:40 -0600
Message-ID: <3C6A13AD.327412B@ehsco.com>
Date: Wed, 13 Feb 2002 01:20:14 -0600
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 interoperability failures, once again
References: <3C68936E.602B7B7@ehsco.com> <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <20020213023227.GA8158@nicemice.net> <3C69E381.1B7A554D@ehsco.com> <20020213050651.GC8158@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:

> therefore all ACE labels MUST NEVER be decoded.  Wonderful.

At last you see the light. IDNA has one single function, which is that it
provides a backwards compatible encoding. That's it.

Supporting internationalized domain names requires that the applications,
protocols and formats, like, ADD SUPPORT FOR internationalized domain
names. A real shocker, I know!

If you want UTF-8 output treated as normal, guess what you need to use for
the normalized input form. C'mon, it should be easy.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Wed Feb 13 03:23: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 DAA23046
	for ; Wed, 13 Feb 2002 03:23:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16aubt-0003Gw-00
	for idn-data@psg.com; Wed, 13 Feb 2002 00:17:49 -0800
Received: from imo-d04.mx.aol.com ([205.188.157.36])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16aubs-0003Gq-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 00:17:48 -0800
Received: from DougEwell2@cs.com
	by imo-d04.mx.aol.com (mail_out_v32.5.) id i.191.22f0f4f (24895);
	Wed, 13 Feb 2002 03:16:43 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <191.22f0f4f.299b7ae6@cs.com>
Date: Wed, 13 Feb 2002 03:16:38 EST
Subject: Re: [idn] Interesting links
To: idn@ops.ietf.org, hoho@iis.sinica.edu.tw
CC: jseng@pobox.org.sg
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-02-12 9:50:11 Pacific Standard Time, 
hoho@iis.sinica.edu.tw writes:

> Dear Dough,

Hmm, I guess it really is difficult to type names correctly.  :-)

> As several members of the list tried to explain to the group, it is
> very difficult to ask a user to enter a Chinese domain names exactly 
> in a Unicode input environment. This is because the complexity of 
> getting the exact domain name is exponential in the length of a 
> domain name. In other words, if there are 10 characters with variants
> in a domain name, then there are at least 1,024 different Unicode 
> strings corresponding to the same name. It is frustrated for users to
> deal with such a high complexity.

Continuing to talk about 1,024 variants is unrealistic and is causing you to 
lose credibility, because

(1) the vast majority of Chinese domain names (in all surveys and in existing 
testbeds) are, and will be, much shorter than 10 Han characters, and

(2) a significant percentage of Han characters do not exist in TC/SC pairs.

If you consider a CDN that is, much more realistically, 6 characters in 
length, and 4 of those 6 characters can be expressed as either TC or SC, then 
you have 2^4 = 16 possible variants.  Now, it may well be that registering 16 
names is an unreasonable burden.  I am not saying that there is no problem at 
all.  But it does no good to exaggerate the problem by claiming that it will 
cause THOUSANDS of variants of a typical domain name.

-Doug Ewell
 Fullerton, California
 (address will soon change to dewell at adelphia dot net)



From owner-idn@ops.ietf.org  Wed Feb 13 04:43: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 EAA24797
	for ; Wed, 13 Feb 2002 04:43:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16avsL-0004wO-00
	for idn-data@psg.com; Wed, 13 Feb 2002 01:38:53 -0800
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16avsK-0004wH-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 01:38:52 -0800
Received: from zetnet.co.uk (bts-0400.dialup.zetnet.co.uk [194.247.49.144])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g1D9cWh16263;
	Wed, 13 Feb 2002 09:38:32 GMT
Message-ID: <3C68D7C3.4804E93@zetnet.co.uk>
Date: Tue, 12 Feb 2002 08:52:19 +0000
From: David Hopwood 
Reply-To: unicode@unicode.org
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: unicode@unicode.org, idn@ops.ietf.org
Subject: [idn] Normalisation and case folding (was: IDNA comment)
References: <0c1f01c1b31a$b8b9caf0$2b19fea9@temp> <004101c1b31d$7ecd45d0$08d8ea0c@c1340594a>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

[Cross-posted from the IDN list; reply-to set to unicode@unicode.org.
Change it back for replies that relate specifically to IDN.]

Mark Davis wrote:
> >stringprep(NFC(x)) == stringprep(x) [does not always hold]
> 
> This was brought up early in the Unicode 3.2 development. We have
> programmatically checked, and I with dot is the only case that causes
> a problem.

No it isn't:

    NFD(toCasefold("\u1FB2"))
        = NFD("\u1F70\u03B9")       = "\u03B1\u0300\u03B9" (alpha-varia, iota)
    NFD(toCasefold("\u1FB3\u0300"))
        = NFD("\u03B1\u03B9\u0300") = "\u03B1\u03B9\u0300" (alpha, iota-varia)

(Which NF is used after toCasefold isn't important.)

What algorithm did you use to check this? In any case, I'll discuss case
folding in part 3 of my Unicode 3.2 comments, later today.

> I have no doubt that it will be resolved for U3.2, and even if StringPrep
> doesn't pick up U3.2, it could add a mapping to that one case.

How would you add a mapping from a sequence of two characters (e.g.
"I\u0307"), without changing the stringprep/nameprep algorithm, rather
than the tables?

(Actually there is an indirect way to do it: map out U+0307, and map all
composed characters with dot-above to the forms without dot-above. However,
that won't work for the standard case folding algorithm, because it would
break consistency with earlier versions, and it doesn't fix the problem
with Greek ypogegrammeni/prosgegrammeni, anyway.)

- -- 
David Hopwood 

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPGjXmzkCAxeYt5gVAQFj1wgAiC4pPi3sJqK6uhOdXrigiUi85QMds7+o
LRgvpGldJ1l+LmuTh7PHqlq/rW5A+mvq/Usm0Gj9rZK0ALyc1i6nKvCN1hUPTGEA
cnCGR24aCqXa1aBNVEDT2FfY4QlJqiRBNjPxncMm3Od6SA3EN0cI76jUTXgk3YxV
S/Ffd2eszm3jy4qeBIkgkXhul7mKxonwdzmGggGLxAj25RNbzzoBAiGmtH2NQn/C
IZExFrQjFXGNwLQ7wjhbRSs1nWwRYP0OcJIHEACSWcf/tYu+opLB6Dcq3ZXAk20y
P4a/c8KvryTd6ZF7d+8sV3x4yCzEh5PzPjgeYRqv0lbAMCsO3bTasw==
=pR5H
-----END PGP SIGNATURE-----





From owner-idn@ops.ietf.org  Wed Feb 13 04:48: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 EAA24852
	for ; Wed, 13 Feb 2002 04:48:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16avwf-00051c-00
	for idn-data@psg.com; Wed, 13 Feb 2002 01:43:21 -0800
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16avwe-00051V-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 01:43:20 -0800
Received: from zetnet.co.uk (bts-0400.dialup.zetnet.co.uk [194.247.49.144])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g1D9hHh18063
        for ; Wed, 13 Feb 2002 09:43:18 GMT
Message-ID: <3C68DF04.4E8539B1@zetnet.co.uk>
Date: Tue, 12 Feb 2002 09:23:16 +0000
From: David Hopwood 
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: Re: [idn] stringprep comment 6:  casefold and then noramlization is not 
 enough
References: <0c5701c1b31e$ecb4d7b0$2b19fea9@temp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

Soobok Lee wrote:
> As I and David Hopwood suggested in the list,
> 
>   NFC(casefold(x)) or NFKC(casefold(x)) are not correct for 
> and .

I suggest that the detail of this should be discussed on the
unicode@unicode.org list.

Suffice it to say that it would be irresponsible to proceed with publication
of the stringprep or nameprep draft just yet. I intend to propose a
replacement for stringprep/nameprep that is simpler, more efficient, and
that takes account of all the comments that have been made (including
Hangul normalisation, BiDi, and spoofing, but excluding TC/SC).

> The steps for preparing strings are:
> 
> 1) Map -- For each character in the input, check if it has a mapping
> and, if so, replace it with its mapping. This is described in Section 4.
> 
> 2) Normalize -- Possibly normalize the result of step 1 using Unicode
> normalization. This is described in Section 5.
> 
> 3) Look for prohibited output -- Check for any characters that are not
> allowed in the output. If any are found, return an error. This is
> described in Section 6.
> 
> The above steps MUST be performed in the order given to comply with this
> specification."
> 
> Please suggest a proof that this last enforcement is necessary and sufficient.
> 
> I suggest the last "MUST" be changed to "MAY".

That would make the problem worse.

- -- 
David Hopwood 

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPGjdHTkCAxeYt5gVAQGZYAgAgqrqFmiuTM2USjJjXftsZp0OaaZcQ9u3
/zhL726xNoOCdBrdt416WRt9tpLlvbVHQfHWceSdC7fukmaA+fHJZYxSzD5ZE3B7
Aw/fZwjoMAfjVCmTJXwq/++4HNdfr6sNgNJTM/ekJj+jDhIMmFqQ/bTqgts1d5Z0
XrkMco+yxqN0sJbol+goRZDknZNvE2xF0KUl6IAACHxnYwKttdXTWRf2KCEU4p4n
Gb/pZDBjUWdrYs7U77YhivpmJgQVMjYHHJGCmnM8DNfYah8Kab1wy2y94hwM/yo7
pwAwZIqQWj08v2odJK64tibO6ilzv7YcQ9qEcfgr474qUY/VEguH1w==
=qUyj
-----END PGP SIGNATURE-----



From owner-idn@ops.ietf.org  Wed Feb 13 05:50: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 FAA26514
	for ; Wed, 13 Feb 2002 05:50:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16awnp-0006Ay-00
	for idn-data@psg.com; Wed, 13 Feb 2002 02:38:17 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16awno-0006As-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 02:38:16 -0800
Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1DAcFh11936
	for ; Wed, 13 Feb 2002 11:38:15 +0100 (MET)
From: "Kent Karlsson" 
To: "'IETF idn working group'" 
Subject: RE: [idn] a few more comments on the last call documents
Date: Wed, 13 Feb 2002 11:35:12 +0100
Message-ID: <000901c1b47a$1ed0e160$d5d61081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20020212225912.GC3881@nicemice.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


> Kent Karlsson  wrote:
> 
> >  "...SHOULD show the name in ACE format... This is to make 
> is to make
> >  it easier to transfer the name correctly to other 
> programs"; cut and
> >  paste works very well also for strings that contain characters not
> >  in the font used at the moment, using an ACE display will 
> be more of
> >  problem than help.
> 
> It depends on the platform and the GUI.  Sometimes copy/paste 
> retrieves
> a string from the application, 

Correct behaviour.

> but sometimes it just retrieves a string
> from the GUI corresponding to exactly what is displayed.

Any such system/application is SEVERELY FLAWED.  What is displayed
is glyphs.  In many cases there is no (uniquely) corresponding character.
For example (taking a Latin script example) an fj-ligature glyph,
or a Brahmic script ligature glyph, or a sequence of (positioned,
as all glyphs) subglyphs.  Or consider a BIDI string, correctly displayed.

I'd suggest NOT taking such severely flawed implementations into account.

		Kind regards
		/kent k




From owner-idn@ops.ietf.org  Wed Feb 13 05:55: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 FAA26684
	for ; Wed, 13 Feb 2002 05:55:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16awn9-00069q-00
	for idn-data@psg.com; Wed, 13 Feb 2002 02:37:35 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16awn8-00069W-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 02:37:34 -0800
Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1DAbWh11916
	for ; Wed, 13 Feb 2002 11:37:32 +0100 (MET)
From: "Kent Karlsson" 
To: "'IETF idn working group'" 
Subject: RE: [idn] Last call comments to nameprep/stringprep: BIDI
Date: Wed, 13 Feb 2002 11:34:29 +0100
Message-ID: <000801c1b47a$0561cd70$d5d61081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4.2.0.58.J.20020213140350.03fd6eb0@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Forwarding to the list; I was just checking offline with Martin
that I had not misapplied (my informal notion of) the BiDi
algorithm in my head...

> -----Original Message-----
> From: Martin Duerst [mailto:duerst@w3.org]
> Sent: den 13 februari 2002 06:04
> To: Kent Karlsson
> Subject: RE: [idn] Last call comments to nameprep/stringprep: BIDI
> 
> 
> You are right!   Thanks,   Martin.
> 
> At 14:58 02/02/12 +0100, you wrote:
> 
> 
> > > It leads to a few strange effects, such as an inversion of
> > > components of different nature in URIs
> > > (example: http://ftp.HEBREW.COM/PATH/file.html turns into
> > > http://ftp.HTAP/WERBEH.MOC/file.html), but these can be
> >
> >Should that not be http://ftp.HTAP/MOC.WERBEH/file.html?
> >
> >                 Kind regards
> >                 /kent k
> 



From owner-idn@ops.ietf.org  Wed Feb 13 06:02: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 GAA26885
	for ; Wed, 13 Feb 2002 06:02:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16awvl-0006MP-00
	for idn-data@psg.com; Wed, 13 Feb 2002 02:46:29 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16awvk-0006MJ-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 02:46:28 -0800
Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1DAkOh12296;
	Wed, 13 Feb 2002 11:46:24 +0100 (MET)
From: "Kent Karlsson" 
To: "'Marc Blanchet'" ,
        "'IETF idn working group'" 
Subject: RE: [idn] Few comments on idna
Date: Wed, 13 Feb 2002 11:43:21 +0100
Message-ID: <000a01c1b47b$424d8c00$d5d61081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <411080000.1013536029@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> > Agreed.  How about "Punycode: An encoding of Unicode for use with IDNA"?

In the UTR 17 model, Punycode is a "Transfer Encoding Syntax" (TES),

A few other things are TESes: UTF-7, MIME/QP, MIME/BASE64, GB/HZ,
and also the syntaxes \uhhhh of Java/C and &#xhhhhh; of XML.

I would not simply refer to Punycode as an "encoding", as to many
that would suggest that it was a Character Encoding Scheme or
Character Encoding Form.


		Kind regards
		/kent k

PS
This comment does NOT mean that I endorse or even in the tiniest way
support Punycode, QP, or HZ.  For IDNs, I still favour using UTF-8.




From owner-idn@ops.ietf.org  Wed Feb 13 06:48: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 GAA27984
	for ; Wed, 13 Feb 2002 06:48:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16axke-0007T8-00
	for idn-data@psg.com; Wed, 13 Feb 2002 03:39:04 -0800
Received: from [211.218.145.194] (helo=postel3.postel.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16axkc-0007Sz-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 03:39:02 -0800
Received: from MASTER ([61.82.180.15])
	by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g1DBbmR09962;
	Wed, 13 Feb 2002 20:37:49 +0900
Message-ID: <114401c1b482$d028d690$2b19fea9@temp>
From: "Soobok Lee" 
To: "David Hopwood" , 
References: <0c5701c1b31e$ecb4d7b0$2b19fea9@temp> <3C68DF04.4E8539B1@zetnet.co.uk>
Subject: Re: [idn] stringprep comment 6:  casefold and then noramlization is not  enough
Date: Wed, 13 Feb 2002 20:37:26 +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: "David Hopwood" 
To: 
Sent: Tuesday, February 12, 2002 6:23 PM
Subject: Re: [idn] stringprep comment 6: casefold and then noramlization is not enough


> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Soobok Lee wrote:
> > As I and David Hopwood suggested in the list,
> > 
> >   NFC(casefold(x)) or NFKC(casefold(x)) are not correct for 
> > and .
> 
> I suggest that the detail of this should be discussed on the
> unicode@unicode.org list.
> 
> Suffice it to say that it would be irresponsible to proceed with publication
> of the stringprep or nameprep draft just yet. 

I agree.

> I intend to propose a
> replacement for stringprep/nameprep that is simpler, more efficient, and
> that takes account of all the comments that have been made (including
> Hangul normalisation, BiDi, and spoofing, but excluding TC/SC).

Cheers!  I will help you  anytime if you want my aids. :-)


> 
> > The steps for preparing strings are:
> > 
> > 1) Map -- For each character in the input, check if it has a mapping
> > and, if so, replace it with its mapping. This is described in Section 4.
> > 
> > 2) Normalize -- Possibly normalize the result of step 1 using Unicode
> > normalization. This is described in Section 5.
> > 
> > 3) Look for prohibited output -- Check for any characters that are not
> > allowed in the output. If any are found, return an error. This is
> > described in Section 6.
> > 
> > The above steps MUST be performed in the order given to comply with this
> > specification."
> > 
> > Please suggest a proof that this last enforcement is necessary and sufficient.
> > 
> > I suggest the last "MUST" be changed to "MAY".
> 
> That would make the problem worse.

Maybe. It's clear that many changes should be made.
As suggested by many contributers, *more steps* should be introduced and interposed.

Soobok Lee
 




From owner-idn@ops.ietf.org  Wed Feb 13 09:49: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 JAA05461
	for ; Wed, 13 Feb 2002 09:49:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b0b6-000Bgm-00
	for idn-data@psg.com; Wed, 13 Feb 2002 06:41:24 -0800
Received: from attila.bofh.it ([213.92.8.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b0b6-000Bgg-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 06:41:24 -0800
Received: by attila.bofh.it (Postfix, from userid 10)
	id 94CB860B57; Wed, 13 Feb 2002 15:41:21 +0100 (CET)
Received: by wonderland.linux.it (Postfix/Md, from userid 1001)
	id D2049340B9; Wed, 13 Feb 2002 15:41:12 +0100 (CET)
Date: Wed, 13 Feb 2002 15:41:12 +0100
From: "Marco d'Itri" 
To: idn@ops.ietf.org
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020213144112.GA2327@wonderland.linux.it>
References: <20020212061019.GL26818@nicemice.net> <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net> <20020213035531.13155.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020213035531.13155.qmail@cr.yp.to>
User-Agent: Mutt/1.3.27i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Feb 13, "D. J. Bernstein"  wrote:

 >Let's try another example: the ``show'' program in the UNIX MH/NMH
 >mail-handling system. Yes or no: Should this program convert domain
 >names from your special-purpose 7-bit character set to the local
 >character set? Again assume LANG=en_US.UTF-8, so this can be done.
This assumption is wrong. Most people whose primary language is not
english do not use Unicode and UTF-8 as their native character set but
some national charset like ISO-8859-1 or KOI8-R.
You may not like it, but the native character set for most people is not
UTF-8 and they will not switch to UTF-8 just to use IDN because they
would not be able to see accented letters in their plain text documents,
in email or usenet articles generated by broken microsoft software and
everywhere else a not identified charset is used.

I just looked at /usr/share/doc/locales/SUPPORTED.gz in my Debian
GNU/Linux workstation and the locales for which UTF-8 is not a second
choice are:

ar_IN
en_IN
fa_IR.UTF-8
hi_IN.UTF-8
mr_IN.UTF-8
ta_IN
te_IN
ur_PK 

md@wonderland:pts/0:~$zcat /usr/share/doc/locales/SUPPORTED.gz | sed -e 's/[\. @].*//' | sort | uniq | wc -l
    132
md@wonderland:pts/0:~$

Some locales may be missing, but 8 of 132 locales are not enough to
justify your assertion that everybody should just use UTF-8.

-- 
ciao,
Marco



From owner-idn@ops.ietf.org  Wed Feb 13 14:47: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 OAA18863
	for ; Wed, 13 Feb 2002 14:47:00 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b52w-000CTp-00
	for idn-data@psg.com; Wed, 13 Feb 2002 11:26:26 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b52v-000CTi-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 11:26:25 -0800
Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1DI5lh06214;
	Wed, 13 Feb 2002 19:05:48 +0100 (MET)
From: "Kent Karlsson" 
To: "'Mark Davis'" , "'Soobok Lee'" ,
        "'Erik Nordmark'" 
Cc: "'Jungshik Shin'" , 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Wed, 13 Feb 2002 19:02:43 +0100
Message-ID: <000301c1b4b8$a34b7ca0$d5d61081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <005501c1b4a3$8b55f5e0$08d8ea0c@c1340594a>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA18863



> -----Original Message-----
...
> The Unicode consoritium debated making the canonical decomposition
> from  to  for a long time. The deciding feedback was from
> the Korean national body at the Seoul SC2/WG2 meeting, where they said
> it should not be done; that it was akin to canonically decomposing "w"
> to "vv". 

With all due respect, I don't think that is the correct analysis.  The
original alphabet consisted of 17 consonant and 11 vowels, none of them
"double" per se (later complemented with a few variants, no longer in
use). Using doubled consonants for particular sounds is very much like
using doubled consonants in the Latin script, even though the phonemic
differences are of a different nature.  Yes, the doubled consonants
in Hangul collate as separate entities, but that is a consequence of
the general approach of collating by consonants cluster (and vowels
cluster; irrespective of how that is achieved technically; Mark and
I have had a long debate about the latter...).

If [g][g] and [gg] really are different, how would [g][g] and [gg] be
differentiated within properly typeset Hangul syllable blocks?


> They also objected to combinations like  being
> canonically decomposed, principally so that modern syllables could
> always be decomposed into 3 pieces. 

And why would that be essential?  Especially since some of them still
decompose into two pieces...  Hangul is a very elegant writing system,
but its computer encoding is far from elegant, I'm sorry to say, even
though a subset remains very elegant.  However that subset interacts
with the rest when normalising, and the normalisation is not complete
(different normal forms for the same (logical) sequence of letters).


> The (weaker) compatibility
> decompositions in Unicode until the time that NFC was formed; those
> were removed because they would have prevented the formation of Hangul
> Syllables in NFKC.

No, but them being compatibility instead of canonical decompositions
prevented the *preservation* of Hangul syllable characters in NFKC.

It is not the first time we hear that that would be a syllable
break between two consecutive lead consonants, or between a lead
consonant and a Hangul syllable character, even though that
has never, AFAICT, been the case in Unicode.  It is not unlikely
that the misconception of spurious syllable breaks has lead astray.


		Kind regards
		/kent k




From owner-idn@ops.ietf.org  Wed Feb 13 14:48: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 OAA18897
	for ; Wed, 13 Feb 2002 14:47:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b5B6-000CoB-00
	for idn-data@psg.com; Wed, 13 Feb 2002 11:34:52 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b5B4-000Co1-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 11:34:52 -0800
Received: from iis.sinica.edu.tw (i2ot0 [140.109.21.152])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g1DFV8T23211;
	Wed, 13 Feb 2002 23:31:08 +0800 (CST)
Message-ID: <3C6A8862.B8FA18E5@iis.sinica.edu.tw>
Date: Wed, 13 Feb 2002 23:38:10 +0800
From: hoho 
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: DougEwell2@cs.com
CC: idn@ops.ietf.org, jseng@pobox.org.sg
Subject: Re: [idn] Interesting links
References: <191.22f0f4f.299b7ae6@cs.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Sorry, Doug,

When you mentioned the two numbers 4 and 6, I think you are talking about the
average number of characters and average number of characters with variants per
label. However,  a domain name is composed of several labels. Let's consider your

example. Then, a domain name would contain more than 10 characters each with at
least two different codepoints in Unicode as long as it contains 3 labels. You
see,
this is exactly the case in which we have more than 1,024 equivalent Chinese
domain
names.

-- Janming


DougEwell2@cs.com gJG

> In a message dated 2002-02-12 9:50:11 Pacific Standard Time,
> hoho@iis.sinica.edu.tw writes:
>
> > Dear Dough,
>
> Hmm, I guess it really is difficult to type names correctly.  :-)
>
> > As several members of the list tried to explain to the group, it is
> > very difficult to ask a user to enter a Chinese domain names exactly
> > in a Unicode input environment. This is because the complexity of
> > getting the exact domain name is exponential in the length of a
> > domain name. In other words, if there are 10 characters with variants
> > in a domain name, then there are at least 1,024 different Unicode
> > strings corresponding to the same name. It is frustrated for users to
> > deal with such a high complexity.
>
> Continuing to talk about 1,024 variants is unrealistic and is causing you to
> lose credibility, because
>
> (1) the vast majority of Chinese domain names (in all surveys and in existing
> testbeds) are, and will be, much shorter than 10 Han characters, and
>
> (2) a significant percentage of Han characters do not exist in TC/SC pairs.
>
> If you consider a CDN that is, much more realistically, 6 characters in
> length, and 4 of those 6 characters can be expressed as either TC or SC, then
> you have 2^4 = 16 possible variants.  Now, it may well be that registering 16
> names is an unreasonable burden.  I am not saying that there is no problem at
> all.  But it does no good to exaggerate the problem by claiming that it will
> cause THOUSANDS of variants of a typical domain name.
>
> -Doug Ewell
>  Fullerton, California
>  (address will soon change to dewell at adelphia dot net)




From owner-idn@ops.ietf.org  Wed Feb 13 15:01: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 PAA19242
	for ; Wed, 13 Feb 2002 15:01:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b5KZ-000DAG-00
	for idn-data@psg.com; Wed, 13 Feb 2002 11:44:39 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b5KZ-000DA8-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 11:44:39 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJiZ329416
	for ; Wed, 13 Feb 2002 11:44:35 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: 
In-Reply-To: <000301c1b4b8$a34b7ca0$d5d61081@chalmers95a69n>
References: <000301c1b4b8$a34b7ca0$d5d61081@chalmers95a69n>
Date: Wed, 13 Feb 2002 11:43:44 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 7:02 PM +0100 2/13/02, Kent Karlsson wrote:
>  > The Unicode consoritium debated making the canonical decomposition
>>  from  to  for a long time. The deciding feedback was from
>>  the Korean national body at the Seoul SC2/WG2 meeting, where they said
>>  it should not be done; that it was akin to canonically decomposing "w"
>>  to "vv".
>
>With all due respect, I don't think that is the correct analysis.

It seems a tad inappropriate for the IETF to consider not only going 
against the Unicode standard but *also* against the desires of the 
Korean national body to ISO because of the desires of a small number 
of people who are neither representatives of standards bodies or the 
national governments that are most interested in the script in 
question.


--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Wed Feb 13 16:10: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 QAA20771
	for ; Wed, 13 Feb 2002 16:10:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b6Yx-000FZC-00
	for idn-data@psg.com; Wed, 13 Feb 2002 13:03:35 -0800
Received: from rwcrmhc51.attbi.com ([204.127.198.38])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b6Yw-000FZ6-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 13:03:35 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020213152923.TMAL2566.rwcrmhc51.attbi.com@c1340594a>;
          Wed, 13 Feb 2002 15:29:23 +0000
Message-ID: <005501c1b4a3$8b55f5e0$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "Soobok Lee" , "Kent Karlsson" ,
        "'Erik Nordmark'" 
Cc: 
References: <000301c1b40d$b8bfda00$0100007f@chalmers95a69n> <100b01c1b433$0fd9ac60$2b19fea9@temp>
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Date: Wed, 13 Feb 2002 07:31:44 -0800
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

The Unicode consoritium debated making the canonical decomposition
from  to  for a long time. The deciding feedback was from
the Korean national body at the Seoul SC2/WG2 meeting, where they said
it should not be done; that it was akin to canonically decomposing "w"
to "vv". They also objected to combinations like  being
canonically decomposed, principally so that modern syllables could
always be decomposed into 3 pieces. The (weaker) compatibility
decompositions in Unicode until the time that NFC was formed; those
were removed because they would have prevented the formation of Hangul
Syllables in NFKC.

Mark
—————

Γνῶθι σαυτόν — Θαλῆς
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Soobok Lee" 
To: "Kent Karlsson" ; "'Erik Nordmark'"

Cc: 
Sent: Tuesday, February 12, 2002 18:06
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep


> Thanks, Kent.
>
> ----- Original Message -----
> From: "Kent Karlsson" 
>  >
> > > > Even though e.g. [gg] and [g][g] (there are a few hundred
other examples)
> > > > are not canonically or compatibility equivalent, they still
represent
> > > > the same sequence of Hangul letters, and thus "mean" the same.
> > >
> > > Yes, same argument is used for SC/TC needing to be addressed in
IDN.
> >
> > No, no, no!!  This issue is comparable to the *canonical*
equivalences
> > that already exist for Hangul syllable characters, and for other
> > characters that have a canonical decomposition (some "double latin
> > letters" have compatibility decompositions, but the relationship
here
> > is much stronger; and it is much much stronger than case
insensitivity).
> > Unfortunately, due to historic events, that equivalence is no
longer
> > recorded in Unicode 3.0 and later property data.
> >
> > This is in no way comparable to the SC/TC issue which is a
spelling
> > preference issue, where the "spellings" are actually different.
> > Here it is just about the underlying representation for the
**same**
> > spelling (in terms of sequence of letters; there is not even any
> > case difference or font variant difference [for correctly
constructed
> > fonts that cover Hangul]).
> >
>
>
> True. the canonical equivalence between [gg] and [g][g] is defined
in the
> unicode 3.0 . They should have been unified by NFC, but haven't
correctly.
>
> Too late to be changed. and It should be solved in new normalizatio
forms.
> But If applications use the new normalization before nameprep,
> As i warned  in the last call comments, the following condition will
be
>  trigerred silently,
>
>   stringprep(newnormalization(Hangul)) != stringprep(Hangul)
>
> If stringprep would be neutral to new normalization adopted by
applications,
>  stringprep should be perfect and inclusive of all kinds of mature
normaliztions,
> that is,  the universal set of all kinds of normalizations built
upon unicode.
> Impossible?
>
> Applications implementors should be cautious when applying
normalizations forms
> to data/texts portions that contain IDN. If some applications
already adopted some
> normalizations forms that are not compatible to stringprep as above,
> backward compatibility requirements are not met in that case.
> IDNA's backward compatibility claim doesn't come without costs.
>
> Don't build our grand castle on the moving sand dune, on which a
tiny tent is more adequate
> and wise choice. :-)
>
> Soobok Lee
>
>
>
>




From owner-idn@ops.ietf.org  Wed Feb 13 16:17: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 QAA20951
	for ; Wed, 13 Feb 2002 16:16:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b6gI-000Fo1-00
	for idn-data@psg.com; Wed, 13 Feb 2002 13:11:10 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16b6gG-000Fnt-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 13:11:08 -0800
Received: (qmail 6717 invoked by uid 1001); 13 Feb 2002 17:06:04 -0000
Date: 13 Feb 2002 17:06:04 -0000
Message-ID: <20020213170604.3529.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] IDNA interoperability failures, once again
References: <3C68B8BB.8E49A530@ehsco.com> <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net> <20020213035531.13155.qmail@cr.yp.to> <20020213144112.GA2327@wonderland.linux.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> > Again assume LANG=en_US.UTF-8, so this can be done.
> This assumption is wrong.

Please look up the word ``assumption'' at m-w.com. I did not say that
everyone uses LANG=en_US.UTF-8. I explicitly restricted attention to
that locale, because it's a locale where the programs under discussion
_can_ display IDNs properly.

The point of this thread is that the IDNA deployment plan will cause
interoperability failures: in particular, mail will bounce. Until the
IDNA proponents can explain how to fix these problems in _one_ modern
Unicode-aware locale, there's no point in considering other locales.

> some national charset like ISO-8859-1 or KOI8-R

Converting UTF-8 to KOI8-R is unreliable, obviously. The reason we want
the world to settle on Unicode is to eliminate such problems. Has it
never occurred to you that some Russian users want to see non-KOI8-R
characters? Or that some Europeans want to see non-8859-1 characters?

Maybe you're happy never seeing anything outside 8859-1. But people
writing software still have to take time to deal with the character-set
mess---time taken away from giving you features that you want. Try not
to be so shortsighted.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Wed Feb 13 16:29: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 QAA21896
	for ; Wed, 13 Feb 2002 16:29:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b6tA-000GCu-00
	for idn-data@psg.com; Wed, 13 Feb 2002 13:24:28 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b6t9-000GCo-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 13:24:27 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16b6t9-0004hp-00
	for ; Wed, 13 Feb 2002 13:24:27 -0800
Date: Wed, 13 Feb 2002 21:24:27 +0000
From: "Adam M. Costello" 
To: "'IETF idn working group'" 
Subject: Re: [idn] a few more comments on the last call documents
Message-ID: <20020213212426.GB17479@nicemice.net>
Reply-To: IETF idn working group 
References: <411080000.1013536029@localhost> <000a01c1b47b$424d8c00$d5d61081@chalmers95a69n> <20020212225912.GC3881@nicemice.net> <000901c1b47a$1ed0e160$d5d61081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000a01c1b47b$424d8c00$d5d61081@chalmers95a69n> <000901c1b47a$1ed0e160$d5d61081@chalmers95a69n>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Kent Karlsson  wrote:

> In the UTR 17 model, Punycode is a "Transfer Encoding Syntax" (TES),
>
> A few other things are TESes: UTF-7, MIME/QP, MIME/BASE64, GB/HZ, and
> also the syntaxes \uhhhh of Java/C and &#xhhhhh; of XML.
>
> I would not simply refer to Punycode as an "encoding", as to many that
> would suggest that it was a Character Encoding Scheme or Character
> Encoding Form.

Would other Unicode experts concur that the title of the Punycode draft
should call it a transfer encoding syntax?  Or if it doesn't really fit
into the model at all, should it use a vague term like "transformation"
rather than "encoding"?

> > sometimes [copy/paste] just retrieves a string from the GUI
> > corresponding to exactly what is displayed.
>
> Any such system/application is SEVERELY FLAWED.

Probably true, but unfortunately it's also quite common.  It's the norm
for X Windows applications.  X is severely flawed in many ways.

AMC



From owner-idn@ops.ietf.org  Wed Feb 13 16:52: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 QAA22299
	for ; Wed, 13 Feb 2002 16:52:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b7FP-000GyX-00
	for idn-data@psg.com; Wed, 13 Feb 2002 13:47:27 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16b7FO-000GyQ-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 13:47:26 -0800
Received: from [] (vg148.viagenie.qc.ca [206.123.31.148])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g1DM71a78309
	for ; Wed, 13 Feb 2002 17:07:01 -0500 (EST)
Date: Wed, 13 Feb 2002 16:47:03 -0500
From: Marc Blanchet 
To: IETF idn working group 
Subject: Re: [idn] a few more comments on the last call documents
Message-ID: <270000000.1013636823@localhost>
In-Reply-To: <20020212225912.GC3881@nicemice.net>
References: <111160000.1013488892@localhost>
 <109960000.1013488820@localhost> <20020212064724.GM26818@nicemice.net>
  <110820000.1013488872@localhost>
 <111160000.1013488892@localhost> <109960000.1013488820@localhost>
 <20020212064724.GM26818@nicemice.net> <411080000.1013536029@localhost>
 <000301c1b3b5$3cea6010$b4e21081@chalmers95a69n>
 <20020212225912.GC3881@nicemice.net>
X-Mailer: Mulberry/2.2.0b2 (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 QAA22299



-- mardi, fvrier 12, 2002 22:59:13 +0000 "Adam M. Costello" 
 wrote/a crit:
>> Marc Blanchet  wrote:
>
>> I would probably add a sentence just after "Punycode can support ...",
>> something like: "However, it MUST NOT be implemented for IDNA."
>
> A Punycode encoder/decoder that implements mixed-case annotation will
> behave exactly the same as a Punycode encoder/decoder that does not
> implement mixed-case annotation, except that the encoder can accept
> flags and the decoder can return flags.  But those flags don't alter
> the output of the encoder except for the case of ASCII letters (which
> doesn't matter for domain labels), and they don't alter the sequence of
> code points returned by the decoder at all.  So there is no reason to
> forbid the Punycode encoder/decoder from implementing this feature.

To me, we want a spec which defines clearly what has to be implemented and 
not.
This option is an optional behavior that should not be implied as to be 
implemented in order to be conformant.

I would argue again to say clearly that this option should not be 
implemented in IDNA.

>
> I will, however, add explicit language to that effect:
>
>     Mixed-case annotation MUST NOT alter the encoder output as defined
>     in section 6.3 except for affecting the case of ASCII letters, and
>     mixed-case annotation MUST NOT alter the sequence of code points
>     returned by the decoder as defined in section 6.2.
>
>> The version will be freezed with the RFC number. i.e. the version of
>> the code is the RFC number.
>
> It's possible that I might continue to develop the code after the RFC is
> published.

And others will implement the spec. So does the specific versioning of the 
code of a specific author make any sense in the context of multiple source 
codes. No.

>For example, I might make stylistic changes or add comments
> or slightly change the interface.

sure. great.

>  Those later versions of the sample
> code won't appear in an RFC, so they'll need their own version number,
> and it will be nice if the sample code in the RFC has a version number
> that can be compared with the version number in the more recent sample
> code.

again. version number of the code will be the RFC number.

>
>> title of the draft: "Punycode version 0.3.3"
>> then annex D:
>>
>> /*
>> punycode.c 0.4.0 (2001-Nov-17-Sat)
>>
>> /* This is ANSI C code (C89) implementing Punycode version 0.3.x. */
>
> What's wrong with that?  Version 0.4.0 of punycode.c implements version
> 0.3.anything of Punycode.  I can use a wildcard like that because all
> 0.3.x versions are equivalent, with only editorial differences.


I understood that you had internal versioning of your algorithm and this is 
ok.
I don't think it will be of any relevance inside an RFC.

If I implement your spec, I'll say it is compliant with RFC XXXX, not to 
the x.y.z version of your code. So your own versioning is irrelevent to the 
RFC.

>
>> How relevent to a specification is the date you made the code?
>
> It's not, but the the date is relevant to the code itself.  We are
> embedding a file inside a document, and that file contains its version
> number and date stamp.

again. it is not relevent. We are publishing a specification with sample 
code in it.

>
>> I think your version numbering management is all fine for yourself. I
>> don't think it is appropriate for an RFC.
>
> Lots of RFCs have version numbers:
>
> RFC-1950 ZLIB compressed data format specification version 3.3
> RFC-1951 DEFLATE compressed data format specification version 1.3
> RFC-1952 GZIP file format specification version 4.3
> RFC-2060 Internet Message Access Protocol - version 4rev1
> RFC-2246 The TLS protocol version 1.0
> RFC-2437 PKCS #1: RSA cryptography specifications version 2.0
> RFC-2616 Hypertext Transfer Protocol -- HTTP/1.1

yes. it is exactly my point. You could say in the title "Punycode v1.0 ...".
But the code inside it does not need to have a version number.

Marc.




From owner-idn@ops.ietf.org  Wed Feb 13 17:08: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 RAA22599
	for ; Wed, 13 Feb 2002 17:08:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16b7Un-000HS9-00
	for idn-data@psg.com; Wed, 13 Feb 2002 14:03:21 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16b7Un-000HRy-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 14:03:21 -0800
Received: (qmail 9274 invoked by uid 1001); 13 Feb 2002 16:30:57 -0000
Date: 13 Feb 2002 16:30:57 -0000
Message-ID: <20020213163057.29845.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: [idn] Why IDNA breaks copy-and-paste
References: <20020212225912.GC3881@nicemice.net> <000901c1b47a$1ed0e160$d5d61081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Kent Karlsson writes:
> What is displayed is glyphs.  In many cases there is no (uniquely)
> corresponding character.

You misunderstand.

Look at the copy-and-paste supported by the UNIX xterm program. Does it
read dots off the display and attempt to convert them to characters? Of
course not. It obtains characters directly from xterm.

This does _not_ mean, however, that it obtains characters directly from
``the application,'' such as the MH/NMH ``show'' program that Keith uses
to read his mail. The system has been engineered so that

   * programs such as ``show'' simply print characters, without worrying
     about dots on the display, copy-and-paste, etc.;

   * programs such as ``xterm'' read characters and manage the display,
     without worrying about where the characters came from.

This modularity speeds software development; let me again recommend
Gancarz's ``UNIX Philosophy'' book. The system doesn't have, and doesn't
need, copy-and-paste in programs such as ``show''.

Web-mail systems are engineered the same way:

   * The web server converts your mail to HTML, without worrying about
     your display.

   * The browser displays the HTML, without worrying about how the HTML
     was generated.

This modularity again speeds software development---but it again means
that there's no copy-and-paste support in the web-mail system.

We seem to have many novice programmers here, people under the delusion
that copy-and-paste is always handled by ``the application,'' which can
provide characters in some dorky 7-bit encoding if it wants to. But the
real world has, in many cases, advanced beyond that primitive model.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Thu Feb 14 01:19: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 BAA04180
	for ; Thu, 14 Feb 2002 01:19:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bEzZ-00043s-00
	for idn-data@psg.com; Wed, 13 Feb 2002 22:03:37 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bEzU-00042j-00
	for idn@ops.ietf.org; Wed, 13 Feb 2002 22:03:33 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP id C3F33FFC09
	for ; Thu, 14 Feb 2002 14:02:32 +0800 (SGT)
Message-ID: <03de01c1b51d$58ebc510$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: 
Subject: [idn] protest mail summary
Date: Thu, 14 Feb 2002 14:03:34 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_03D9_01C1B560.63E3B5C0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_03D9_01C1B560.63E3B5C0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Sorry for been late in this:

A total of 353 "protest" mails have been recieved, including those that
is posted to the working group.

The protest mails comes in two standard format, MAIL1 and MAIL2 (See
attached) and the break down of the mails is as below.

All of them have been auto-responded with a standard reply (see
attached) to informed them of
    1. Their mails have been pooled and will summaried on 11th Feb
    2. Internet Standard Process RFC 2026
    3. Invitation to join the working group and to provide their
       technical arguments on the last call

Two private response have been recieved after the autoreply message have
been send out, one that say "Thanks for the reply. I just want to make
things better." and the other that say "I'll think about it".

Other than these two responses, no further messages have been recieved.

-James Seng

Email                                MAIL1   MAIL2
5463715@pchome.com.tw                    1       0
9sman@sinamail.com                       0       1
CCChuan4@winbond.com.tw                  1       0
Chen.Ariel@inventec.com                  0       1
Chen.Stan@inventec.com                   0       1
Hsieh@stud-mailer.uni-marburg.de         1       0
MaxMao@giga.net.tw                       0       2
NY8869962@yahoo.com                      0       1
Tony.Wang@iaSolution.net                 1       0
Wu.Wey-Mim@inventec.com                  0       1
abw@iss.com.tw                           1       0
acelin@ms2.url.com.tw                    0       1
adawen@erato.dricas.com                  0       1
advance2000@giga.net.tw                  0       1
al6688.su@msa.hinet.net                  1       0
allatin@hoolan.org                       1       0
aloe_lew@pchome.com.tw                   0       1
amony@ms28.hinet.net                     1       0
aproll@ms1.hinet.net                     1       0
aqua@ms7.url.com.tw                      1       0
archer@stcopper.com.tw                   1       0
arthur88tw@yahoo.com.tw                  0       1
ate5168@yahoo.com.tw                     1       0
b6610104@ms.cc.ntu.edu.tw                0       1
blue.davie@msa.hinet.net                 1       0
bluek@ms1.hinet.net                      0       1
bluekid828@seed.net.tw                   0       1
bobby@iis.sinica.edu.tw                  0       1
bobchao@ms1.url.com.tw                   1       1
c610327@hotmail.com                      1       0
cab0722@cm1.ethome.net.tw                1       0
cahue122@ms39.hinet.net                  1       0
cancerman@seed.net.tw                    0       1
cat2k88@yahoo.com                        1       0
catchang@altavista.com                   1       0
cclu@ee.nthu.edu.tw                      0       1
ccy0927@neural.ee.ncku.edu.tw            0       1
ceary@pchome.com.tw                      0       1
chang212@staff.yam.com                   0       1
changwc@phys.sinica.edu.tw               1       0
chen_elsa@hotmail.com                    1       0
chengtsung@pchome.com.tw                 1       0
chenyy@ms22.url.com.tw                   0       1
chi@mis.nccu.edu.tw                      0       1
chiahung@gmx.de                          0       1
chih727@ms28.hinet.net                   1       0
chihwen@staff.yam.com                    0       1
chinjill@seed.net.tw                     1       0
chiu0514@ms18.hinet.net                  0       1
chliao@tpts4.seed.net.tw                 1       0
choco@chusv1.me.nctu.edu.tw              1       0
choucy@sparc2.Nhltc.edu.tw               0       1
chrishuang@seed.net.tw                   0       1
christyt@ms16.hinet.net                  1       1
chsiao@staff.yam.com                     0       1
chtseng@cht.com.tw                       1       0
chun577@ms55.hinet.net                   0       1
chunchuo@pcmail.com.tw                   0       1
chwang@iis.sinica.edu.tw                 0       1
cjchen@csie.nctu.edu.tw                  1       1
ckao2@csulb.edu                          1       0
ckuo@vot.url.com.tw                      0       1
clair@softwareliberty.org                1       0
cll88lynn@pchome.com.tw                  0       1
cm84005@cm.nctu.edu.tw                   1       0
cmcheng@ms3.url.com.tw                   1       0
cmlee@iis.sinica.edu.tw                  1       0
cr.kao@ever.com.tw                       0       1
crxcrx@ms24.url.com.tw                   1       0
csf8109@so-net.net.tw                    0       1
cshih@uiuc.edu                           0       1
csho@et.ntust.edu.tw                     0       1
curtain_tseng@hotmail.com                1       1
cwlin@roger.ee.ncu.edu.tw                0       1
cykao@csie.ntu.edu.tw                    1       0
d1972@ms46.hinet.net                     1       0
d6526005@csie.ntu.edu.tw                 1       0
d87027@ccws8.ee.ntu.edu.tw               0       1
danchao@staff.yam.com                    0       1
davihuan@seed.net.tw                     1       0
dcam@iplus.net.tw                        0       1
denn3232@ms34.hinet.net                  1       0
dmlee@techart.tnua.edu.tw                0       1
dtlee@iis.sinica.edu.tw                  1       1
e1233516@ms39.hinet.net                  0       2
e6666@ms14.hinet.net                     1       1
e7011273@ms16.hinet.net                  1       0
e9487118@ccmail.ncku.edu.tw              0       1
eamgh@giga.net.tw                        1       0
edt1023@speedymail.org                   1       1
edwardwen@sparqnet.net                   1       0
ee892010@ee.ncu.edu.tw                   1       0
electer@pchome.com.tw                    1       0
elilau@ms36.hinet.net                    2       2
elliot@aiecon.org                        0       1
elsa@ms15.url.com.tw                     0       1
email@vip.url.com.tw                     0       1
enoch.lee@msa.hinet.net                  1       0
eric_cheng@accusys.com.tw                0       1
erichia@ms45.hinet.net                   0       1
f587090098@s6.mhit.edu.tw                0       1
fann@iis.sinica.edu.tw                   1       0
felix_lee@seed.net.tw                    1       0
fireheadchen@ms46.url.com.tw             1       0
florahu@shaw.ca                          0       1
frank@goolu.com                          1       0
g895633@student.thu.edu.tw               0       1
g905629@oz.nthu.edu.tw                   2       1
ga2002_tw@yahoo.com                      0       1
gamewind@giga.net.tw                     1       0
gandalf@seed.net.tw                      3       4
garyhu@iii.org.tw                        1       0
gc@iis.sinica.edu.tw                     1       0
genewang99@yahoo.com                     1       0
gerry@mail.cool-site.idv.tw              1       0
ginbaserver@yahoo.com.tw                 1       0
gis555@m1.is.net.tw                      0       1
gis84527@cis.nctu.edu.tw                 1       2
gmchen@machvision.com.tw                 1       0
good-joe@taiwan.com                      1       0
green@staff.yam.com                      1       0
gsyan@lsps.tp.edu.tw                     0       1
gtliu1123@taiwan.com                     1       0
gtliu1123@yahoo.com.tw                   1       0
gtliu@mail2000.com.tw                    2       0
h7638629@pchome.com.tw                   0       1
hbger@rpgs1.soc.nthu.edu.tw              0       1
hbsheu@vghtpe.gov.tw                     1       0
hcc1024.huang@msa.hinet.net              1       0
hhwang@mail2000.com.tw                   0       1
hlchou@mail2000.com.tw                   2       1
hpchen@db.csie.ncu.edu.tw                0       1
huger@ms11.hinet.net                     1       0
hwaijeh@tcts.seed.net.tw                 1       0
hwike02@ms69.url.com.tw                  1       0
hycheng@iis.sinica.edu.tw                1       0
hys88@cs.ccu.edu.tw                      1       0
iKakeru@netscape.net                     1       0
iav940@ms10.hinet.net                    1       2
iccheng@mcu.edu.tw                       1       1
ich@techart.tnua.edu.tw                  1       0
ifhuang@ms21.hinet.net                   0       1
inhon@u-aizu.ac.jp                       0       1
is87056@cis.nctu.edu.tw                  0       1
jackmau@pchome.com.tw                    1       0
jahorng@iis.sinica.edu.tw                1       0
janson@ms3.url.com.tw                    1       0
jarbamay@yahoo.com                       1       0
jays_chi@hotmail.com                     0       1
jazz@norlee.com                          1       0
jctan@acm.org                            0       1
jeansonh@admtek.com.tw                   0       1
jeff@hoolan.org                          0       1
jeffliu@wiscore.com                      1       0
jelan816@ms17.hinet.net                  1       0
jennycustomers@hotmail.com               0       1
jerry.hsliu@msa.hinet.net                0       1
jerry@lcy.com.tw                         1       0
jevons@foreknow.com.tw                   1       0
jhuang@mail.tku.edu.tw                   1       0
jianhom@hotmail.com                      0       1
jiunkuei@yahoo.com.tw                    0       1
johnchang@itri.org.tw                    0       1
jojo@staff.yam.com                       1       0
jonah.lin@msa.hinet.net                  1       0
js22@jasonel.com.tw                      1       0
jw-lin@yahoo.com.tw                      0       1
jyhuang@pcs.csie.nctu.edu.tw             1       0
k4380khh@ms23.hinet.net                  1       0
kang_wayne34@hotmail.com                 1       0
keanu@ms50.url.com.tw                    0       1
kiater@pchome.com.tw                     1       0
kitkat@cradle.com.tw                     1       0
koliner@seed.net.tw                      0       1
kulun@iis.sinica.edu.tw                  0       1
kunfeng.lee@msa.hinet.net                1       0
laputa1224@yahoo.com.tw                  0       1
leolarrel@yahoo.com.tw                   1       0
li@nccu.edu.tw                           0       1
lin1438@hotmail.com                      1       1
ling@techart.nia.edu.tw                  1       0
linlll@vip.url.com.tw                    1       0
liu0610@pchome.com.tw                    0       1
llwang@infor.org                         0       1
luke_liu@staff.yam.com                   1       0
luliwei@cm1.ethome.net.tw                0       1
maggiechou@msn.com                       1       0
mark.hsy@msa.hinet.net                   0       1
master@beurl.com                         1       0
max@mail2.cy.edu.tw                      0       1
miao@mail.trtc.com.tw                    0       1
min-ray@yahoo.com.tw                     1       0
mingda@gate.sinica.edu.tw                1       0
monksun@ebtnet.net                       0       1
mozart@ms40.url.com.tw                   1       0
mtlin1@ms36.hinet.net                    0       1
murphychen@mail2000.com.tw               1       0
n4968451@ms29.hinet.net                  1       0
nacestudio@giga.net.tw                   1       0
nanri@bbs.ee.fcu.edu.tw                  1       0
navyfang@ms31.hinet.net                  0       1
neil@mail.min-yao.net                    0       1
neoikki@giga.net.tw                      0       1
netsurfer@mail2000.com.tw                0       1
nschen@cc.nsysu.edu.tw                   0       2
null_doc@pchome.com.tw                   0       1
opusiii@ms13.hinet.net                   0       1
orho@leadtek.com.tw                      1       0
pcjacq@pchome.com.tw                     1       0
phchen@ccms.ntu.edu.tw                   0       1
phhung@itri.org.tw                       1       0
polyyang@cm1.ethome.net.tw               1       0
ppiro@ms43.hinet.net                     0       2
preisner@iis.sinica.edu.tw               0       1
quantos@hotmail.com                      1       0
r1358@ms7.url.com.tw                     1       0
reding@mail2000.com.tw                   0       1
rfive@cm1.ethome.net.tw                  1       0
richliu@poorman.org                      1       0
richy@waley.com                          1       0
rock.roll@msa.hinet.net                  1       0
roger@rogerdeng.idv.tw                   0       1
rushu@pchome.com.tw                      1       0
s0chen1@wmich.edu                        1       1
s1232536@ms48.hinet.net                  1       1
s8327202@seed.net.tw                     0       1
s881051@ym.edu.tw                        1       0
s89085@cc.ntnu.edu.tw                    0       1
s8912@cs.nccu.edu.tw                     1       0
s891729@seed.net.tw                      1       0
s9323090@cc.ncu.edu.tw                   0       1
s9523010@cc.ncu.edu.tw                   0       1
salmon_h@ms25.url.com.tw                 0       1
samliu@staff.yam.com                     1       1
savagelee@pchome.com.tw                  1       1
sawang@iis.sinica.edu.tw                 0       1
sbjiang@pchome.com.tw                    0       1
scarf0222@yahoo.com.tw                   1       0
seventeen@linux.org.tw                   1       0
shaking@shaking.net                      0       1
shaoahs@ms39.url.com.tw                  1       0
shihhsin_hu.tw@yahoo.com.tw              1       0
shlin@iis.sinica.edu.tw                  1       0
shyue@linux.shyue.idv.tw                 0       1
sky.jou@msa.hinet.net                    0       1
skylooker@pchome.com.tw                  0       1
skylookerlin@yahoo.com.tw                1       0
slose@selab.csie.ncu.edu.tw              1       0
smingli@pchome.com.tw                    0       1
sophia@center.fjtc.edu.tw                0       1
sthsieh@ha.mc.ntu.edu.tw                 1       0
stsai@frontier.org.tw                    1       0
stt89@gais.cs.ccu.edu.tw                 0       1
sun_sherry@ms5.url.com.tw                0       1
sunflier@yahoo.com                       1       0
sunisswang@giga.net.tw                   1       0
superbee@mail.tachan.com.tw              1       0
t_fox@blue.url.com.tw                    0       1
taichis@shsh.ylc.edu.tw                  0       1
taili@gate.sinica.edu.tw                 0       2
tango200@seed.net.tw                     1       0
tbsky@greenware.com.tw                   0       1
tcliu@mail2000.com.tw                    1       0
thedoors@pchome.com.tw                   1       0
tinghsienyi@seed.net.tw                  0       1
tktsay@ccms.ntu.edu.tw                   0       1
tmm@ms.cc.ntu.edu.tw                     2       0
tsung@iis.sinica.edu.tw                  1       0
u2261123@cc.ncu.edu.tw                   0       1
u8097500@cc.ncu.edu.tw                   1       0
u8711007@cc.nkfust.edu.tw                1       0
u8912818@cc.nkfust.edu.tw                1       1
upc@sunland.com.tw                       1       1
victorlin11@pchome.com.tw                0       1
viewer@mail2000.com.tw                   0       1
vtsai@tecom.com.tw                       1       0
wanching411@hotmail.com                  0       1
wangtun@staff.yam.com                    0       1
wanjiun@pegasus.rutgers.edu              1       0
waylonlee@seed.net.tw                    1       0
weigianc@hotmail.com                     0       1
wenjang@ms1.hinet.net                    0       1
wenlu@ms1.tcol.com.tw                    0       1
whchu@ms2.hinet.net                      1       1
willyjr@ms8.url.com.tw                   0       2
winona.chen@msa.hinet.net                1       0
wood.ep87@nctu.edu.tw                    1       0
workfun@gate.sinica.edu.tw               2       0
wychen@sounding.com.tw                   0       1
wylin@isu.edu.tw                         0       1
xiang_1110@yahoo.com.tw                  1       0
xtom.hung@msa.hinet.net                  1       0
yang@mail.ee.ntu.edu.tw                  1       1
yangbin@msn.com                          1       0
yclin@et.ntust.edu.tw                    0       1
ycpan@ccms.ntu.edu.tw                    1       0
yehhc990@ms32.hinet.net                  1       0
yhliu@ibm.stat.ncku.edu.tw               0       1
ying0928@ms63.hinet.net                  1       0
yinyins@ms9.url.com.tw                   0       1
yjy@aic.ee.ntu.edu.tw                    0       1
yrc@ms.cc.ntu.edu.tw                     1       1
ysheng65@ms6.url.com.tw                  1       0
ysst@msn.com                             0       1
yu_shens@hotmail.com                     0       1
yusd5644@gate.sinica.edu.tw              1       0
yvb@iis.sinica.edu.tw                    0       1
yychang@aicompro.com                     1       0
zziven@hotmail.com                       1       0
                              Total    181     172    353

------=_NextPart_000_03D9_01C1B560.63E3B5C0
Content-Type: text/plain;
	name="MAIL1.txt"
Content-Disposition: attachment;
	filename="MAIL1.txt"
Content-Transfer-Encoding: quoted-printable

Subject: PROTEST! RESCUE CHINESE DOMAIN NAMES.

PROTEST! RESCUE CHINESE DOMAIN NAMES.

Many Han character variants, also known as equivalent Chinese =3D
characters, exists in Unicode. A Chinese domain name thus usually has =
=3D
many different Unicode representations. As Unicode evolves, more CJK Han =
=3D
characters are added to Unicode. It also increases the number of =3D
variants of a character and the number of characters with variants, and =
=3D
thus the number of Unicode representations per Chinese domain name. =
=3D20

Though it meets the needs for internationalized domain name of those =3D
people who uses phonetic characters. However, a Chinese domain name =3D
service based on IDN WG technology is defective.

We urge the working group to seriously take these cultural differences =
=3D
into account. Do not finalize IDN documents without minimizing their =3D
negative impacts against Chinese domain names.

DO NOT DAMAGE INTERNET COMUNITY IN CHINA AND TAIWAN!


------=_NextPart_000_03D9_01C1B560.63E3B5C0
Content-Type: text/plain;
	name="MAIL2.txt"
Content-Disposition: attachment;
	filename="MAIL2.txt"
Content-Transfer-Encoding: 7bit

Subject: Please do not pass an IDN document which you know will cause 
conflicts and chaos

I've recently come to know that IETF is about to release 
drafts on IDN standards, and to my regret, I found that 
the document does not solve problems for Chinese domain 
names. and this defect in your drafts will result conflicts 
and chaos for internet users of Han characters, namely 
Chinese, Korean and Japanese, and the effect is international 
because users of these languages are all over the world.

It is important to know that while a certain character can 
have different appearance in Simplified Chinese and Traditional 
Chinese Character forms even though they are actually same words 
with the same meaning; at the same time, a certain character 
which might look exactly the same, but in fact are two different 
words with different meaning when applied to different languages 
such as Chinese and Japanese.

I believe that IETF bears great responsible in setting standards 
which will bring order to the internet world, and any document 
which might cause disorder, should be carefully reconsidered 
before release.Therefore, before IETF can resolve this problem 
and identify one mechanism which can differentiate these delicate 
language difference, IETF should not pass the document which 
would apply Unicode for IDN resolution, because this irresponsible 
decision is going to cause conflicts and chaos in DN registration 
policy and DRP worldwide.


------=_NextPart_000_03D9_01C1B560.63E3B5C0
Content-Type: text/plain;
	name="REPLY.txt"
Content-Disposition: attachment;
	filename="REPLY.txt"
Content-Transfer-Encoding: 7bit

First, thank you for your mail.

Please note that we have not let your mail go to the idn-wg
given other similar mails have been send to the group.

Instead, we will put your mail into a pool, and summaries them
to the idn-wg on 11th Feb 2002.

RFC2026 (http://www.ietf.org/rfc/rfc2026.txt) document the
IETF Standard Process. It also specify the appropriate action
one could take to appeal. However, sending protest mail to stop
the last call is not one of possible process.

Please note that WG Last Call is for fine-tuning the document
we are going to move forward. Protest to stop the last call will
be noted but not useful to the last call itself.

Instead, if you have read the drafts and have modifications you
wish to be made, then please bring them to the working group with
your technical arguments.

Please also review the discussion we have for the 2+ years of
archives on http://www.imc.org/idn/mail-archive/mail12.html
before you make your comments to avoid repeat discussion on
topics which already been concluded.

We welcome you to join our wg which you can do so by sending
an email to majordomo\@ops.ietf.org with the word "subscribe idn".

FYI, IDN Working Group Last Call will conclude on 11th Feb 2002.

-James Seng
------=_NextPart_000_03D9_01C1B560.63E3B5C0--




From owner-idn@ops.ietf.org  Thu Feb 14 07:03: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 HAA15626
	for ; Thu, 14 Feb 2002 07:03:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bKN7-000Bes-00
	for idn-data@psg.com; Thu, 14 Feb 2002 03:48:17 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bKN6-000Bem-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 03:48:16 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1EBmBh17525;
	Thu, 14 Feb 2002 12:48:11 +0100 (MET)
From: "Kent Karlsson" 
To: "'D. J. Bernstein'" , 
Cc: "'Markus Kuhn'" 
Subject: RE: [idn] Why IDNA breaks copy-and-paste
Date: Thu, 14 Feb 2002 12:45:02 +0100
Message-ID: <000f01c1b54d$0aac7c70$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20020213163057.29845.qmail@cr.yp.to>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dan,

	I hesitate to say, but you misunderstand.  Grossly.

	For "copy and paste" involving a terminal emulator, the
"application" of interest is the terminal emulator itself.  

	Now, converting from a stream of characters to a stream of
glyphs is in general a non-trivial step.  For a very restricted
subset of strings, the mapping **MAY** be (but usually isn't,
since it is a bad idea and does not generalise well) made by
mapping from the stream of input characters to a stream of
characters representing the glyphs that are to be displayed.
Sometimes, in these restricted cases, the mapping may be the
identity mapping, but even in these restricted cases, the mapping
may take context into account (for contextual shaping of Arabic
for instance) or do BiDi mapping to "visual order" (i.e. left-to-right
order, misnamed).

	But in general this approach does not work: ligatures that don't
have corresponding characters, contextual shapes that don't have
corresponding characters, etc. All-in-all this depends much on
the font chosen in the "front UI application".

	In either case, it is *wrong* to take the sequence of "glyph
indicies" (which is the result of these processes, whether these
correspond to allocated characters or not) as the object to "cut and
paste".  It must be the sequence of characters that was the input
to that process that is the object to do "cut-and-paste" on.  

	Now if a background application does the mapping from characters
to glyph indices (maskerading as characters), cutting and pasting
at the terminal emulator application level can't be expected to
work.  But this is a degenerate situation; the background application
should not attempt to do this mapping.  A properly constructed
"front UI application" should get a stream of characters from 
the "background application"; the mapping to glyph indices (and
where to place the glyphs) should be done by the "front UI
application" (normally via some system library; and the actual
mapping often depends on the font used); cutting (and pasting)
should involve only the "front UI application" and should work on
the characters received, not on the glyph indices (even if they
are mascarading as characters).

	The glyphs, or rather their indices, in a step further may
be turned into a set of pixels on a screen (the true glyphs, if
you like, but it is tedious to say "glyph indices" all the time,
so they are informally referred to as "glyphs"), a step which I
haven't talked about, and is not expected to be reversed by
some kind of OCR process for cut-and-paste (where did you get
that idea from?); in short: the pixels are irrelevant here.

	And yes, I do copy-and-paste from web pages quite often,
I think I know how it works, in principle at least... On rare
occations I also use terminal emulators, and copy-and-paste
there too.  I think I know how that works, or should work, in
principle too...  Xterm, under Linux, does some odd things where
it maps characters to characters (glyph indices really). I'm not
sure if, or from which version, it does correct copy-and-paste.

	Whichever side ("background" or "front") that gets
a Punycoded string, to be able to convert to a Unicode
string, must "know" that it is Punycoded.  That is very
hard to do if *both* sides are "unaware" of Punycode, and
where it may be applied and were it may not be applied...

		Kind regards
		/kent k





> -----Original Message-----
> From: owner-idn@ops.ietf.org 
> [mailto:owner-idn@ops.ietf.org]On Behalf Of
> D. J. Bernstein
> Sent: den 13 februari 2002 17:31
> To: idn@ops.ietf.org
> Subject: [idn] Why IDNA breaks copy-and-paste
> 
> 
> Kent Karlsson writes:
> > What is displayed is glyphs.  In many cases there is no (uniquely)
> > corresponding character.
> 
> You misunderstand.
> 
> Look at the copy-and-paste supported by the UNIX xterm 
> program. Does it
> read dots off the display and attempt to convert them to 
> characters? Of
> course not. It obtains characters directly from xterm.
> 
> This does _not_ mean, however, that it obtains characters 
> directly from
> ``the application,'' such as the MH/NMH ``show'' program that 
> Keith uses
> to read his mail. The system has been engineered so that
> 
>    * programs such as ``show'' simply print characters, 
> without worrying
>      about dots on the display, copy-and-paste, etc.;
> 
>    * programs such as ``xterm'' read characters and manage 
> the display,
>      without worrying about where the characters came from.
> 
> This modularity speeds software development; let me again recommend
> Gancarz's ``UNIX Philosophy'' book. The system doesn't have, 
> and doesn't
> need, copy-and-paste in programs such as ``show''.
> 
> Web-mail systems are engineered the same way:
> 
>    * The web server converts your mail to HTML, without worrying about
>      your display.
> 
>    * The browser displays the HTML, without worrying about 
> how the HTML
>      was generated.
> 
> This modularity again speeds software development---but it again means
> that there's no copy-and-paste support in the web-mail system.
> 
> We seem to have many novice programmers here, people under 
> the delusion
> that copy-and-paste is always handled by ``the application,'' 
> which can
> provide characters in some dorky 7-bit encoding if it wants 
> to. But the
> real world has, in many cases, advanced beyond that primitive model.
> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 



From owner-idn@ops.ietf.org  Thu Feb 14 09:07: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 JAA18434
	for ; Thu, 14 Feb 2002 09:07:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bMR7-000ECu-00
	for idn-data@psg.com; Thu, 14 Feb 2002 06:00:33 -0800
Received: from attila.bofh.it ([213.92.8.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bMR6-000ECo-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 06:00:32 -0800
Received: by attila.bofh.it (Postfix, from userid 10)
	id 9403A60212; Thu, 14 Feb 2002 15:00:31 +0100 (CET)
Received: by wonderland.linux.it (Postfix/Md, from userid 1001)
	id 8AFF433B67; Thu, 14 Feb 2002 15:00:18 +0100 (CET)
Date: Thu, 14 Feb 2002 15:00:18 +0100
From: "Marco d'Itri" 
To: idn@ops.ietf.org
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020214140018.GA2035@wonderland.linux.it>
Mail-Followup-To: idn@ops.ietf.org
References: <20020212071810.GO26818@nicemice.net> <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net> <20020213035531.13155.qmail@cr.yp.to> <20020213144112.GA2327@wonderland.linux.it> <20020213170604.3529.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020213170604.3529.qmail@cr.yp.to>
User-Agent: Mutt/1.3.27i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Feb 13, "D. J. Bernstein"  wrote:

 >Please look up the word ``assumption'' at m-w.com. I did not say that
 >everyone uses LANG=en_US.UTF-8. I explicitly restricted attention to
 >that locale, because it's a locale where the programs under discussion
 >_can_ display IDNs properly.
And my point is that assuming wide deployment of UTF-8 (like you do in
http://cr.yp.to/proto/idn.html) is pointless, because such a thing does
not exist and will not exist in the near future, at least in most of
Europe and in the UNIX community of Japan (I do not know about windows
users).

 >The point of this thread is that the IDNA deployment plan will cause
 >interoperability failures: in particular, mail will bounce. Until the
 >IDNA proponents can explain how to fix these problems in _one_ modern
 >Unicode-aware locale, there's no point in considering other locales.
This has already been discussed to death on this mailing list and I feel
I do not have anything new to add.

 >> some national charset like ISO-8859-1 or KOI8-R
 >Converting UTF-8 to KOI8-R is unreliable, obviously. The reason we want
 >the world to settle on Unicode is to eliminate such problems. Has it
Maybe you want this, but most of the world does not feel the need to use
unicode instead of their usual national charsets and does not want to
experience the interoperability problems of such a change.

 >never occurred to you that some Russian users want to see non-KOI8-R
 >characters? Or that some Europeans want to see non-8859-1 characters?
Yes, I've met on the network a few people with this need, but they are
not at all representative of the users of their country.

-- 
ciao,
Marco



From owner-idn@ops.ietf.org  Thu Feb 14 10:06: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 KAA23727
	for ; Thu, 14 Feb 2002 10:06:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bNFt-000FHm-00
	for idn-data@psg.com; Thu, 14 Feb 2002 06:53:01 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bNFt-000FHg-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 06:53:01 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020214145300.CKS2951.rwcrmhc53.attbi.com@c1340594a>
          for ; Thu, 14 Feb 2002 14:53:00 +0000
Message-ID: <005301c1b567$a1481800$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" 
From: "Mark Davis" 
To: "IETF idn working group" 
References: <411080000.1013536029@localhost> <000a01c1b47b$424d8c00$d5d61081@chalmers95a69n> <20020212225912.GC3881@nicemice.net> <000901c1b47a$1ed0e160$d5d61081@chalmers95a69n> <20020213212426.GB17479@nicemice.net>
Subject: Re: [idn] a few more comments on the last call documents
Date: Thu, 14 Feb 2002 06:55:23 -0800
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

transfer encoding syntax would be the right term. See

To: "'IETF idn working group'" 
Sent: Wednesday, February 13, 2002 13:24
Subject: Re: [idn] a few more comments on the last call documents


> Kent Karlsson  wrote:
>
> > In the UTR 17 model, Punycode is a "Transfer Encoding Syntax"
(TES),
> >
> > A few other things are TESes: UTF-7, MIME/QP, MIME/BASE64, GB/HZ,
and
> > also the syntaxes \uhhhh of Java/C and &#xhhhhh; of XML.
> >
> > I would not simply refer to Punycode as an "encoding", as to many
that
> > would suggest that it was a Character Encoding Scheme or Character
> > Encoding Form.
>
> Would other Unicode experts concur that the title of the Punycode
draft
> should call it a transfer encoding syntax?  Or if it doesn't really
fit
> into the model at all, should it use a vague term like
"transformation"
> rather than "encoding"?
>
> > > sometimes [copy/paste] just retrieves a string from the GUI
> > > corresponding to exactly what is displayed.
> >
> > Any such system/application is SEVERELY FLAWED.
>
> Probably true, but unfortunately it's also quite common.  It's the
norm
> for X Windows applications.  X is severely flawed in many ways.
>
> AMC
>
>




From owner-idn@ops.ietf.org  Thu Feb 14 13:31: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 NAA05506
	for ; Thu, 14 Feb 2002 13:31:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bQT1-000KBh-00
	for idn-data@psg.com; Thu, 14 Feb 2002 10:18:47 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16bQSz-000KBb-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 10:18:45 -0800
Received: (qmail 9769 invoked by uid 1001); 14 Feb 2002 18:14:41 -0000
Date: 14 Feb 2002 18:14:41 -0000
Message-ID: <20020214181441.21665.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Why IDNA breaks copy-and-paste
References: <20020213163057.29845.qmail@cr.yp.to> <000f01c1b54d$0aac7c70$b4e21081@chalmers95a69n>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

In July 2001, when this failure pattern was pointed out, Costello
admitted that ``getting an IDN for my domain'' would cause failures with
IDNA during his proposed (multi-year) software upgrade. He admitted that
his previous ``nothing will actually break'' comment was ``overstated.''

He claimed that IDNA ``fails in fewer instances'' than other proposals.
So what? IDNA indisputably fails in more instances than the status quo.

Now, several months later, many IDNA proponents once again seem to
believe that they can deploy IDNA right now without breaking anything.
But that belief doesn't stand up to an examination of the facts.

Kent Karlsson writes:
> For "copy and paste" involving a terminal emulator, the
> "application" of interest is the terminal emulator itself.  

This ``application,'' like a browser looking at the output of a web-mail
server, doesn't know where the domain names are, so it can't convert
those names to PunyCode for copy-and-paste.

Bottom line: If the user sees (glyphs for) non-ASCII characters, then
other programs will receive non-ASCII characters (in the local character
encoding). Many of those programs won't know anything about IDNA, so
their domain-name lookups will fail.

How are we supposed to avoid these failures? What are software authors
supposed to do? Why do the IDNA proponents keep dodging this fundamental
question?

> Now, converting from a stream of characters to a stream of
> glyphs is in general a non-trivial step.

Irrelevant. Copy-and-paste grabs characters, not glyphs. You are putting
a huge amount of effort into attacking a stupid copy-and-paste design
that no sane programmer would use.

The current X release has full UTF-8 support; you simply set a UTF-8
locale such as LANG=en_US.UTF-8. Copy-and-paste handles full Unicode.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Thu Feb 14 14:02: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 OAA06492
	for ; Thu, 14 Feb 2002 14:02:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bR2N-000L3h-00
	for idn-data@psg.com; Thu, 14 Feb 2002 10:55:19 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16bR2M-000L3b-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 10:55:18 -0800
Received: (qmail 14075 invoked by uid 1001); 14 Feb 2002 18:54:15 -0000
Date: 14 Feb 2002 18:54:15 -0000
Message-ID: <20020214185415.22425.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] IDNA interoperability failures, once again
References: <20020212090900.13619.qmail@cr.yp.to> <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net> <20020213035531.13155.qmail@cr.yp.to> <20020213144112.GA2327@wonderland.linux.it> <20020213170604.3529.qmail@cr.yp.to> <20020214140018.GA2035@wonderland.linux.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

I'm asking how IDNA is supposed to work on a modern UNIX system with
full support for Unicode and UTF-8.

Programs that convert PunyCode to UTF-8 are creating interoperability
problems. Programs that display PunyCode as is are presenting
gobbledygook to the users.

IDNA appears to be based on the delusion that there are always separate
channels for programs to talk to users and to other programs. I've given
several counterexamples, and explained why many systems are deliberately
engineered to have a unified communications channel.

Anyway, Marco is saying that many UNIX systems don't even have full
Unicode support. This is true. I don't know why he thinks it's relevant.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Thu Feb 14 14: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 OAA08063
	for ; Thu, 14 Feb 2002 14:54:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bRry-000MFj-00
	for idn-data@psg.com; Thu, 14 Feb 2002 11:48:38 -0800
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bRrx-000MFd-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 11:48:37 -0800
Received: from zetnet.co.uk (bts-0580.dialup.zetnet.co.uk [194.247.50.68])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g1EJmUG18450
        for ; Thu, 14 Feb 2002 19:48:31 GMT
Message-ID: <3C6AA33B.EA022DFD@zetnet.co.uk>
Date: Wed, 13 Feb 2002 17:32:43 +0000
From: David Hopwood 
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: Re: [idn] Punycode comment:  hangul reordering
References: <0cae01c1b329$4be05a70$2b19fea9@temp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

Soobok Lee wrote:
> Many of this WG participants may remember that I was the first supporter
> of ACE-Z (PUNYCODE). :-)
> 
> Reordering for chinese letters had met some objections from japanese
> participants, while it could benefit billions of other chinese end users.
> But for reordering for hangul syllables there were no significant objections.

?? The main objections to reordering were on the basis of complexity, and
applied if *any* scripts were reordered.

Re-ordering has already been thoroughly discussed and rejected; I don't
think there is any point in going over that discussion again.

- -- 
David Hopwood 

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPGmeNzkCAxeYt5gVAQFD/AgAlH18BW32H/8t9k9a1ssK/FsXAN5fIiBg
F1nHJ8ov6IqtcPSJ6ZDkoWq3uU7vLPJPwAxBTJlFMkkoyLojg8rcxS18Nogzj5s7
ujpHhZwImUUIuzN4qTKzykTM6e8HNboAraAqtTshpv6vuDl2P7+fBrJq9eWtxEux
YbxQR0CJ1Yges8Tf549cxeDwXPREue3Wue385k7yI7hWn7Uu0FoQqCyrbTCZmyhu
L01v2ginFzN167Bmqp2omTb+B2kna4nCgZonSxI7JCMFD9TcEuS+k7NGL607iSJJ
b2IcAJAF1PNUzfLS0DhvGTzgDoEEjGGRGenDFNCknm4NDycy3qYYrA==
=s3Lj
-----END PGP SIGNATURE-----



From owner-idn@ops.ietf.org  Thu Feb 14 14:54: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 OAA08093
	for ; Thu, 14 Feb 2002 14:54:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bRsH-000MFz-00
	for idn-data@psg.com; Thu, 14 Feb 2002 11:48:57 -0800
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bRsG-000MFs-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 11:48:56 -0800
Received: from zetnet.co.uk (bts-0580.dialup.zetnet.co.uk [194.247.50.68])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g1EJmrG18564
        for ; Thu, 14 Feb 2002 19:48:53 GMT
Message-ID: <3C6AA354.C0FE4DDF@zetnet.co.uk>
Date: Wed, 13 Feb 2002 17:33:08 +0000
From: David Hopwood 
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: IETF idn working group 
Subject: Re: [idn] last call reminder - Hebrew
References: <004501c1ad20$07132b20$0d01000a@jamessonyvaio> <000001c1b24f$0f9b96e0$eb0110ac@qsm3> <20020211214239.GC23357@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

-----BEGIN PGP SIGNED MESSAGE-----

"Adam M. Costello" wrote:
> Jonathan Rosenne  wrote:
> 
> > Hebrew vowel signs etc. (points) should be stripped (mapped out) by
> > nameprep. Unicodes 05B0 to 05B9, 05BB to 05BD, 05BF, 05C1, 05C2, 05C4.
> >
> > Their presence or absence should not make two host names different.
> 
> This is a language-level equivalence issue, similar to
> traditional/simplified Chinese or Danish aa/a-with-ring-above or English
> color/colour.

No, it's a script-level issue. The similar case of Arabic points is also
a script-level issue. (Someone mentioned the Khmer inherent vowels
U+17B4/17B5; that might be similar, but I'm less convinced because they
are apparently only used for phonetic transcription.)

Unlike TC/SC or other language-specific equivalences, mapping out
Hebrew and Arabic points is absolutely trivial to implement, trivial
to specify, and makes sense for all languages using the affected scripts.

- -- 
David Hopwood 

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPGoIaDkCAxeYt5gVAQGIvgf+KIsezBtagosbOwUbGmhmzJ+37mt7fsck
4uLX51cJ3FKdK0w3t1LJjulnDU38AWlE4OwhObpfmLGOA+2M4VocdU7YrlNcrCRD
eONafCMvx+1mbvqOlsOHzsK1mNEtnMtFesc83CXn2vE2y/EQgGZJhTvCDtRNFqtS
4GxHtyVh+xYDb7msGOqHjdKG014ph6uRkGA8rH6dqpPKGuddioRQjSu4Mz4oQm2d
4w9COswN682+i3BGfMYHS6y0s1dZ0eMe2D953OMQTVpOpPmtVsbu2HxNN8kt9GYw
k9Q9dUjyYWa8KGZh8FWqrkOsTMNJZpZf/IHSqdCrLdiuzkSh6hRhkA==
=epwK
-----END PGP SIGNATURE-----



From owner-idn@ops.ietf.org  Thu Feb 14 15:11: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 PAA08509
	for ; Thu, 14 Feb 2002 15:11:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bS9K-000Mji-00
	for idn-data@psg.com; Thu, 14 Feb 2002 12:06:34 -0800
Received: from med131.ndl.net.nu ([216.133.64.131] helo=Thinkpad)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bS9J-000Mjc-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 12:06:33 -0800
Received: from Thinkpad.mail.nic.nu ([127.0.0.1]) by Thinkpad with Microsoft SMTPSVC(6.0.2600.1);
	 Thu, 14 Feb 2002 15:06:10 -0500
Message-Id: <5.1.0.14.2.20020214150446.0353bff8@mail.nic.nu>
X-Sender: bill@mail.nic.nu
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Feb 2002 15:06:09 -0500
To: "D. J. Bernstein" , idn@ops.ietf.org
From: "J. William Semich" 
Subject: Re: [idn] IDNA interoperability failures, once again
In-Reply-To: <20020214185415.22425.qmail@cr.yp.to>
References: <20020212090900.13619.qmail@cr.yp.to>
 <3C6947FF.D252D4A8@ehsco.com>
 <20020212212015.GA3881@nicemice.net>
 <20020212234359.7250.qmail@cr.yp.to>
 <3C69BC31.EB0F7B1C@ehsco.com>
 <20020213023227.GA8158@nicemice.net>
 <20020213035531.13155.qmail@cr.yp.to>
 <20020213144112.GA2327@wonderland.linux.it>
 <20020213170604.3529.qmail@cr.yp.to>
 <20020214140018.GA2035@wonderland.linux.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 14 Feb 2002 20:06:10.0483 (UTC) FILETIME=[0BBCD830:01C1B593]
Sender: owner-idn@ops.ietf.org
Precedence: bulk

To 99% of Internet users, it's not.

Bill Semich

At 01:54 PM 2/14/2002, D. J. Bernstein wrote:
>Anyway, Marco is saying that many UNIX systems don't even have full
>Unicode support. This is true. I don't know why he thinks it's relevant.




From owner-idn@ops.ietf.org  Thu Feb 14 16:34: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 QAA10357
	for ; Thu, 14 Feb 2002 16:34:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bTPL-000OZO-00
	for idn-data@psg.com; Thu, 14 Feb 2002 13:27:11 -0800
Received: from attila.bofh.it ([213.92.8.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bTPL-000OZB-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 13:27:11 -0800
Received: by attila.bofh.it (Postfix, from userid 10)
	id D582E61550; Thu, 14 Feb 2002 22:27:09 +0100 (CET)
Received: by wonderland.linux.it (Postfix/Md, from userid 1001)
	id D5E6B33B5D; Thu, 14 Feb 2002 22:26:55 +0100 (CET)
Date: Thu, 14 Feb 2002 22:26:55 +0100
From: "Marco d'Itri" 
To: idn@ops.ietf.org
Subject: Re: [idn] IDNA interoperability failures, once again
Message-ID: <20020214212655.GA5885@wonderland.linux.it>
References: <3C6947FF.D252D4A8@ehsco.com> <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net> <20020213035531.13155.qmail@cr.yp.to> <20020213144112.GA2327@wonderland.linux.it> <20020213170604.3529.qmail@cr.yp.to> <20020214140018.GA2035@wonderland.linux.it> <20020214185415.22425.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020214185415.22425.qmail@cr.yp.to>
User-Agent: Mutt/1.3.27i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Feb 14, "D. J. Bernstein"  wrote:

 >Anyway, Marco is saying that many UNIX systems don't even have full
 >Unicode support. This is true. I don't know why he thinks it's relevant.
You are misrepresenting my opinion. I'm saying that many people do not
use unicode as their native character set and have no plan to do so.
This means that "just using UTF-8" will not magically work as you
suggest.

-- 
ciao,
Marco



From owner-idn@ops.ietf.org  Thu Feb 14 17:06: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 RAA11259
	for ; Thu, 14 Feb 2002 17:06:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bTqJ-000PDz-00
	for idn-data@psg.com; Thu, 14 Feb 2002 13:55:03 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16bTqI-000PDg-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 13:55:02 -0800
Received: (qmail 30987 invoked by uid 1001); 14 Feb 2002 21:54:00 -0000
Date: 14 Feb 2002 21:53:59 -0000
Message-ID: <20020214215359.25685.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] IDNA interoperability failures, once again
References: <20020212212015.GA3881@nicemice.net> <20020212234359.7250.qmail@cr.yp.to> <3C69BC31.EB0F7B1C@ehsco.com> <20020213023227.GA8158@nicemice.net> <20020213035531.13155.qmail@cr.yp.to> <20020213144112.GA2327@wonderland.linux.it> <20020213170604.3529.qmail@cr.yp.to> <20020214140018.GA2035@wonderland.linux.it> <20020214185415.22425.qmail@cr.yp.to> <20020214212655.GA5885@wonderland.linux.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Marco d'Itri writes:
> "just using UTF-8" will not magically work

Nobody has said it will magically work. Supporting Unicode and UTF-8 has
taken quite a bit of effort. Some programs still need to be fixed.

But none of this is relevant to the current discussion. It is simply not
rational to respond to ``IDNA is extremely harmful and should not be
deployed'' by making claims about the merits of another proposal.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Thu Feb 14 18:18: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 SAA12485
	for ; Thu, 14 Feb 2002 18:18:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bUxT-0000wJ-00
	for idn-data@psg.com; Thu, 14 Feb 2002 15:06:31 -0800
Received: from attila.bofh.it ([213.92.8.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bUxS-0000vk-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 15:06:30 -0800
Received: by attila.bofh.it (Postfix, from userid 10)
	id D296E61859; Fri, 15 Feb 2002 00:06:28 +0100 (CET)
Received: by wonderland.linux.it (Postfix/Md, from userid 1001)
	id 37BE8340B9; Fri, 15 Feb 2002 00:06:19 +0100 (CET)
Date: Fri, 15 Feb 2002 00:06:19 +0100
From: "Marco d'Itri" 
To: idn@ops.ietf.org
Subject: Re: [idn] Why IDNA breaks copy-and-paste
Message-ID: <20020214230619.GA4105@wonderland.linux.it>
Mail-Followup-To: idn@ops.ietf.org
References: <20020213163057.29845.qmail@cr.yp.to> <000f01c1b54d$0aac7c70$b4e21081@chalmers95a69n> <20020214181441.21665.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020214181441.21665.qmail@cr.yp.to>
User-Agent: Mutt/1.3.27i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Feb 14, "D. J. Bernstein"  wrote:

 >Bottom line: If the user sees (glyphs for) non-ASCII characters, then
 >other programs will receive non-ASCII characters (in the local character
 >encoding). Many of those programs won't know anything about IDNA, so
 >their domain-name lookups will fail.
And if the user types non-ASCII characters with his own keyboard then
programs which do not know about IDN will receive non-ASCII characters
and their domain-name lookups will fail. So what?
Users will learn that entering IDN in applications not IDN-enabled does
not work and will update them or use a X applet with an embedde punycode
converter.

 >How are we supposed to avoid these failures? What are software authors
 >supposed to do?
If you really want to know, while waiting for all software to be updated
to the IDN API (which I hope that in simple cases like ping or telnet
would amount to adding a flag to getaddrinfo(3) or something like this)
my plan is to LD_PRELOAD a simple library which will wrap name
resolution library calls and call the new API.
This may not work with more complex programs like a MUA which puts a
domain in a RFC 2822 header, but would fix all simple programs like
ping and telnet (and I think your tcpclient).
And "just entering UTF-8" would still not work for my MUA, because UTF-8
characters are not allowed in mail headers until DRUMS says so.

 >The current X release has full UTF-8 support; you simply set a UTF-8
 >locale such as LANG=en_US.UTF-8. Copy-and-paste handles full Unicode.
As I explained, in most countries you cannot "simply set a UTF-8
locale" because that would damage interoperability with other people
using a native charset, so this is not a generally applicable solution.

-- 
ciao,
Marco



From owner-idn@ops.ietf.org  Thu Feb 14 21:33: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 VAA15226
	for ; Thu, 14 Feb 2002 21:33:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bY3k-0005lP-00
	for idn-data@psg.com; Thu, 14 Feb 2002 18:25:12 -0800
To: "Kent Karlsson" 
cc: "'D. J. Bernstein'" , idn@ops.ietf.org
Subject: Re: [idn] Why IDNA breaks copy-and-paste 
In-reply-to: Your message of "Thu, 14 Feb 2002 12:45:02 +0100."
             <000f01c1b54d$0aac7c70$b4e21081@chalmers95a69n> 
X-URL: http://www.cl.cam.ac.uk/~mgk25/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 14 Feb 2002 12:12:53 +0000
From: Markus Kuhn 
Message-Id: 
Sender: owner-idn@ops.ietf.org
Precedence: bulk

We try to make sure that xterm preserves as much of the original UCS
plaintext that was sent to it as feasible for the purpose of cut&paste.
This is not achieved with high perfection yet in the current version,
for example xterm currently still converts tabs into spaces and drops
combining characters if there are more than two per base character. It
also drops most control characters, in particular it currently does not
preserve SGR. This is supposed to improve in the future, but cut&paste
will always remain a compromise hack in terminal emulator applications.
In particular, do not expect cut&paste to work in any satisfactory way
for bidi scripts in the foreseeable, but they are a hopeless can of
worms anyway for terminal emulators and probabaly should better only be
used with GUI applications in general.

http://www.cl.cam.ac.uk/~mgk25/unicode.html

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: 






From owner-idn@ops.ietf.org  Fri Feb 15 00:43: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 AAA19902
	for ; Fri, 15 Feb 2002 00:43:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16baya-0009ba-00
	for idn-data@psg.com; Thu, 14 Feb 2002 21:32:04 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16bayZ-0009bU-00
	for idn@ops.ietf.org; Thu, 14 Feb 2002 21:32:03 -0800
Received: (qmail 14879 invoked by uid 1001); 15 Feb 2002 05:31:01 -0000
Date: 15 Feb 2002 05:31:01 -0000
Message-ID: <20020215053101.16838.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: [idn] IDNC3: clean, careful, conservative IDNs
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

http://cr.yp.to/proto/idnc3.html

I'm particularly interested in hearing comments from Chinese users. The
IDNC3 framework will allow the TC .traditional and SC .simplified TLDs,
for example.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Fri Feb 15 10:27: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 KAA08116
	for ; Fri, 15 Feb 2002 10:27:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bk0f-000GYn-00
	for idn-data@psg.com; Fri, 15 Feb 2002 07:10:49 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bk0f-000GYh-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 07:10:49 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Fri, 15 Feb 2002 07:27:07 -0800
Message-ID: <004d01c1b634$6066f7c0$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "D. J. Bernstein" , 
References: <20020215053101.16838.qmail@cr.yp.to>
Subject: Re: [idn] IDNC3: clean, careful, conservative IDNs
Date: Fri, 15 Feb 2002 10:21:00 -0500
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

Hi Dan,

> http://cr.yp.to/proto/idnc3.html
>
> I'm particularly interested in hearing comments from Chinese users.
The
> IDNC3 framework will allow the TC .traditional and SC .simplified
TLDs,
> for example.
>

You words are music to my ears.      ;-)

However, first things first... provide the means for the users to
start using IDNs first. (I do *not* see the need to replace IDNA.)
Then later on, for needs that cannot be met with the existing
technology, we can work on other ways to improve/help (including
John's idea for a search/directory.)

Thanks,
Ben







From owner-idn@ops.ietf.org  Fri Feb 15 12:21: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 MAA12339
	for ; Fri, 15 Feb 2002 12:21:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16blwV-000I5G-00
	for idn-data@psg.com; Fri, 15 Feb 2002 09:14:39 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16blwU-000I5A-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 09:14:38 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4TYncVoZ3VcB04ei9jxyzIw==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GTP3LFRG; Fri, 15 Feb 2002 12:13:16 EST
To: Markus.Kuhn@cl.cam.ac.uk
Cc: kentk@md.chalmers.se, djb@cr.yp.to, idn@ops.ietf.org
Date: Fri, 15 Feb 2002 09:24:09 -0800
Subject: Re: [idn] Why IDNA breaks copy-and-paste
Message-ID: <20020215.092409.-262871.1.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-17,19-20,22-25,27-38
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello, Markus:

Thanks for your input into the discussion.  Although
I  myself not an expert in termcap, your experience
in making " xterm preserves as much of the original UCS
plaintext " is  what I expected to hear from someone.  

This is a part of my reasoning to treat Latin script at the 
same lavel with other scripts, not make it a special 
case to squeeze it into DNS. 

Afterall, language issues should be handled by GUI
applicantions.

Thanks again.

Liana 

On Thu, 14 Feb 2002 12:12:53 +0000 Markus Kuhn 
writes:
> We try to make sure that xterm preserves as much of the original UCS
> plaintext that was sent to it as feasible for the purpose of 
cut&paste.
> This is not achieved with high perfection yet in the current  version,
> for example xterm currently still converts tabs into spaces and  drops
> combining characters if there are more than two per base character. 
> It  also drops most control characters, in particular it currently does

> not preserve SGR. This is supposed to improve in the future, but 
> cut&paste  will always remain a compromise hack in terminal emulator 
> applications. In particular, do not expect cut&paste to work in any 
> satisfactory  way  for bidi scripts in the foreseeable, but they are a 
> hopeless can of  worms anyway for terminal emulators and probabaly 
> should better only  be used with GUI applications in general.
> 
> http://www.cl.cam.ac.uk/~mgk25/unicode.html
> 
> Markus
> 



From owner-idn@ops.ietf.org  Fri Feb 15 14: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 OAA17005
	for ; Fri, 15 Feb 2002 14:30:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bnvK-000JnZ-00
	for idn-data@psg.com; Fri, 15 Feb 2002 11:21:34 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bnvJ-000JnK-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 11:21:33 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56057 for idn@ops.ietf.org; Fri, 15 Feb 2002 13:20:55 -0600
Message-ID: <3C6D5FB7.E3F6AAA4@ehsco.com>
Date: Fri, 15 Feb 2002 13:21:27 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@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


"Eric A. Hall" wrote:

> > I think the intended title of this document is "Stringprep Profile
> > for Internationalized Domain Names".
> 
> Based on a cursory analysis, this document is suitable as a standalone
> description of i18n domain names

Looking at this in more detail, I take that back. The i18n "domain name"
specification needs to allow any valid UCS character code, and must not be
restricted to hostname characters. As has been discussed multiple times,
there are some domain names which are not hostnames, and this model will
likely be valid in the future as well.

The obvious example of this is mailbox names. Some future version of an
email specification may allow (for example) the use of non-combining
characters in mailbox names. However, mailbox names are often stored in
DNS labels, and under the current arrangement, those mailbox names would
be normalized and lowercased as part of this process. In essence, the
rules which are currently provided impose restrictions on any future
mailbox name designs which the representative working group may come up
with in the future.

That is the obvious example. There are less-obvious examples of the same
concern. However, in general, there should be a different stringprep
profile for i18n "domain names" than for "host names", and IDNA (among
other encoding or tagging sequences) must allow for all of these
variations, rather than imposing artificial restrictions in this area.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Fri Feb 15 15:12: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 PAA18167
	for ; Fri, 15 Feb 2002 15:12:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16boQp-000KM4-00
	for idn-data@psg.com; Fri, 15 Feb 2002 11:54:07 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16boQo-000KLx-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 11:54:06 -0800
Received: (qmail 29091 invoked by uid 1001); 15 Feb 2002 19:53:03 -0000
Date: 15 Feb 2002 19:53:03 -0000
Message-ID: <20020215195303.2128.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Why IDNA breaks copy-and-paste
References: <000f01c1b54d$0aac7c70$b4e21081@chalmers95a69n> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Markus Kuhn writes:
> xterm currently still converts tabs into spaces and drops
> combining characters if there are more than two per base character. It
> also drops most control characters, in particular it currently does not
> preserve SGR.

The ability to copy and paste tabs and font selections isn't relevant to
IDNs. However, the limit of two combining characters may interfere with
some languages. Why two?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Fri Feb 15 16:40: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 QAA20452
	for ; Fri, 15 Feb 2002 16:40:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bpzt-000Lkw-00
	for idn-data@psg.com; Fri, 15 Feb 2002 13:34:25 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bpzs-000Lkq-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 13:34:24 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4OKnKEp1e03hrYDaP+2gBuQ==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GTQJHV55; Fri, 15 Feb 2002 16:34:01 EST
To: Markus.Kuhn@cl.cam.ac.uk
Cc: liana.ydisg@juno.com, kentk@md.chalmers.se, djb@cr.yp.to, idn@ops.ietf.org
Date: Fri, 15 Feb 2002 13:44:55 -0800
Subject: Re: [idn] Why IDNA breaks copy-and-paste
Message-ID: <20020215.134456.-264303.1.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0,2-4,6-47
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye 
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> To I would be extremely careful with using cut&paste in order to
> transfer unique identifiers from a terminal emulator to an 
application.
> This can end in an endless can of worms, if Hebrew, Arabic or Syriac 
> are involved, and we haven't even begun to understand how to handle 
> that,  even after scratching out heads for a year in heated discussions
on 
> the  linux-utf8 and i18n@xfree86.org mailing lists.

Cut&paste should have three levels of handling:

1. traditional ASCII text, consistent with URI requirement;
   -Keep termcap as is.  To expand on that, there are already
  tons of published books about processing various scripts 
  with various encoding on it, but the point may not be obvious 
  to many.   To tug Latin into DNS is another example:-)
  I don't  want to dive into that mess.

> The other critical security issue related to DNS are of course
> homoglyphs. The same glyph appears in Unicode many times as separate
> characters that are part of different alphabets or different usage
> backgrounds, Latin, Cyrillic, and Greek "A" being just one example.
> 
> Markus

2. New IDN identifiers, a subset of UCS:
  - Try to come up a new universal identifier character table 
   to eliminate script and character confusions. Thus language 
   tag has to be used, and limited mixed scripts can be 
   implemented, and IDN Cut&paste can be verified.
   
3. The rest of UCS characters, bidi, Chinese TC/SC n-1 
  cases to be  handled.  This level traditionally is handled in 
  applicantion level. With UAX15, UTR21 done at UTC, it is 
  possible to  have a universal interface for all applications 
  to implement,  but this is not the job in DNS or IDN. 

If this IETF decides to come up with a universal interface for 
IDN, then it is possible to Cut&Paste on the third level cross
major applications such as Web pages.  However, there is little 
information for me to say how much the IDNA is going to do, 
since there is no specification about scripts and character 
confusions in IDNA, then it is must belong to DNS level of 
above.  No wander the Chinese group has organized an 
official protest.
 
Regards, 

Liana



From owner-idn@ops.ietf.org  Fri Feb 15 17:24: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 RAA21678
	for ; Fri, 15 Feb 2002 17:24:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bqdW-000MMr-00
	for idn-data@psg.com; Fri, 15 Feb 2002 14:15:22 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bqdN-000MMf-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 14:15:13 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16bqdM-0005yE-00
	for ; Fri, 15 Feb 2002 14:15:12 -0800
Date: Fri, 15 Feb 2002 22:15:12 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020215221512.GB22341@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C6D5FB7.E3F6AAA4@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> The i18n "domain name" specification needs to allow any valid UCS
> character code,

You might be able to argue that it should allow all valid code points,
but I don't see why it's *necessary*.  Since IDNA will be the first
specification to say anything about Unicode characters in domain names,
later specifications will know exactly which code points they must live
without.  It's not as if IDNA's prohibitions will cause incompatibilites
with existing IDN-related standards.  New IDN-related standards will
cause incompatibilities if they attempt to use code points prohibited by
IDNA.

> and must not be restricted to hostname characters.

Domain names in IDNA are not restricted to host name characters.  Only
host names are.  See step 3 of ToASCII.

(If you're concerned about the ASCII control characters and space, which
indeed are prohibited in the current Nameprep draft, then relax, we've
seen the flaw, and those prohibitions are being removed.)

> However, mailbox names are often stored in DNS labels, and under the
> current arrangement, those mailbox names would be normalized and
> lowercased as part of this process.

This problem already exists to some extent with ASCII mailbox names.
Sticking an ASCII mailbox name (which is allowed by RFC 822 to be
case-sensitive) in a domain label (which is defined by RFC 1035 to be
case-insensitive) is already a dubious proposition.

> In essence, the rules which are currently provided impose restrictions
> on any future mailbox name designs which the representative working
> group may come up with in the future.

The email working group has at least two options:  They can either
take IDNA (which was designed for domain labels) and apply it as-is to
mailbox names (even though it wasn't designed for that) and live with
the implications, or they can define their own way of representing
internationalized mailbox names as ASCII strings (which might bear some
resemblance to IDNA and might reuse components).  Either way, they will
interoperate with IDNA just as well (or as badly) as ASCII mailbox names
interoperate with ASCII domain names today.

> there should be a different stringprep profile for i18n "domain names"
> than for "host names"

There effectively is.  Nameprep is the profile for domain names, and
ToASCII adds a few more restrictions for host names.

The case-folding of all domain names (not just host names) is consistent
with the existing DNS, which uses case-insensitive matching for all
domain names (not just host names).

AMC



From owner-idn@ops.ietf.org  Fri Feb 15 19:13: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 TAA23674
	for ; Fri, 15 Feb 2002 19:13:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bsB8-000NeM-00
	for idn-data@psg.com; Fri, 15 Feb 2002 15:54:10 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bsB7-000NeG-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 15:54:09 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56090 for idn@ops.ietf.org; Fri, 15 Feb 2002 17:53:33 -0600
Message-ID: <3C6D9F9E.D300224D@ehsco.com>
Date: Fri, 15 Feb 2002 17:54:06 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@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 i18n "domain name" specification needs to allow any valid UCS
> > character code,
> 
> You might be able to argue that it should allow all valid code points,
> but I don't see why it's *necessary*.  Since IDNA will be the first
> specification to say anything about Unicode characters in domain names,
> later specifications will know exactly which code points they must
> live without.

Why must anything live without some reasonable characters just because
IDNA didn't see the reason for it at this particular moment? There is no
reason to impose any such restriction, so I fail to see why it should be
done in the first place. Perhaps you should argue why this restriction
needs to be in place?

> The email working group has at least two options:  They can either
> take IDNA (which was designed for domain labels) and apply it as-is to
> mailbox names (even though it wasn't designed for that) and live with
> the implications, or they can define their own way of representing
> internationalized mailbox names as ASCII strings (which might bear
> some resemblance to IDNA and might reuse components).  Either way,
> they will interoperate with IDNA just as well (or as badly) as ASCII
> mailbox names interoperate with ASCII domain names today.

Why can't they be accomodated now? Will this flexibility break something
that I don't know about? I mean, why come up with YET ANOTHER ACE ENCODING
just for email addresses or some other data-type which happens to get
stored in DNS sooner or later, when we can design for flexibility right
now? Why?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Fri Feb 15 19:58: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 TAA24051
	for ; Fri, 15 Feb 2002 19:58:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bt1f-000OKn-00
	for idn-data@psg.com; Fri, 15 Feb 2002 16:48:27 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bt1e-000OKh-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 16:48:26 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16bt1e-0006Np-00
	for ; Fri, 15 Feb 2002 16:48:26 -0800
Date: Sat, 16 Feb 2002 00:48:26 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020216004825.GD22341@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C6D9F9E.D300224D@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> Why must anything live without some reasonable characters just because
> IDNA didn't see the reason for it at this particular moment?

Exactly which "reasonable" characters are you talking about?  The
prohibited list in nameprep is pretty small, and they're all characters
that you'd have to be somewhat crazy to want to use in domain names.

> I mean, why come up with YET ANOTHER ACE ENCODING just for email
> addresses or some other data-type which happens to get stored in DNS
> sooner or later, when we can design for flexibility right now?  Why?

I asked long ago, shouldn't we try to design a solution that handles
both domain labels and email address local-parts?  I was told no, that's
out of scope, a different working group will take care of email address
local parts.  I share your concern, but I got the impression that this
was not open for debate.

AMC



From owner-idn@ops.ietf.org  Fri Feb 15 20:55: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 UAA24720
	for ; Fri, 15 Feb 2002 20:55:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16btz0-000P33-00
	for idn-data@psg.com; Fri, 15 Feb 2002 17:49:46 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16btyz-000P2x-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 17:49:45 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56096 for idn@ops.ietf.org; Fri, 15 Feb 2002 19:49:09 -0600
Message-ID: <3C6DBAB6.8B85E778@ehsco.com>
Date: Fri, 15 Feb 2002 19:49:42 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@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:

> Exactly which "reasonable" characters are you talking about? 

All UCS character codes are valid for something, and anything can be
stored in DNS as an owner domain name (think TXT) or as data (SOA, RP, or
as-yet-invented). The problem with the current spec is that case-folding
and normalization will impose restrictions on these assignments. This is
inappropriate for a generic i18n domain name label syntax.

On a secondary note, normalization and lowercasing are problems having to
do with hostnames, and those should be enforced by delegation and
application rules. Note well: the existing DNS does not enforce hostname
rules anywhere else, we should be mimic'ing this behavior. The hostname
rules should only define, the codecs should only encode/decode, and the
apps/protos/formats should enforce.

> The prohibited list in nameprep is pretty small, and they're all
> characters that you'd have to be somewhat crazy to want to use in
> domain names.

I think you meant hostname here. Remember that hostname rules apply to
delegations. Domain name rules are a broader category which also include
things like SRV, email addresses, and so forth.

> I asked long ago, shouldn't we try to design a solution that handles
> both domain labels and email address local-parts?  I was told no,
> that's out of scope, a different working group will take care of
> email address local parts.  I share your concern, but I got the
> impression that this was not open for debate.

The email people will come up with their own character restrictions, which
is exactly the point. The namespace should ALLOW them to come up with
mapping rules, case-folding, normalization and whatever other rules they
wish. I mean, if they want to have a perverse mailbox sequence, why
shouldn't they? The codecs should only deal with inputs and outputs. I'm
pretty certain that's what you were told.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Fri Feb 15 21:03: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 VAA24848
	for ; Fri, 15 Feb 2002 21:03:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bu6S-000P9o-00
	for idn-data@psg.com; Fri, 15 Feb 2002 17:57:28 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bu6R-000P9i-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 17:57:27 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56099 for idn@ops.ietf.org; Fri, 15 Feb 2002 19:56:51 -0600
Message-ID: <3C6DBC83.DA812731@ehsco.com>
Date: Fri, 15 Feb 2002 19:57:23 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com>
Content-Type: multipart/mixed;
 boundary="------------09F5816E371845BB23A4A433"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------09F5816E371845BB23A4A433
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


See attached.

This WG should define the global rules as in section 3[.0] (plus a
dot-mapping syntax), the generic domain name rules as in section 3.1 as a
minimum definition for other data-types to be built on, and the hostname
rules as in section 3.2. Everything else can go into an update of STD13.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
--------------09F5816E371845BB23A4A433
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: 
Received: from psg.com ([147.28.0.62] verified)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.4.8)
  with ESMTP-TLS id 18542 for lists@ehsco.com; Tue, 04 Dec 2001 02:37:05 -0600
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16BX8U-0000DM-00
	for idn-data@psg.com; Wed, 05 Dec 2001 00:10:34 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16BX8T-0000Cu-00
	for idn@ops.ietf.org; Wed, 05 Dec 2001 00:10:33 -0800
Received: from [207.65.3.26] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.4.8)
  with ESMTP-TLS id 18538 for idn@ops.ietf.org; Tue, 04 Dec 2001 02:10:20 -0600
Message-ID: <3C0DD610.F50F947B@ehsco.com>
Date: Wed, 05 Dec 2001 02:08:48 -0600
From: "Eric A. Hall" 
Organization: EHS Company
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IDN 
Subject: [idn] naming syntax rules
Content-Type: text/plain; charset=us-ascii
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


James has been needling me to put together a second summary of the naming
rules in time for the IETF meeting. However, I have been extremely busy
lately (it is 3 am in a strange hotel room) but I wanted to at least
scratch together enough material for the concepts to be tangible.

The following text is by no means complete. It's hardly just begun.
However, it illustrates what the scope will be, exposes some of the open
issues, and may be usable as a touchstone to see if this whole IDN thing
is going to work or not.

What I mean by that is, if systems are going to work with IDNs in their
raw form (not encoded form, but raw form) these are the rules they will
have to work with. If these rules are too complex, the whole approach has
to be reconsidered. That will affect a lot of other things, including ACE.

The basic idea here is to declare formal data-types for labels, and to
incorporate the data-types into syntaxes for applications and protocols to
use when they need to interact with domain names.


1.	Summary

This memo describes two sets of definitions which are necessary for the
consistent and reliable use of internationalized domain names across the
Internet. First and foremost, this memo specifies the rules which govern
the structure and syntax of internationalized domain names in various
scenarios, and also describes their legitimate characters and any
normalization which may be required. Secondarily, this memo also clarifies
and extends usage rules of common resource records so that
internationalized domain names can be stored and exchanged (either as
resource record owner domain names or as resource record data) in a form
which is consistent across all usage environments.


2.	Introduction

There are many issues which affect the characters that are desirable for
use in DNS domain names. Among these considerations are obvious aspects
such as breadth, as well as less-obvious aspects such as normalized forms
of particular character sequences, comparison efficiencies, and more.

The general consensus of the IDN working group is that domain names should
use a mildly-restricted subset of the character codes and arrangement
sequences which are documented in the UCS for use with languages, as this
subset excludes non-verbal symbols and spurious punctuation which are
likely to be problematic, while still allowing international domain names
to be created. Furthermore, the consensus is that these character
sequences should be normalized and converted to lowercase [in that order?]
wherever this is possible, since this will provide the tightest
syntactical representation of the supported characters with the least
amount of ambiguity.

While both of those objectives are highly desirable (and are met in most
of the scenarios), there are many instances where these objectives are
incompatible with existing practice. For example, existing
(STD13-compliant) DNS implementations are allowed to use domain names
which contain any eight-bit character code (0x00 through 0xFF), while
there are some protocol models which specifically require the use of
punctuation (SRV requires underscore, for example), while some resource
records can contain domain names that combine both of these elements (SOA
and RP both provide email addresses as domain name labels that can
contain, and those can use punctuation or case-specific US-ASCII letters).

In order to facilitate these divergent requirements, this memo describes
multiple types of domain name labels, including their valid characters,
any case-conversions and/or normalizations which may be required, and so
forth.

Furthermore, in order to ensure that these rules are consistently
implemented (and to minimize damage when they are not), this memo also
states which label data-types are valid for use with many of the common
resource records.

Cumulatively, this means that a system which attempts to use an
internationalized domain name for a specific purpose will have to be aware
of the rules which govern the resource record which provides that service,
and will have to be aware of the rules which govern the domain name
data-types which are valid for that resource record. For example, if an
application knows that an internationalized domain name will be used for a
forward lookup, it will have to be aware of the label data-types that are
usable with A (or AAAA) resource records, and must ensure that the domain
name is processed (normalized and lower-cased, in this example) before it
is used.

NOTE: Legacy systems which use a backwards-compatible encoding scheme for
access to resources with internationalized domain names will not be
required to perform any of these tests. However, systems which embrace
internationalized domain names as specific data (EG, any system which
encodes or decodes an internationalized domain name as explicit data) will
need to be aware of these issues and will likely be required to enforce
their usage.


3.	Domain Names and Label Data-Types

An internationalized domain name is a sequence of labels which are
encapsulated in a message. The message may provide the labels as separate
units of data (as is the case with DNS), or may provide them as a series
of dot-separated textual strings (as is the case when domain names are
"written-out" in protocol or application data streams).

In global terms, an internationalized domain name has the following
characteristics:

*	Series of labels (1*label)

*	Maximum cumulative length of 255 UCS character codes (not necessarily
codes with matching characters, and most definitely not octets or any
encoded representation). This limit includes any separators which may be
provided (such as the full-stop character commonly used as a separator
when the domain name is written), and also includes one character for the
root domain (the trailing dot).

The labels that make up a domain name will vary according to the
contextual use of the domain name.


3.1.	Opaque Labels

Some functions can use domain names which consist of unstructured or
unknown labels. For example, a TXT resource record can describe anything,
and as such, it can use any sequence of UCS characters for its owner
domain name.

Opaque labels require no processing on the part of the application which
is using the domain name. It is the responsibility of the user to provide
the domain name to the application in its correct case and/or
normalization form.

Opaque labels have the following characteristics:

*	Any valid UCS character code (not necessarily a valid UCS character).

*	Minimum length of one UCS character code.

*	Maximum length of 63 UCS character codes.

NOTE: Even though a domain name may sometimes consist of a variable number
of opaque labels, most domain names will also contain at least some host
labels. In those cases, the entire domain name should be provided as a
series of opaque labels, and the host labels should be determined
beforehand. For example, a CNAME resource record can reference anything,
including an A RR that consists entirely of host labels, or a TXT RR that
consists of a mixture of opaque and host labels. As such, it will depend
on the formats in use by the alias target, and will inherit those
attributes.


3.2.	Host Identifier Labels

Most functions will use domain names to identify a host, either directly
or indirectly. For example, a host may be identified by a relative domain
name which consists of only a local label, or by an FQDN which contains a
series of host labels. Since all forms must be supportable, all namespace
delegation functions also use the host label syntax.

The UCS characters provided in host labels are required to be converted to
lowercase and normalized according to the rules in [nameprep] before they
are processed. Servers are likely to treat such labels as exact matches of
the encoded data, so it is imperative that applications perform this work
before they encode the label into a DNS query.

Host labels are used for any lookups, protocol actions, or message formats
which specifically make use of internationalized domain names for host
identification purposes.

Host labels have the following characteristics:

*	UCS characters from the following ranges:

"letters" [need a property]

characters with number property [?]

characters with diacritical mark property [?]

hyphen-minus (U+002D)

*	MUST be converted to lowercase according to [nameprep].

*	MUST be normalized according to [nameprep].

*	First and last characters in the label MUST NOT be a diacritical mark or
hyphen-minus.

*	Minimum length of two characters.

*	Maximum length of 63 characters.


3.3.	ASCII Labels

Some functions require labels that contain extended punctuation, but which
also require case-neutral comparisons. The most readily apparent of these
usages is the SRV resource record, which makes use of the underscore
character (U+005F) and case-neutral US-ASCII in the owner labels.

ASCII labels have the following characteristics:

*	Any printable character from US-ASCII (0x21 through 0x7E, inclusive).

*	SHOULD be converted to lowercase as specified in [nameprep] (note that
servers are required to perform case-neutral comparisons, but certain
tools will likely prefer to generate and use lower-case wherever possible,
so lowercase is the preferred form). All comparison operations on these
domain names MUST be performed in a case-neutral form.

*	Minimum length of one character.

*	Maximum length of 63 characters.

NOTE: some resource records may define tighter restrictions.

NOTE: Even though a domain name may sometimes consist of a variable number
of ASCII labels, most domain names will also contain at least some host
labels. In those cases, the entire domain name should be provided as a
series of opaque labels, and the ASCII and host labels should be
determined beforehand.


3.4.	Mailbox Labels

Some functions provide SMTP mailboxes as labels within domain names. For
example, the SOA and RP resource records both provide email addresses,
with the first label providing a mailbox (local-part) of the address, and
with the remainder of the labels providing the delivery domain of the
address.

In order for these resources to be accessible, applications must process
labels which are known to contain email addresses through these rules.
This means that data must be provided in a non-normalized, non-lowercased
form, and must be restricted to the range of characters which are valid,
as specified in section XX of RFC 2822. Until RFC 2822 is deprecated or
until such a time as UCS characters can be stored in the mailbox portion
of Internet standard email addresses, the mailbox label is to processed
according to the rules set forth in RFC 2822.

There are two additional rules which govern this data-type:

*	Minimum length of one character.

*	Maximum length of 63 characters.

NOTE: mailbox labels can contain a large number of special characters such
as spaces or full-stop. These characters may require escaping as described
in section XX of this document.

NOTE: Mailbox labels are NOT a subset of the ASCII labels. Mailbox labels
are case-sensitive, while ASCII labels are case-neutral.


4.	Resource Records

The following structure is used to describe resource records and their
usage of internationalized domain names and labels.

  <[data] [data] [...]>

A, always provides a host identifier

<1*host>  <[IPv4 address]>


AAAA, always provides a host identifier

<1*host>  <[IPv6 address]>


CNAME, can reference anything, can target anything

<1*opaque>  <[1*opaque]>


NS, references a host, provides a host identifier

<1*host>  <[1*host]>


SOA, references a host (delegation), provides host identifier, email
address, and custom data

<1*host>  <[1*host] [1mailbox (*host)] [serial] [refresh] [retry]
[expire] [ttl]>


WKS, always provides a host identifier

<1*host>  <[XX] [XX]>


PTR, can reference anything, must inherit target attributes

<1*opaque>  <[1*opaque]>


HINFO, references a host, provides RR-specific data

<1*host>  <[hardware] [opsys]>


MX, references a host, provides a preference and a host identifer

<1*host>  <[preference] [1*host]>


TXT, can reference anything, provides free-text data

<1*host>  <[text]>


RP, can reference anything, provides email address and a pointer to a TXT
RR

<1*opaque>  <[1mailbox (*host)]> <1*opaque>


SRV, references a protocol (which is specified using the ASCII data-type),
provides preference values and a host identifier

<1*ASCII>  <[priority] [weight] [port] [1*host]>

[NOTE: cannot define <2ASCII *HOST> because not all SRV protocol labels
are just _service._transport]



--------------09F5816E371845BB23A4A433--




From owner-idn@ops.ietf.org  Fri Feb 15 21:13: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 VAA24962
	for ; Fri, 15 Feb 2002 21:13:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16buHk-000PJ9-00
	for idn-data@psg.com; Fri, 15 Feb 2002 18:09:08 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16buHj-000PJ3-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 18:09:07 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56101 for idn@ops.ietf.org; Fri, 15 Feb 2002 20:08:31 -0600
Message-ID: <3C6DBF40.6F5EDC83@ehsco.com>
Date: Fri, 15 Feb 2002 20:09:04 -0600
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] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <3C6DBC83.DA812731@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


"Eric A. Hall" wrote:

> 3.2.    Host Identifier Labels

> *       Minimum length of two characters.

ps--that requirement was dropped in subsequent discussion, since minimum
length is a function of the delegation authority's policy (.com has
minimum length of 2 chars, .info has minimum length of 3, internal
delegations have minimum length of 1, etc).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Fri Feb 15 21:43: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 VAA26249
	for ; Fri, 15 Feb 2002 21:43:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bukx-000Pjo-00
	for idn-data@psg.com; Fri, 15 Feb 2002 18:39:19 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bukw-000Pji-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 18:39:18 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Fri, 15 Feb 2002 18:55:34 -0800
Message-ID: <001d01c1b694$8dd13e40$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" 
To: "ben" , "D. J. Bernstein" ,
        
References: <20020215053101.16838.qmail@cr.yp.to> <004d01c1b634$6066f7c0$cd462b18@mtag.phub.net.cable.rogers.com>
Subject: Re: [idn] IDNC3: clean, careful, conservative IDNs
Date: Fri, 15 Feb 2002 21:49:27 -0500
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

> You words are music to my ears.      ;-)
>
> However, first things first... provide the means for the users to
> start using IDNs first. (I do *not* see the need to replace IDNA.)
> Then later on, for needs that cannot be met with the existing
> technology, we can work on other ways to improve/help (including
> John's idea for a search/directory.)
>

By the way, I want to apologize to anyone who may find this approach
offensive.  Unfortunately, if this WG is waiting for everyone to say
"Yes, I agree and I have no objections" before moving forward with
IDNs then the WG may as well wait for the cows to come home.

Thanks,
Ben







From owner-idn@ops.ietf.org  Fri Feb 15 22: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 WAA28401
	for ; Fri, 15 Feb 2002 22:55:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bvrn-0000gm-00
	for idn-data@psg.com; Fri, 15 Feb 2002 19:50:27 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bvrm-0000gg-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 19:50:26 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16bvrl-0000VY-00
	for ; Fri, 15 Feb 2002 19:50:25 -0800
Date: Sat, 16 Feb 2002 03:50:25 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020216035025.GA1681@nicemice.net>
Reply-To: IETF idn working group 
References: <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C6DBAB6.8B85E778@ehsco.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Eric A. Hall"  wrote:

> The problem with the current spec is that case-folding and
> normalization will impose restrictions on these assignments.  This
> is inappropriate for a generic i18n domain name label syntax.  On a
> secondary note, normalization and lowercasing are problems having to
> do with hostnames

The existing DNS requires *all* domain labels to be case-insensitive,
not just host labels.  See RFC 1035.  So domain names are already
inappropriate for any data types that are case-sensitive.

> > The prohibited list in nameprep is pretty small, and they're all
> > characters that you'd have to be somewhat crazy to want to use in
> > domain names.
> 
> I think you meant hostname here.  Remember that hostname rules apply to
> delegations.  Domain name rules are a broader category which also include
> things like SRV, email addresses, and so forth.

I understand that not all domain names are host names.  I meant domain
names.  Have you actually looked at the prohibited list in Nameprep?  I
think it will be extremely rare that someone wishes they could use one
of those characters in a domain name (of any type).

> The email people will come up with their own character restrictions,
> which is exactly the point.  The namespace should ALLOW them to come
> up with mapping rules, case-folding, normalization and whatever other
> rules they wish.  I mean, if they want to have a perverse mailbox
> sequence, why shouldn't they?  The codecs should only deal with inputs
> and outputs.  I'm pretty certain that's what you were told.

I was basically told not to discuss email local-parts on this mailing
list.

AMC



From owner-idn@ops.ietf.org  Fri Feb 15 23:04: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 XAA28513
	for ; Fri, 15 Feb 2002 23:04:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bw0S-0000pL-00
	for idn-data@psg.com; Fri, 15 Feb 2002 19:59:24 -0800
Received: from friendly.realnames.com ([63.251.238.102])
	by psg.com with smtp (Exim 3.33 #1)
	id 16bw0R-0000pF-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 19:59:23 -0800
Received: (qmail 23105 invoked by uid 104); 16 Feb 2002 03:59:22 -0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.82837 secs); 16 Feb 2002 03:59:22 -0000
Received: from heaven.internal.realnames.com (10.1.5.39)
  by friendly.realnames.com with SMTP; 16 Feb 2002 03:59:21 -0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1533]) by heaven.internal.realnames.com
	Mail essentials (server 2.422) with SMTP id: <291717@heaven.internal.realnames.com>
	 for ; Fri, 15 Feb 2002 7:54:28 PM -0800
	smtpmailfrom  
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Feb 2002 19:58:44 -0800
Message-ID: <7FC3066C236FD511BC5900508BAC86FE9197BF@trestles.internal.realnames.com>
From: Yves Arrouye 
To: "'Eric A. Hall'" ,
        Dan Oscarsson
	 
Cc: idn@ops.ietf.org
Subject: RE: [idn] WG last call documents
Date: Fri, 15 Feb 2002 19:56:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> > To make this work, we need ONE stringprep plus ACE.
> > One that can be used on ALL labels in DNS.
> 
> We have been through this subject many times. STD13 binary domain names
> and i18n host names are fundamentally incompatible. One specification will
> not suffice.

Clearly. So is this:

"IDNA-aware applications MUST be able to work with both
non-internationalized labels (those that conform to [STD13]
and [STD3]) and internationalized labels."

going to go away from the IDNA document? It is misleading. Or maybe replaced
with:
 
"IDNA-aware applications MUST be able to work with both
non-internationalized ASCII labels (those that conform to [STD13]
and [STD3]) and internationalized labels."

(where ASCII should be replaced by some other definition since 0000..0020
and U+007F are prohibited by Nameprep-07; unless Nameprep is changed to
allow them since ToASCII now has an explicit "hostname" step).

YA




From owner-idn@ops.ietf.org  Fri Feb 15 23:42: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 XAA29267
	for ; Fri, 15 Feb 2002 23:42:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bwXX-0001IY-00
	for idn-data@psg.com; Fri, 15 Feb 2002 20:33:35 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bwXW-0001IS-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 20:33:34 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56110 for idn@ops.ietf.org; Fri, 15 Feb 2002 22:32:58 -0600
Message-ID: <3C6DE11B.53DB2D14@ehsco.com>
Date: Fri, 15 Feb 2002 22:33:31 -0600
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] WG last call documents
References: <3C66B609.7A538AC7@ehsco.com> <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <20020216035025.GA1681@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 problem with the current spec is that case-folding and
> > normalization will impose restrictions on these assignments.  This
> > is inappropriate for a generic i18n domain name label syntax.  On a
> > secondary note, normalization and lowercasing are problems having to
> > do with hostnames
> 
> The existing DNS requires *all* domain labels to be case-insensitive,
> not just host labels.  See RFC 1035.  So domain names are already
> inappropriate for any data types that are case-sensitive.

The rules that govern STD13 labels only apply to STD13 labels. This is
somewhat irrelevant to the subject at hand.

The rules for i18n domain names can say that a domain name contains
explicit character codes. If the app/user is in the ToASCII step then the
label is not an STD13 label. Different rules can apply for those labels.
Note that I am not saying that the rules should be enforced by ToASCII
(they should be enforced by the applications that generate the domain
names), but that if the label needs to go through ToASCII then it is an
i18n domain name, and not an STD13 domain name. Conversely, if the label
does not need to go through ToASCII or if it falls out of ToASCII
unmolested, then it is an STD13 domain name.

> > > The prohibited list in nameprep is pretty small, and they're all
> > > characters that you'd have to be somewhat crazy to want to use in
> > > domain names.
> >
> > I think you meant hostname here.  Remember that hostname rules apply
> > to delegations.  Domain name rules are a broader category which also
> > include things like SRV, email addresses, and so forth.
> 
> I understand that not all domain names are host names.  I meant domain
> names.  Have you actually looked at the prohibited list in Nameprep?  I
> think it will be extremely rare that someone wishes they could use one
> of those characters in a domain name (of any type).

It's the case-folding and normalization that I'm worried about. We should
not be enforcing this kind of reduction on every label that can be stored
in the namespace. And if we can make that distinction, why worry about
prohibitions? Even the issue with leading combining characters is
something that can be foisted onto the hostname subset rules, and simply
noted in the domain name rules as an issue that additional subset
specifications should be aware of.

If there are some codes that flat-out break IDNA which can be REASONABLY
withheld from the generic i18n domain name rules, then by all means, those
should be prohibited. But for the most part, everything that has
historically been described in nameprep should be in the i18n hostname
rules and enforced by the applications, protocols and data-formats. The
generic i18n domain name rules should be as flexible as possible, and IDNA
should only encode/decode the generic i18n domain names.

This model will allow additional subordinate profiles to be defined by any
other WG as needed (EG, mailbox names), and IDNA will still function as
expected. Too many restrictions and we will end up with label- and
data-specific codecs, which is absolutely not what we want.

> I was basically told not to discuss email local-parts on this mailing
> list.

We have talked about email local-parts several times. I'm not sure what
you are referring to here.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Fri Feb 15 23:47: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 XAA29383
	for ; Fri, 15 Feb 2002 23:47:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bwaG-0001Li-00
	for idn-data@psg.com; Fri, 15 Feb 2002 20:36:24 -0800
Received: from muncher.math.uic.edu ([131.193.178.181])
	by psg.com with smtp (Exim 3.33 #1)
	id 16bwaF-0001Lc-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 20:36:23 -0800
Received: (qmail 29929 invoked by uid 1001); 16 Feb 2002 04:35:20 -0000
Date: 16 Feb 2002 04:35:20 -0000
Message-ID: <20020216043520.20904.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
References: <3C66A551.231AE0E6@trab.se> <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <20020216035025.GA1681@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Adam M. Costello writes:
> The existing DNS requires *all* domain labels to be case-insensitive,
> not just host labels.  See RFC 1035.  So domain names are already
> inappropriate for any data types that are case-sensitive.

False. Let's look at what the specifications actually say:

   * RFC 1034 says that ``all present domain functions'' are
     case-insensitive ``assuming an ASCII character set.'' (For
     non-English speakers: ``present'' means ``now existing.'')

   * RFC 1035 says that case-insensitivity is used throughout the domain
     system ``at present.'' (``At present'' means ``at this time.'')

   * RFC 1035, section 2.3.3, quite explicitly allows administrators to
     store case-sensitive data in the domain name system, contrary to
     your claims. Have you ever read the RFC?

Both documents demand that case be preserved. Consequently, if you
destroy the case of (for example) a mailbox name inside an SOA record,
you are violating the DNS specifications.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sat Feb 16 00:09: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 AAA29534
	for ; Sat, 16 Feb 2002 00:09:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bwyo-0001ki-00
	for idn-data@psg.com; Fri, 15 Feb 2002 21:01:46 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bwyn-0001kY-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 21:01:45 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16bwyn-0000OD-00
	for ; Fri, 15 Feb 2002 21:01:45 -0800
Date: Sat, 16 Feb 2002 05:01:45 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020216050144.GA1320@nicemice.net>
Reply-To: IETF idn working group 
References: <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <20020216035025.GA1681@nicemice.net> <20020216043520.20904.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020216043520.20904.qmail@cr.yp.to>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"D. J. Bernstein"  wrote:

>    * RFC 1035, section 2.3.3, quite explicitly allows administrators
>    to store case-sensitive data in the domain name system

You can't have foo.com and Foo.com refer to different information.
If you have case-sensitive names that you're trying to map onto
domain names, you're going to run into that limitation.  Domain names
may be case-preserving to some extent, but they do not accomodate
case-sensitive names.

AMC



From owner-idn@ops.ietf.org  Sat Feb 16 00:22: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 AAA29623
	for ; Sat, 16 Feb 2002 00:22:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bx6L-0001rt-00
	for idn-data@psg.com; Fri, 15 Feb 2002 21:09:33 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bx6K-0001rm-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 21:09:32 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16bx6K-0000QK-00
	for ; Fri, 15 Feb 2002 21:09:32 -0800
Date: Sat, 16 Feb 2002 05:09:32 +0000
From: "Adam M. Costello" 
To: idn@ops.ietf.org
Subject: Re: [idn] WG last call documents
Message-ID: <20020216050931.GB1320@nicemice.net>
Reply-To: IETF idn working group 
References: <7FC3066C236FD511BC5900508BAC86FE9197BF@trestles.internal.realnames.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7FC3066C236FD511BC5900508BAC86FE9197BF@trestles.internal.realnames.com>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Yves Arrouye  wrote:

> > STD13 binary domain names and i18n host names are fundamentally
> > incompatible.
>
> Clearly. So is this:
>
> "IDNA-aware applications MUST be able to work with both
> non-internationalized labels (those that conform to [STD13] and
> [STD3]) and internationalized labels."
>
> going to go away from the IDNA document?  It is misleading.  Or maybe
> replaced with:
>
> "IDNA-aware applications MUST be able to work with both
> non-internationalized ASCII labels (those that conform to [STD13] and
> [STD3]) and internationalized labels."

We are planning to add the following to the definition of "label":

    [STD13] permits labels to contain arbitrary binary data that might
    not represent text.  IDNA does not apply to non-text labels.
    Throughout this document the term "label" is shorthand for "text
    label", and "every label" means "every text label".

Does that help?

> (where ASCII should be replaced by some other definition since
> 0000..0020 and U+007F are prohibited by Nameprep-07; unless Nameprep
> is changed to allow them since ToASCII now has an explicit "hostname"
> step).

Yes, we are removing all ASCII code points from the Nameprep prohibited
list.

AMC



From owner-idn@ops.ietf.org  Sat Feb 16 00:44: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 AAA29878
	for ; Sat, 16 Feb 2002 00:44:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bxJa-00024Q-00
	for idn-data@psg.com; Fri, 15 Feb 2002 21:23:14 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16bxJZ-00024K-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 21:23:13 -0800
Received: (qmail 20282 invoked by uid 1001); 16 Feb 2002 05:22:12 -0000
Date: 16 Feb 2002 05:22:12 -0000
Message-ID: <20020216052212.24064.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
References: <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <20020216035025.GA1681@nicemice.net> <20020216043520.20904.qmail@cr.yp.to> <20020216050144.GA1320@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Adam M. Costello writes:
> If you have case-sensitive names that you're trying to map onto
> domain names, you're going to run into that limitation.

False. I have already given an example: the mailbox name stored in an
SOA record.

One SOA record can say Johnny.fbi.gov, for example, while another one
says johnny.fbi.gov. Mail in the first case must go to Johnny@fbi.gov.
Mail in the second case must go to johnny@fbi.gov.

There is no guarantee that these are the same address. If you screw up
the case, you are violating RFC 1034 and RFC 1035.

Your ignorance of this use of DNS is typical of the carelessness that
pervades the IDNA design.

> Domain names may be case-preserving to some extent, but they do not
> accomodate case-sensitive names.

RFC 1035, section 2.3.3, final paragraph, clearly and explicitly allows
case-sensitive names in DNS. It even uses the words ``case-sensitive.''
Are you completely unable to read?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sat Feb 16 00:52: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 AAA29911
	for ; Sat, 16 Feb 2002 00:52:23 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bxhT-0002R8-00
	for idn-data@psg.com; Fri, 15 Feb 2002 21:47:55 -0800
Received: from goose.ehsco.com ([207.65.203.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bxhT-0002R2-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 21:47:55 -0800
Received: from [68.52.224.13] (account ehall HELO ehsco.com)
  by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2)
  with ESMTP-TLS id 56117 for idn@ops.ietf.org; Fri, 15 Feb 2002 23:47:19 -0600
Message-ID: <3C6DF288.A62B3079@ehsco.com>
Date: Fri, 15 Feb 2002 23:47:52 -0600
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] WG last call documents
References: <3C6580EA.DE431F4D@ehsco.com> <20020211041601.GB14664@nicemice.net> <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <20020216035025.GA1681@nicemice.net> <20020216043520.20904.qmail@cr.yp.to> <20020216050144.GA1320@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:
> 
> "D. J. Bernstein"  wrote:
> 
> >    * RFC 1035, section 2.3.3, quite explicitly allows administrators
> >    to store case-sensitive data in the domain name system
> 
> You can't have foo.com and Foo.com refer to different information.

As owner names, those labels will be treated the same for comparison
purposes. As owner names of RRs which are provided as supplemental data
(such as CNAME completion, NS RRs in Authority, etc) the capitalization
will be preserved. As RR data, their capitalization will be preserved.

> If you have case-sensitive names that you're trying to map onto
> domain names, you're going to run into that limitation.  Domain names
> may be case-preserving to some extent, but they do not accomodate
> case-sensitive names.

The case-sensitive data-types which are normally found in DNS do not
normally exist as owner domain names. For example, there are no RRs that
use mailboxes as owner domain names. However, as M Andrews pointed out in
<200111220358.fAM3wVo45784@drugs.dv.isc.org>, this has not always been the
situation and it isn't guaranteed to always be the situation in the future
either. Mandatory lowercasing on all i18n domain names would be
counter-productive in that scenario as well.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-idn@ops.ietf.org  Sat Feb 16 01: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 BAA00122
	for ; Sat, 16 Feb 2002 01:17:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16bxzU-0002iZ-00
	for idn-data@psg.com; Fri, 15 Feb 2002 22:06:32 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16bxzT-0002iT-00
	for idn@ops.ietf.org; Fri, 15 Feb 2002 22:06:31 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16bxzT-0000mY-00
	for ; Fri, 15 Feb 2002 22:06:31 -0800
Date: Sat, 16 Feb 2002 06:06:31 +0000
From: "Adam M. Costello" 
To: IETF idn working group 
Subject: Re: [idn] WG last call documents
Message-ID: <20020216060630.GC1320@nicemice.net>
Reply-To: IETF idn working group 
References: <3C684239.738EE007@ehsco.com> <3C6D5FB7.E3F6AAA4@ehsco.com> <20020215221512.GB22341@nicemice.net> <3C6D9F9E.D300224D@ehsco.com> <20020216004825.GD22341@nicemice.net> <3C6DBAB6.8B85E778@ehsco.com> <20020216035025.GA1681@nicemice.net> <20020216043520.20904.qmail@cr.yp.to> <20020216050144.GA1320@nicemice.net> <20020216052212.24064.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020216052212.24064.qmail@cr.yp.to>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"D. J. Bernstein"  wrote:

> > If you have case-sensitive names that you're trying to map onto
> > domain names, you're going to run into that limitation.
>
> False.  I have already given an example: the mailbox name stored in an
> SOA record.

Okay, there you can get away with it because that domain name is never
the name of a record in the DNS, it is only part of the returned
data.  Names of records (that is, names that can be queried) are
case-insensitive.

> > Domain names may be case-preserving to some extent, but they do not
> > accomodate case-sensitive names.
>
> RFC 1035, section 2.3.3, final paragraph, clearly and explicitly
> allows case-sensitive names in DNS.  It even uses the words
> ``case-sensitive.''  Are you completely unable to read?

Are you?  Here's the paragraph you refer to:

    Systems administrators who enter data into the domain database
    should take care to represent the data they supply to the
    domain system in a case-consistent manner if their system is
    case-sensitive.  The data distribution system in the domain system
    will ensure that consistent representations are preserved.

Nowhere does that paragraph apply the term "case-sensitive" to the
names.  It applies to term "case-sensitive" to the system on which the
database resides.  It's warning administrators not to accidentally enter
both "foo" and "Foo" into the database if their database would blindly
do that, because the DNS database is not allowed to have both "foo" and
"Foo" in the same zone.

It says that the DNS will preserve the case of whatever was entered,
but as I explained above, that doesn't mean the DNS can accomodate
case-sensitive names of records.  If I have a collection of
case-sensitive names, it might contain names that differ only in their
case, and DNS will not make the distinction.

AMC



From owner-idn@ops.ietf.org  Sat Feb 16 07:37: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 HAA11068
	for ; Sat, 16 Feb 2002 07:37:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16c3ps-0008dO-00
	for idn-data@psg.com; Sat, 16 Feb 2002 04:21:00 -0800
Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16c3pq-0008dH-00
	for idn@ops.ietf.org; Sat, 16 Feb 2002 04:20:59 -0800
Received: from mailb.telia.se (localhost [127.0.0.1])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g1GCKuJ22337
	for ; Sat, 16 Feb 2002 13:20:57 +0100 (MET)
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 g1GCKtv22333
	for ; Sat, 16 Feb 2002 13:20:55 +0100 (MET)
Message-ID: <3C6E4E80.CA0C16D0@trab.se>
Date: Sat, 16 Feb 2002 13:20:16 +0100
From: Dan Oscarsson 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: [idn] Expected handling of labels
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I see that still, after so long time, the people of the IDN working
group
do not agree of how labels in DNS should be handled.

DNS, as defined by RFC 1035, defines for me what I would expect
of a database with objects having an owner name:
- A name is a sequence of printable characters.
- The character data in a name is preserved.
- Names are matched case-insensitive.

Yes, it is printable characters even though RFC 1035 does not
forbid it because that is how it is generally used.
If we want to use binary data in labels, either define
a new binary label or encode binary data using ACE.

There is now much different discussions of how DNS should work
when be broaden the scope of characters of all of the world's need.
Some want to force special rules on some labels (like requiring
host names to be lower case) and some want anything to be possible
including binary data and un-normalised character data.

I strongly oppose DNS having more than ONE form of character labels.
All character labels (it is ok to define a binary one) in DNS
must follow the same rules. To be well working and follow what would
be expected of names used for matching in directorys or other types of
databases, they should:
- Be only printable characters (no control codes).
  This because they are names, not application data.
- Be normalised. Unicode form C or probably KC is suitable.
  This because only one representation of a character must
  exist so that data can be easily processed.
  I cannot say if KC is OK for everybody. From what I can
  see for Latin based letters KC is fine. Things like
  full/double width or circled forms are display options like
  bold or italic and should not have a special code in a
  character set.
- Be stored and returnd in queries using the original
  entered form (including mixed case and other characteristics
  available).
  This because form may be significat in some systems and
  it is important to enhance readability.
- Be matched using form-insensitive matching (this includes
  case-insensitive matching).
  This because for the common man, form is not significant.


Using the above rules DNS (which are defined in RFC 1035 or
the current usage/semantics of DNS) would continue having
a broad and easy to use functionality.

If there exist specific need to have binary or form-exact
matching, new label types can be defined for those labels.

Please stop thinking so much about programmers. Think
of how people want to use a database where you bind a
name to an object. At least I want things to work
like LDAP and DNS today works: I define an object,
give it a name, the name is reatind and returned from
the database in the same form I entered it and when
doing matching the database ignores case of letters.

   Dan



From owner-idn@ops.ietf.org  Sat Feb 16 07:40: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 HAA11098
	for ; Sat, 16 Feb 2002 07:40:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16c3xY-0008lz-00
	for idn-data@psg.com; Sat, 16 Feb 2002 04:28:56 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16c3xW-0008lG-00
	for idn@ops.ietf.org; Sat, 16 Feb 2002 04:28:54 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1GCSqh20125
	for ; Sat, 16 Feb 2002 13:28:52 +0100 (MET)
From: "Kent Karlsson" 
To: "'IETF idn working group'" 
Subject: Khmer and Hangul (was: RE: [idn] last call reminder - Hebrew)
Date: Sat, 16 Feb 2002 13:25:25 +0100
Message-ID: <000801c1b6e5$042fc4d0$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3C6AA354.C0FE4DDF@zetnet.co.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


> a script-level issue. (Someone mentioned the Khmer inherent vowels
> U+17B4/17B5; that might be similar, but I'm less convinced 
> because they are apparently only used for phonetic transcription.)

Note that the Khmer "INHERENT" (no, not 'inherent', there are no
characters for those) vowels are invisible, and should normally not
be used.  But if they are, they cannot be seen (except in "view 
invisibles" mode).

> Unlike TC/SC or other language-specific equivalences, mapping out
> Hebrew and Arabic points is absolutely trivial to implement, trivial
> to specify, and makes sense for all languages using the 
> affected scripts.

Likewise, mapping *out* Hangul compatibility letters (which are not
as trivial to map properly to conjoining Hangul jamo) and mapping
letter cluster Hangul jamos *to* their constituent letters are trivial
to implement.  Doing the latter is also in accordance with the
desing of the Hangul script, *not* doing so *goes against* the design
of the Hangul script.

		Kind regards
		/kent k




From owner-idn@ops.ietf.org  Sat Feb 16 07:41: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 HAA11117
	for ; Sat, 16 Feb 2002 07:41:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16c3wC-0008j8-00
	for idn-data@psg.com; Sat, 16 Feb 2002 04:27:32 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16c3wB-0008j2-00
	for idn@ops.ietf.org; Sat, 16 Feb 2002 04:27:31 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1GCRSh20078
	for ; Sat, 16 Feb 2002 13:27:28 +0100 (MET)
From: "Kent Karlsson" 
To: 
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep
Date: Sat, 16 Feb 2002 13:24:02 +0100
Message-ID: <000701c1b6e4$d28dc670$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
Paul Hoffman / IMC:

> It seems a tad inappropriate for the IETF to consider not only going 
> against the Unicode standard but *also* against the desires of the 
> Korean national body to ISO because of the desires of a small number 
> of people who are neither representatives of standards bodies or the 
> national governments that are most interested in the script in 
> question.


It seems to be much more than a tad inappropriate (for anyone) to go
against the *design* of a script. Note that Hangul was really designed,
by a working group, resulting in a document describing the (then) new
script.  So there is no after-construction involved when referring to
"the design" here.  There have been some minor changes of use, like
IEUNG as trail now stands for what YESIEUNG ("ng") used to stand for.
But that does not affect the structure of the design.  See "The Korean
Language" [1], section 6.3 gives an English translation of the original
description of the script design.  (Note that I'm not suggesting that
YESIEUNG be folded to IEUNG, they are different letters, albeit similar.)


I think I know why the letter cluster characters were invented, and 
why one did not want them to be decomposed at the time: it has to do
with collation.  But getting Hangul correctly collated *can and
should* be done without resorting to these letter cluster characters.
(There are several methods, irrelevant for this group.)


Note that it is not entirely unusual for SC2/WG2 to go "against the
desires of the NNN national body to ISO" that is asking for some
rearrangement or precomposition of characters, referring said
NB to 14651 for how to achieve correct collation order.


For all other (alphabetic or syllabic) scripts we have that: same
sequence of letters (including diacritics) = same "nameprepped" form =
same "name"; indeed, for IDN we even disregard all case differences
(for historic reasons; which we therefore must generalise; even though,
as has been pointed out, there are still some technical problems
with that [Turkish, and Greek; dotted i and adscript iota...]).


Now why should we in this instance at all regard multiple low
level representations of exactly the ***SAME*** sequence of
letters (and [tone] marks), according to the design, as being
different?  They will not only look the same (if properly
supported), they *ARE* the same, even if one representation
uses letter cluster characters and the other does not.


		Kind regards
		/kent k


PS
Note still that this is very different from the SC/TC case where the
spelling is different for the same words.


[1] SOHN, Ho-Min, "The Korean Language", Cambridge University
    Press, 1999.


> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 




From owner-idn@ops.ietf.org  Sat Feb 16 09:32: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 JAA12435
	for ; Sat, 16 Feb 2002 09:32:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16c5dv-000Aid-00
	for idn-data@psg.com; Sat, 16 Feb 2002 06:16:47 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16c5du-000AiX-00
	for idn@ops.ietf.org; Sat, 16 Feb 2002 06:16:46 -0800
Received: from chalmers95a69n (dhcp226-180.cs.chalmers.se [129.16.226.180])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1GEGih23664
	for ; Sat, 16 Feb 2002 15:16:44 +0100 (MET)
From: "Kent Karlsson" 
To: "'IETF idn working group'" 
Subject: RE: Khmer and Hangul (was: RE: [idn] last call reminder - Hebrew)
Date: Sat, 16 Feb 2002 15:13:18 +0100
Message-ID: <000901c1b6f4$15d21710$b4e21081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000801c1b6e5$042fc4d0$b4e21081@chalmers95a69n>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


I wrote:
> Likewise, mapping *out* Hangul compatibility letters (which are not

By "map out" I here meant "map to illegal", NOT "ignore/delete".

	Sorry for any confusion
	/kent k




From owner-idn@ops.ietf.org  Sat Feb 16 20:59: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 UAA19602
	for ; Sat, 16 Feb 2002 20:59:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16cGJZ-000LiL-00
	for idn-data@psg.com; Sat, 16 Feb 2002 17:40:29 -0800
To: liana Ye 
cc: kentk@md.chalmers.se, djb@cr.yp.to, idn@ops.ietf.org
Subject: Re: [idn] Why IDNA breaks copy-and-paste
In-reply-to: Your message of "Fri, 15 Feb 2002 09:24:09 PST."
             <20020215.092409.-262871.1.liana.ydisg@juno.com>
X-URL: http://www.cl.cam.ac.uk/~mgk25/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 15 Feb 2002 17:34:09 +0000
From: Markus Kuhn 
Message-Id: 
Sender: owner-idn@ops.ietf.org
Precedence: bulk

liana Ye wrote on 2002-02-15 17:24 UTC:
> Thanks for your input into the discussion.  Although
> I  myself not an expert in termcap, your experience
> in making " xterm preserves as much of the original UCS
> plaintext " is  what I expected to hear from someone.
>
> This is a part of my reasoning to treat Latin script at the
> same lavel with other scripts, not make it a special
> case to squeeze it into DNS.

Ah, now that I have understood what the discussion is about, I can
comment better onto what sort of corruption you should expect:

  - xterm is likely to leave only Normalization Form C of Unicode
    untouched. Composed sequences will be replaced with precomposed
    sequences.

  - xterm is likely to mess up significantly any text from right-to-left
    scripts. The current plan is that bidi might be handled in an extra
    filter stage or in libaries such as ncurses.

  - If Arabic shaping is done not in xterm, but in the intermediate
    filter or ncurses layer, then you will also find in the cut&paste
    buffer presentation forms and not alphabetic characters

To I would be extremely careful with using cut&paste in order to
transfer unique identifiers from a terminal emulator to an application.
This can end in an endless can of worms, if Hebrew, Arabic or Syriac are
involved, and we haven't even begun to understand how to handle that,
even after scratching out heads for a year in heated discussions on the
linux-utf8 and i18n@xfree86.org mailing lists.

The other critical security issue related to DNS are of course
homoglyphs. The same glyph appears in Unicode many times as separate
characters that are part of different alphabets or different usage
backgrounds, Latin, Cyrillic, and Greek "A" being just one example.

Markus

--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: 






From owner-idn@ops.ietf.org  Sat Feb 16 23:54: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 XAA23413
	for ; Sat, 16 Feb 2002 23:54:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16cJ7F-000OgA-00
	for idn-data@psg.com; Sat, 16 Feb 2002 20:39:57 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16cJ7C-000Og2-00
	for idn@ops.ietf.org; Sat, 16 Feb 2002 20:39:55 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP
	id 7002BFFC01; Sun, 17 Feb 2002 12:38:45 +0800 (SGT)
Message-ID: <008d01c1b76d$27093e40$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" 
To: "Kent Karlsson" , 
References: <000701c1b6e4$d28dc670$b4e21081@chalmers95a69n>
Subject: Re: [idn] Comments on IDNA/stringprep/nameprep
Date: Sun, 17 Feb 2002 12:39: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 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: 7bit

this is the kind of discussion that should be carried out in unicore and
not in idn, really.

-James Seng

----- Original Message -----
From: "Kent Karlsson" 
To: 
Sent: Saturday, February 16, 2002 8:24 PM
Subject: RE: [idn] Comments on IDNA/stringprep/nameprep


>
>
> > -----Original Message-----
> Paul Hoffman / IMC:
>
> > It seems a tad inappropriate for the IETF to consider not only going
> > against the Unicode standard but *also* against the desires of the
> > Korean national body to ISO because of the desires of a small number
> > of people who are neither representatives of standards bodies or the
> > national governments that are most interested in the script in
> > question.
>
>
> It seems to be much more than a tad inappropriate (for anyone) to go
> against the *design* of a script. Note that Hangul was really
designed,
> by a working group, resulting in a document describing the (then) new
> script.  So there is no after-construction involved when referring to
> "the design" here.  There have been some minor changes of use, like
> IEUNG as trail now stands for what YESIEUNG ("ng") used to stand for.
> But that does not affect the structure of the design.  See "The Korean
> Language" [1], section 6.3 gives an English translation of the
original
> description of the script design.  (Note that I'm not suggesting that
> YESIEUNG be folded to IEUNG, they are different letters, albeit
similar.)
>
>
> I think I know why the letter cluster characters were invented, and
> why one did not want them to be decomposed at the time: it has to do
> with collation.  But getting Hangul correctly collated *can and
> should* be done without resorting to these letter cluster characters.
> (There are several methods, irrelevant for this group.)
>
>
> Note that it is not entirely unusual for SC2/WG2 to go "against the
> desires of the NNN national body to ISO" that is asking for some
> rearrangement or precomposition of characters, referring said
> NB to 14651 for how to achieve correct collation order.
>
>
> For all other (alphabetic or syllabic) scripts we have that: same
> sequence of letters (including diacritics) = same "nameprepped" form =
> same "name"; indeed, for IDN we even disregard all case differences
> (for historic reasons; which we therefore must generalise; even
though,
> as has been pointed out, there are still some technical problems
> with that [Turkish, and Greek; dotted i and adscript iota...]).
>
>
> Now why should we in this instance at all regard multiple low
> level representations of exactly the ***SAME*** sequence of
> letters (and [tone] marks), according to the design, as being
> different?  They will not only look the same (if properly
> supported), they *ARE* the same, even if one representation
> uses letter cluster characters and the other does not.
>
>
> Kind regards
> /kent k
>
>
> PS
> Note still that this is very different from the SC/TC case where the
> spelling is different for the same words.
>
>
> [1] SOHN, Ho-Min, "The Korean Language", Cambridge University
>     Press, 1999.
>
>
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >
>
>




From owner-idn@ops.ietf.org  Sun Feb 17 03:24: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 DAA02995
	for ; Sun, 17 Feb 2002 03:24:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16cMGj-0001yC-00
	for idn-data@psg.com; Sun, 17 Feb 2002 00:01:57 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16cMGj-0001y6-00
	for idn@ops.ietf.org; Sun, 17 Feb 2002 00:01:57 -0800
Received: (qmail 29499 invoked by uid 1001); 17 Feb 2002 08:00:52 -0000
Date: 17 Feb 2002 08:00:52 -0000
Message-ID: <20020217080052.9658.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Expected handling of labels
References: <3C6E4E80.CA0C16D0@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dan Oscarsson writes:
> Think of how people want to use a database where you bind a
> name to an object.

Okay. Here are three examples of well-known case-sensitive databases
that you probably use every day:

   * The UNIX password list, accessed by account name.
   * The UNIX filesystem, accessed by filename.
   * The World Wide Web, accessed by URL.

Do you find yourself trying to log into your computer as ``dAn'' rather
than ``dan'' and wondering why it doesn't work? Have you been screaming
at the UNIX filesystem designers, telling them that they need nameprep?
How about W3C?

The simple fact is that users have already adapted to a huge number of
case-sensitive systems. Byte-string comparisons have not brought the
world to an end. This is true even for databases allowing full Unicode
names: look at the Plan 9 filesystem, for example.

``But it's confusing when I have separate objects named foo and Foo!''
you say. That's why people rarely set up such objects: they choose names
that _won't_ be confused. The IDNC3 proposal described at

   http://cr.yp.to/proto/idnc3.html

extends this principle to domain-name registrars.

The clincher is the fact that, if we set up case-insensitivity for
non-ASCII characters, we'll never be able to escape. We'll have to
suffer the costs of supporting it forever. In contrast, if we take the
conservative IDNC3 approach, we'll still have the option of adding
case-insensitivity later, _if_ it turns out to be necessary.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Sun Feb 17 11:23: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 LAA07834
	for ; Sun, 17 Feb 2002 11:23:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16cTey-000AmX-00
	for idn-data@psg.com; Sun, 17 Feb 2002 07:55:28 -0800
Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16cTex-000AmR-00
	for idn@ops.ietf.org; Sun, 17 Feb 2002 07:55:27 -0800
Received: from mailb.telia.se (localhost [127.0.0.1])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g1HFtOJ01711
	for ; Sun, 17 Feb 2002 16:55:24 +0100 (MET)
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 g1HFtNv01700;
	Sun, 17 Feb 2002 16:55:23 +0100 (MET)
Message-ID: <3C6FD249.952479C9@trab.se>
Date: Sun, 17 Feb 2002 16:54:49 +0100
From: Dan Oscarsson 
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org, djb@cr.yp.to
Subject: Re: [idn] Expected handling of labels
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

D. J. Bernstein wrote:

>Okay. Here are three examples of well-known case-sensitive databases
>that you probably use every day:
>
>   * The UNIX password list, accessed by account name.
>   * The UNIX filesystem, accessed by filename.
>   * The World Wide Web, accessed by URL.
>
>Do you find yourself trying to log into your computer as ``dAn'' rather
>than ``dan'' and wondering why it doesn't work? Have you been screaming
>at the UNIX filesystem designers, telling them that they need nameprep?
>How about W3C?

You quite often lears to bypass defect interfaces and quit complaining
after a while. Though you still dislike it.

Yes, Unix is one system full of bad designs. You have to learn to live
with it
and always type your account name of file names using the exact case
stored in the system (but you do not have to use lower case always).
URLs have always been case-insensitive on my web even though the server
is running under Unix. Much easier for the users!



>``But it's confusing when I have separate objects named foo and Foo!''
>you say. That's why people rarely set up such objects: they choose names
>that _won't_ be confused.

Yes and when using case-sensitive systems you probably should avoid
having
to names only different in case in the same scope. But you want to
use different case to enhance readability.

I use mixed case in my Unix filesystem to enhance readability.
I use tcsh which can compleate file names ignoring case.
I would be much nicer it the file system was case-insensitive.

Some want their host name or URL to contain mixed case because
it corresponds to their trademark or makes the meaning clearer.


>The clincher is the fact that, if we set up case-insensitivity for
>non-ASCII characters, we'll never be able to escape. We'll have to
>suffer the costs of supporting it forever. In contrast, if we take the
>conservative IDNC3 approach, we'll still have the option of adding
>case-insensitivity later, _if_ it turns out to be necessary.

Actually case-insensitivity for many Latin based letters can easily
be handled without a large cost. One thing that could be done
is to avoid the difficult cases from the beginning.

One important question is:
Is it more important to lower the cost of software then to
lower the cost of the human - computer interface?

From what I have seen the cost of increased human time to handle
difficlut interfaces is very much more costly than fixing
software.

   Dan



From owner-idn@ops.ietf.org  Mon Feb 18 22:32: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 WAA29870
	for ; Mon, 18 Feb 2002 22:32:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16d0lB-0002F8-00
	for idn-data@psg.com; Mon, 18 Feb 2002 19:16:05 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16d0l9-0002F1-00
	for idn@ops.ietf.org; Mon, 18 Feb 2002 19:16:04 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GRRFSI00.CA3; Tue,
          19 Feb 2002 11:17:06 +0800 
Message-ID: <03bf01c1b8f2$b19716f0$4407e29f@deng>
From: "xiang deng" 
To: , "Paul Hoffman / IMC" 
References: <029f01c1b026$2920dd30$0f01000a@jamessonyvaio><00b801c1b056$0ade4760$49156d8c@acer603><072b01c1b058$6bda16f0$0f01000a@jamessonyvaio><021e01c1b0e5$611d15e0$c5e16d8c@itsnb><20020208142737.A53521@shell.nominum.com><005d01c1b109$d7315100$4407e29f@deng> 
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)
Date: Tue, 19 Feb 2002 11:08:24 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA29870

Internet Users in China: 
  Totally 33,700,000. Among them, 6,720,000 use leased line connections, 
21,330,000 are dial-up users and 5,650,000 use both. 

The online survey had received 75,383 responses, among which 64,627 responses were valid. For the sampling survey, we carried on telephone interviews by using the sampling survey method, and 53,797 samples are available (under the confidence coefficient of 95%, the absolute error of the provincial result is less than 3%) .

Regards.
Deng xiang 

----- Original Message ----- 
From: "Paul Hoffman / IMC" 

> At 9:33 AM +0800 2/9/02, xiang deng wrote:
> >Dear Ted,
> >
> >Thanks for your comment.
> >Discussion make issue more clearly.
> >
> >we are clear:
> >1. Current IDNA is a good solution.
> >2. IDNA ONLY will be detrimental to Chinese Internet Community.
> >3. IDN WG chairs' express: it's out of scope.
> 
> It is incredibly inappropriate to blame this on WG chairs. There have 
> been many, many other people in the WG who have stated the same 
> opinion. If you object to this, you can follow the IETF rules for 
> appealing. Hint: that does not involve spamming the mailing list.
> 
> >  But decision maker is not
> >     family with Chinese character and never use Chinese character in 
> >daily life.
> 
> Why do you feel that is relevant in a standards body?
> 
> >4. Chinese Internet community object IDNA ONLY solution.
> 
> The two name registries on this mailing list do not represent the 
> Chinese Internet community any more than Verisign represents the US 
> community. Many of us know know lots of other Chinese people, and it 
> is safe to say that the extreme rudeness and inability to work with 
> others is not representative of the Chinese Internet community.
> 
> >5. Unicode haven't finish the equivalent set of Chinese character.
> 
> More importantly, ISO has not started it either.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 


From owner-idn@ops.ietf.org  Mon Feb 18 22:53: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 WAA00339
	for ; Mon, 18 Feb 2002 22:53:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16d16T-0005Fx-00
	for idn-data@psg.com; Mon, 18 Feb 2002 19:38:05 -0800
Received: from koobera.math.uic.edu ([131.193.178.181] helo=muncher.math.uic.edu)
	by psg.com with smtp (Exim 3.33 #1)
	id 16d16R-0005EX-00
	for idn@ops.ietf.org; Mon, 18 Feb 2002 19:38:03 -0800
Received: (qmail 31519 invoked by uid 1001); 19 Feb 2002 03:37:00 -0000
Date: 19 Feb 2002 03:37:00 -0000
Message-ID: <20020219033700.18880.qmail@cr.yp.to>
Mail-Followup-To: idn@ops.ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" 
To: idn@ops.ietf.org
Subject: Re: [idn] Expected handling of labels
References: <3C6FD249.952479C9@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dan Oscarsson writes:
> Much easier for the users!

Where are the HCI studies evaluating the actual usability impact of
allowing uppercase Unicode labels?

You claim without evidence that there's a readability benefit. I could
claim, with just as much evidence, that there is a huge typability loss.
I could also claim that users who don't know Greek will be confused by
uppercase Greek Gamma matching lowercase Greek gamma. ``Hey, this
certificate is for the wrong site! Impostors!''

You say that usability will be improved so much that programmers should
take time away from other features to implement this one. But are you so
sure about this that you're willing to commit the entire Internet to
this decision _now_, with no way to escape if you turn out to be wrong?

IDNC3, http://cr.yp.to/proto/idnc3.html, takes a conservative approach.
It provides safe deployment of lowercase IDNs, and allows uppercase to
be safely added later _if_ that turns out to be a good idea.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



From owner-idn@ops.ietf.org  Mon Feb 18 23:08: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 XAA00536
	for ; Mon, 18 Feb 2002 23:08:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16d1QX-000991-00
	for idn-data@psg.com; Mon, 18 Feb 2002 19:58:49 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16d1QW-00098v-00
	for idn@ops.ietf.org; Mon, 18 Feb 2002 19:58:48 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GRRHRT00.UAW; Tue,
          19 Feb 2002 11:59:53 +0800 
Message-ID: <041201c1b8f8$abe004f0$4407e29f@deng>
From: "xiang deng" 
To: , "Paul Hoffman / IMC" 
References: <5.1.0.14.2.20020204073729.01b04328@127.0.0.1>	<83129960.1012820475@localhost> <3C6494D9.988C9CBA@iis.sinica.edu.tw><001001c1b196$d5765f80$4007738c@q.j.tw> 
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Date: Tue, 19 Feb 2002 11:51:11 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id XAA00536


From: "Paul Hoffman / IMC" 


> At 2:23 AM +0800 2/10/02, tsenglm@cc.ncu.edu.tw wrote:
> >Can you specify more clearly ? we all like to know what is the reference ?
> 
> Sure. The "reference" is personal conversations that folks from CDNC 
> had with other people active in the IDN WG during the Salt Lake City 
> meeting. Many people met with CDNC members in Salt Lake City, and 
> many of us heard similar statements in our discussions.

I'm from CNNIC and Mainland of China, as a technical member of CDNC,
I also interested in YOUR reference of CDNC.

> >                1. make more money from registration
> 
> People from both CNNIC and TWNIC have said "we cannot do a 2^n 
> registration solution because we need to charge end users for each 
> name in the zone". Of course, you do not need to charge per name: you 
> can charge per group of names that come from a single base name. But 
> the fact that this argument still comes up leads one to think that 
> maybe you want to charge per name even though doing that will hurt 
> the Chinese people.

Funny! If you want stigmatize others, don't use the word "Maybe".
 
Deng xiang



From owner-idn@ops.ietf.org  Sun Feb 24 08:02: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 IAA10743
	for ; Sun, 24 Feb 2002 08:02:00 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.35 #1)
	id 16ey10-000BK0-00
	for idn-data@psg.com; Sun, 24 Feb 2002 04:44:30 -0800
Received: from pheidippides.md.chalmers.se ([129.16.237.91])
	by psg.com with esmtp (Exim 3.35 #1)
	id 16ey0z-000BJu-00
	for idn@ops.ietf.org; Sun, 24 Feb 2002 04:44:30 -0800
Received: from chalmers95a69n (dynamic-193-200.dialup.chalmers.se [129.16.193.200])
	by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id g1OCiQh00282
	for ; Sun, 24 Feb 2002 13:44:26 +0100 (MET)
From: "Kent Karlsson" 
To: 
Subject: RE: [idn] Expected handling of labels
Date: Sun, 24 Feb 2002 12:41:20 +0100
Message-ID: <003a01c1bd30$e6ec4bd0$91c11081@chalmers95a69n>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20020219033700.18880.qmail@cr.yp.to>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


> It provides safe deployment of lowercase IDNs, and allows uppercase to
> be safely added later _if_ that turns out to be a good idea.

I don't agree with that approach, I think uppercase should
be allowed, since it is allowed for ASCII.  

But maybe one should reconsider the use of *case folding* and
instead just *map to lowercase* (in the 'default' way; not
localised for Turkish/similar nor for Lithuanian).   This
recognises that domain names most commonly are written in
lowercase anyway, and also allows for the distinction of "ss"
and sharp s, as well as the distinction of (the *different* letters)
i and dotless i (and similarly for Lithuanian), IF the domain
name is written in lowercase. Note also that there are several
(Latin) letters that do not even have ANY uppercase form (used
for IPA/similar).

		Kind regards
		/kent k