From owner-idn@ops.ietf.org Sun Dec 1 05:01:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02037 for ; Sun, 1 Dec 2002 05:01:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IQoL-000OFo-00 for idn-data@psg.com; Sun, 01 Dec 2002 01:54:49 -0800 Received: from mailout06.sul.t-online.com ([194.25.134.19]) by psg.com with esmtp (Exim 3.36 #2) id 18IQoI-000OFZ-00 for idn@ops.ietf.org; Sun, 01 Dec 2002 01:54:46 -0800 Received: from fwd07.sul.t-online.de by mailout06.sul.t-online.com with smtp id 18IQoG-0006Fn-03; Sun, 01 Dec 2002 10:54:44 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.19.155]) by fmrl07.sul.t-online.com with esmtp id 18IQo5-08JrkWC; Sun, 1 Dec 2002 10:54:33 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id gB19selg001797 for ; Sun, 1 Dec 2002 10:54:40 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id gB19sdAe001794; Sun, 1 Dec 2002 10:54:39 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: IETF idn working group Subject: Re: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> <20021130090227.GB14628@nicemice.net> <20021201001350.GA20965@nicemice.net> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 01 Dec 2002 10:54:38 +0100 In-Reply-To: <20021201001350.GA20965@nicemice.net> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,MAILTO_TO_REMOVE, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_AUTH_WARNING version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > An approach that would really avoid this pitfall would be to deprecate > these characters not only in Unicode, but also in CNS 11643 and any > other character sets that contain them, and create new characters > in all these character sets, and leave all the mappings of the old > deprecated characters unchanged in both the Unicode database and the > WhateverToUnicode tables. That, of course, defeats the purpose of compatibility characters in the first place. It is my understanding that CNS 11643 contains characters that are really duplicates of each other, in different planes (of CNS 11643). The duplicates originate from creating the standard from different sources, and not applying a unification procedure. When integrating them to Unicode, the unification procedure found out that they are duplicates, and added the compatibility characters for round-tripping. [Somebody please correct me if this report on the history is incorrect] Now, if changing CNS 11643 was an option, you could have just deprecated the duplicate characters in that standard. Regards, Martin From owner-idn@ops.ietf.org Sun Dec 1 10:40:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08156 for ; Sun, 1 Dec 2002 10:40:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IVzT-0006ra-00 for idn-data@psg.com; Sun, 01 Dec 2002 07:26:39 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18IVzN-0006qm-00 for idn@ops.ietf.org; Sun, 01 Dec 2002 07:26:33 -0800 Received: from localhost (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gB1FQTGB028989 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 1 Dec 2002 16:26:30 +0100 To: IETF idn working group Subject: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> <20021130090227.GB14628@nicemice.net> <20021201001350.GA20965@nicemice.net> X-Hashcash: 0:021201:idn@ops.ietf.org:8700169e6c23500a From: Simon Josefsson Date: Sun, 01 Dec 2002 16:26:29 +0100 In-Reply-To: <20021201001350.GA20965@nicemice.net> ("Adam M. Costello"'s message of "Sun, 1 Dec 2002 00:13:50 +0000") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.8 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,MAILTO_TO_REMOVE, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > Simon Josefsson wrote: > >> Authentication identity "admin", authorization identity U+4711, >> password X. For the argument, let's say U+4711 decomposes into U+1234 >> in Unicode 3.2 but is later changed to U+4321. >> >> The SASL library, acting as a proxy in front of the application >> software, implements the current libstringprep correctly. It checks >> that admin's password is X and that he is authorized to log in as >> U+1234 (which is the result after stringprep of U+4711, which was sent >> because the client hadn't been updated to use stringprep, which should >> cause no problem) and says OK to the application. >> >> Now, in 1a the application is using updated tables from a more recent >> stringprep that incorporates the fixed decomposition mapping, causing >> it to admit the user to an account U+4321. This is bad. >> >> In 2a, the application sees that the characters are deprecated due >> to its decomposition mapping changed, and rejects the user. This is >> good. > > It looks like the security hole in 1a stems from the existence of two > Unicode strings X and Y such that now Stringprep(X) != Stringprep(Y) > (so that two distinct accounts for X and Y can be created), but later > (after the update of the decomposition mappings) Stringprep(X) == > Stringprep(Y), so the two accounts will get confused. > > But I think the same phenomenon can happen with 2a. There are CNS > 11643 strings A and B such that now Stringprep(CNS11643toUnicode(A)) > != Stringprep(CNS11643toUnicode(B)) (so that two distinct accounts for > A and B can be created), but later (after the deprecation and addition > of Unicode characters, and the subsequent update of CNS11643toUnicode > to use the new Unicode characters instead of the deprecated ones) > Stringprep(CNS11643toUnicode(A)) == Stringprep(CNS11643toUnicode(B)), > so again the two accounts get confused. No deprecated characters are > going to be seen and rejected, because no CNS 11643 characters are > deprecated, and the deprecated Unicode characters do not appear in the > new CNS11643toUnicode table. Yes, if I understand it correctly, I belive this was my motivation for proposing a security consideration saying something along the lines of that transcoding to and from the Unicode charset is a critical part of secure IDN and the the current IDN specification set doesn't address that problem, so it is a security consideration. IMHO that problem is bigger than the issues discussed here which only concerns a few and, more importantly, well known characters. To my knowledge, nobody has studied how many or which characters are in conflict in various transcoding table used. But in case 1a, it seems the problem can happen even when only Unicode is used. This makes the problem caused by transcoding exist even when no transcoding is involved. > An approach that would really avoid this pitfall would be to deprecate > these characters not only in Unicode, but also in CNS 11643 and any > other character sets that contain them, and create new characters > in all these character sets, and leave all the mappings of the old > deprecated characters unchanged in both the Unicode database and the > WhateverToUnicode tables. That would solve it. However, it seems the IDN WG has decided to only care about Unicode though, so the consequence of that decision is to declare that solution as out of scope as far as IDN is concerned. Anyone implementing this in the real world will have to solve the problem herself though, perhaps by adovcating the solution you proposed. From owner-idn@ops.ietf.org Mon Dec 2 04:27:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08746 for ; Mon, 2 Dec 2002 04:27:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ImkE-0008NH-00 for idn-data@psg.com; Mon, 02 Dec 2002 01:20:02 -0800 Received: from pheidippides.md.chalmers.se ([129.16.237.91]) by psg.com with esmtp (Exim 3.36 #2) id 18ImkB-0008N0-00 for idn@ops.ietf.org; Mon, 02 Dec 2002 01:19:59 -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 gB29JsD26652; Mon, 2 Dec 2002 10:19:54 +0100 (MET) From: "Kent Karlsson" To: "'Simon Josefsson'" Cc: Subject: RE: [idn] Re: Fwd: Unicode letter ballot Date: Mon, 2 Dec 2002 10:19:39 +0100 Message-ID: <000601c299e3$f17667d0$d5d61081@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Yes, you are right. I was thinking of when changes like the one > proposed here applies to any character, that doesn't happen to be a > compatibility character. By "compatibility character" you seem to mean "character that has a (compatibility or canonical) decomposition". But there are also other compatibility characters. Among them "characters that should have had a canonical decomposition, but has no decomposition". I'm thinking about what Soobok Lee wrote: > If option A wins in the coming ballot, then I will push > forward "correct NFC's hangul > jamo handling errors!" in Unicode 4.0, because NFC backward > compatibility promises would > be regarded as being broken already in those cases of 5 CJK > characters. I think "backward > compatiblity promise of NFC" is useful and neccesary but > proved to be premature at least > in current version 3.2. It is proved that proofreading takes > much time. The correction mentioned here involves characters that are such that they in Unicode 3.2 have no decompositions, while they had compatibility decompositions in Unicode 2.0, but logically should have canonical decompositions. For those not familiar with Hangul (jamo) in Unicode, these characters are those that stand for a sequence of two or three Hangul letters. For instance HANGUL CHOSEONG NIEUN-KIYEOK ('nk') should have a canonical decomposition into HANGUL CHOSEONG NIEUN ('n') followed by HANGUL CHOSEONG KIYEOK ('k'); there is no distinction between these, they both stand for 'nk' (in the lead part of a syllable), there is no ligaturing difference of any kind, no font difference (in theory), nor anything else that should be different between them, except for representation. But it, and several others like it, has no decomposition at all in Unicode 3.2. This has been mentioned several times before, but ignored by this WG. I'm drafting a "Unicode Technical Note" on Hangul decompositions. Kind regards /kent k From owner-idn@ops.ietf.org Wed Dec 4 12:27:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23726 for ; Wed, 4 Dec 2002 12:27:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jd6c-000Ckz-00 for idn-data@psg.com; Wed, 04 Dec 2002 09:14:38 -0800 Received: from m3001.hostcentric.net ([216.157.79.237]) by psg.com with smtp (Exim 3.36 #2) id 18Jd6Y-000Cki-00 for idn@ops.ietf.org; Wed, 04 Dec 2002 09:14:34 -0800 Received: (qmail 3845 invoked by alias); 4 Dec 2002 17:14:32 -0000 Received: from unknown (HELO DAVIS1) (12.234.224.33) by 0 with SMTP; 4 Dec 2002 17:14:32 -0000 Message-ID: <00a901c29bb8$98ede350$7300a8c0@DAVIS1> From: "Mark Davis" To: Subject: [idn] Fw: BALLOT on Five Canonical Mapping Errors Date: Wed, 4 Dec 2002 09:14:25 -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 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.2 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (Forwarded from another list) > Patrik, the consortium does take seriously the relationship with the IETF. > Were it not for that, there probably would not have been a letter ballot in > the first place -- it would have simply been dealt with in the last meeting. > > As the discussion on this list and on > http://www.imc.org/idn/mail-archive/threads.html attest, this is not a > simple decision; there are good arguments on both sides. > > I myself favor option B -- I think it will cause the least disruption > overall, especially since those 5 characters are rare, and the mapping > tables from CNS 11643 to those characters are not widely deployed (and one > already has to handle cases of variant mapping tables: the JIS characters > that vary in mappings between different operating systems are a heck of a > lot more common!) > > On the other hand, should the UTC decide to go with option A, the > NormalizationCorrections.txt file does allow IDN to migrate to future > versions of Unicode while being strictly backwards compatible. And because > the mappings are one-way, to characters that themselves do not differ have > canonical/compatibility mappings in either case, an implementation can > *still* make use of a stock version of NFKC or NFC to do mappings. The > implementation just needs to have an additional preprocessing step, mapping > those 5 characters according to NormalizationCorrections.txt before applying > normalization. (We should make this point clear somewhere in the > documentation of that file.) > > So having NormalizationCorrections.txt does ameliorate the problem. I agree > with you and others that it does not *eliminate* the problem (that's why I > personally believe that B is the better course), but in practice either A or > B are tenable solutions. > > Mark From owner-idn@ops.ietf.org Thu Dec 5 23:19:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13294 for ; Thu, 5 Dec 2002 23:19:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K9YW-0007k0-00 for idn-data@psg.com; Thu, 05 Dec 2002 19:53:36 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18K9Y0-0007j4-00 for idn@ops.ietf.org; Thu, 05 Dec 2002 19:53:04 -0800 Received: from localhost (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gB63r08b030567 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 6 Dec 2002 04:53:01 +0100 To: idn@ops.ietf.org Subject: [idn] Unassigned code points discussion in draft-hoffman-stringprep-07.txt X-Hashcash: 0:021206:idn@ops.ietf.org:cec25c7e3dc3af3d From: Simon Josefsson Date: Fri, 06 Dec 2002 04:52:59 +0100 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk It has been pointed out that the handling of unassigned code points in stringprep is unclear, and I agree. Quoting the document: ,---- | 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 3. | | 2) Normalize -- Possibly normalize the result of step 1 using Unicode | normalization. This is described in section 4. | | 3) Prohibit -- Check for any characters that are not allowed in the | output. If any are found, return an error. This is described in section | 5. | | 4) Check bidi -- Possibly check for right-to-left characters, and if any | are found, make sure that the whole string satisfies the requirements | for bidirectional strings. If the string does not satisfy the requirements | for bidirectional strings, return an error. This is described in section 6. | | The above steps MUST be performed in the order given to comply with this | specification. `---- A step for handling unassigned code points would make it clearer: 5) Check unassigned code points -- Possibly check the output for unassigned code points, according to the profile. This is described in section 7. A comment on whether this is what was intended or not would be appreciated. It could be argued that step 3 covers for unassigned code points, but prohibited characters and unassigned characters are treated separately elsewhere, and the forward reference does not include section 7. So unless it is stated explicitly that case 3 covers for unassigned code points too, one will not likely reach that conclusion when reading the document. From owner-idn@ops.ietf.org Fri Dec 6 11:55:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13679 for ; Fri, 6 Dec 2002 11:55:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KLTs-000FPO-00 for idn-data@psg.com; Fri, 06 Dec 2002 08:37:36 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 18KLTM-000FME-00 for idn@ops.ietf.org; Fri, 06 Dec 2002 08:37:04 -0800 Received: from [165.227.249.25] ([165.227.249.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6GaKg03445; Fri, 6 Dec 2002 08:36:21 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 6 Dec 2002 08:35:59 -0800 To: Simon Josefsson , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Unassigned code points discussion in draft-hoffman-stringprep-07.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=HABEAS_SWE,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk At 4:52 AM +0100 12/6/02, Simon Josefsson wrote: >A step for handling unassigned code points would make it clearer: > >5) Check unassigned code points -- Possibly check the output for > unassigned code points, according to the profile. This is > described in section 7. > >A comment on whether this is what was intended or not would be >appreciated. You can do it last, you can do it first, or you can check for unassigned code points during the prohibit step. It will work the same regardless of when you check. The mapping, normalization, and bidi steps will never add any unassigned characters, so checking for them in any step has the same effect. >It could be argued that step 3 covers for unassigned code points, but >prohibited characters and unassigned characters are treated separately >elsewhere, and the forward reference does not include section 7. So >unless it is stated explicitly that case 3 covers for unassigned code >points too, one will not likely reach that conclusion when reading the >document. Given the length of section 7, and the many forward references to it, it seems like that it would be noticed. If we revised the document, we could add explicit text saying you can do the check whenever you want. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Dec 7 04:13:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24010 for ; Sat, 7 Dec 2002 04:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kajq-000EdM-00 for idn-data@psg.com; Sat, 07 Dec 2002 00:55:06 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 18Kajn-000EcL-00 for idn@ops.ietf.org; Sat, 07 Dec 2002 00:55:03 -0800 Received: (qmail 7579 invoked from network); 7 Dec 2002 08:52:08 -0000 Received: from bb-203-125-86-201.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.86.201) by sentosa.post1.com with SMTP; 7 Dec 2002 08:52:08 -0000 Message-ID: <008901c29dce$39c152f0$e400a8c0@JSENGTOSHIBA> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] Fw: Results of BALLOT on Five Canonical Mapping Errors Date: Sat, 7 Dec 2002 16:54:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.1 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit fyi ----- Original Message ----- From: "Lisa Moore" To: "unicore" Sent: Saturday, December 07, 2002 6:09 AM Subject: Results of BALLOT on Five Canonical Mapping Errors > Folks, > > We are closing the ballot - 14 out of 18 members have voted, a majority of > full members voted for Option A: > > A) Fix the canonical mappings and issue another normalization corrigendum > with corrected mappings in the Unicode 4.0 time frame, as follows: > > Make the following corrections in UnicodeData.txt for 4.0: > Correct canonical mapping for 2F868 from 2136A to 36FC. > Correct canonical mapping for 2F874 from 5F33 to 5F53. > Correct canonical mapping for 2F91F from 43AB to 243AB. > Correct canonical mapping for 2F95F from 7AAE to 7AEE. > Correct canonical mapping for 2F9BF from 4D57 to 45D7. > Add the following entries to NormalizationCorrections.txt: > 2F868;2136A;36FC;4.0.0 # Corrigendum 4 > 2F874;5F33;5F53;4.0.0 # Corrigendum 4 > 2F91F;43AB;243AB;4.0.0 # Corrigendum 4 > 2F95F;7AAE;7AEE;4.0.0 # Corrigendum 4 > 2F9BF;4D57;45D7;4.0.0 # Corrigendum 4 > > The vote was: > > 13 for A (Adobe, Apple, Basis, HP, Justsystem, Microsoft, Oracle, > Peoplesoft, RLG, SAP, Sun, Sybase, Unisys) > 1 for B (IBM) > > Thank you to all for voting so promptly. The UTC will now support > correcting the five above mappings at next week's WG2 meeting. > > Lisa > > > > From owner-idn@ops.ietf.org Sat Dec 7 08:31:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27803 for ; Sat, 7 Dec 2002 08:31:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KerS-0000cC-00 for idn-data@psg.com; Sat, 07 Dec 2002 05:19:14 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18KerQ-0000bv-00 for idn@ops.ietf.org; Sat, 07 Dec 2002 05:19:13 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gB7DHHh17877; Sat, 7 Dec 2002 22:17:17 +0900 Date: Sat, 7 Dec 2002 22:17:17 +0900 From: Soobok Lee To: James Seng Cc: IETF/IDN WG Subject: Re: [idn] Fw: Results of BALLOT on Five Canonical Mapping Errors Message-ID: <20021207131717.GA29626@postel.co.kr> References: <008901c29dce$39c152f0$e400a8c0@JSENGTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008901c29dce$39c152f0$e400a8c0@JSENGTOSHIBA> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Thanks. I welcome Option A. This is the right decision! I hope to see Unicode 4.0 NFC also has corrected version of hangul jamo processing. My concern was that such false mappings become too heavily deployed and established to be corrected sometime later, due to critical use in IDN identifiers. But, Today, UTC decision opened the right way for correction. I fullheartedly appreciate for their honest efforts around this. Then, what would be done on Stringprep ? Will it follow future Unicode 4.0 ? Of course, it will take some time for authors to give the answer. So, I won't prompt them today... :-) Soobok Lee On Sat, Dec 07, 2002 at 04:54:17PM +0800, James Seng wrote: > fyi > > ----- Original Message ----- > From: "Lisa Moore" > To: "unicore" > Sent: Saturday, December 07, 2002 6:09 AM > Subject: Results of BALLOT on Five Canonical Mapping Errors > > > > Folks, > > > > We are closing the ballot - 14 out of 18 members have voted, a majority of > > full members voted for Option A: > > > > A) Fix the canonical mappings and issue another normalization corrigendum > > with corrected mappings in the Unicode 4.0 time frame, as follows: > > > > Make the following corrections in UnicodeData.txt for 4.0: > > Correct canonical mapping for 2F868 from 2136A to 36FC. > > Correct canonical mapping for 2F874 from 5F33 to 5F53. > > Correct canonical mapping for 2F91F from 43AB to 243AB. > > Correct canonical mapping for 2F95F from 7AAE to 7AEE. > > Correct canonical mapping for 2F9BF from 4D57 to 45D7. > > Add the following entries to NormalizationCorrections.txt: > > 2F868;2136A;36FC;4.0.0 # Corrigendum 4 > > 2F874;5F33;5F53;4.0.0 # Corrigendum 4 > > 2F91F;43AB;243AB;4.0.0 # Corrigendum 4 > > 2F95F;7AAE;7AEE;4.0.0 # Corrigendum 4 > > 2F9BF;4D57;45D7;4.0.0 # Corrigendum 4 > > > > The vote was: > > > > 13 for A (Adobe, Apple, Basis, HP, Justsystem, Microsoft, Oracle, > > Peoplesoft, RLG, SAP, Sun, Sybase, Unisys) > > 1 for B (IBM) > > > > Thank you to all for voting so promptly. The UTC will now support > > correcting the five above mappings at next week's WG2 meeting. > > > > Lisa > > > > > > > > > From owner-idn@ops.ietf.org Sat Dec 7 09:41:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28924 for ; Sat, 7 Dec 2002 09:41:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kg1M-0005Uh-00 for idn-data@psg.com; Sat, 07 Dec 2002 06:33:32 -0800 Received: from pheidippides.md.chalmers.se ([129.16.237.91]) by psg.com with esmtp (Exim 3.36 #2) id 18Kg1J-0005UT-00 for idn@ops.ietf.org; Sat, 07 Dec 2002 06:33:29 -0800 Received: from chalmers95a69n (dynamic-193-155.dialup.chalmers.se [129.16.193.155]) by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id gB7EWoD16023; Sat, 7 Dec 2002 15:32:50 +0100 (MET) From: "Kent Karlsson" To: "'Soobok Lee'" , "'James Seng'" Cc: "'IETF/IDN WG'" Subject: RE: [idn] Fw: Results of BALLOT on Five Canonical Mapping Errors Date: Sat, 7 Dec 2002 15:31:59 +0100 Message-ID: <000801c29dfd$6741afc0$9bc11081@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 Importance: Normal In-Reply-To: <20021207131717.GA29626@postel.co.kr> X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee: > Thanks. I welcome Option A. This is the right decision! > > I hope to see Unicode 4.0 NFC also has > corrected version of hangul jamo processing. My concern was > that such false mappings become too heavily deployed and established > to be corrected sometime later, due to critical use in IDN > identifiers. > But, Today, UTC decision opened the right way for correction. > I fullheartedly appreciate for their honest efforts around this. > > Then, what would be done on Stringprep ? Will it follow > future Unicode 4.0 ? Of course, it will take some time for authors > to give the answer. So, I won't prompt them today... :-) Since IDNs have not yet been deployed, there is still a VERY SMALL window of opportunity to fix this for IDNs. Once deployed, it will be much harder to fix this for IDNs, if at all possible. /Kent Karlsson > Soobok Lee From owner-idn@ops.ietf.org Sun Dec 8 21:04:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14566 for ; Sun, 8 Dec 2002 21:04:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LD12-0009pv-00 for idn-data@psg.com; Sun, 08 Dec 2002 17:47:24 -0800 Received: from qmail.netpia.com ([210.103.175.234] helo=netpia.com) by psg.com with smtp (Exim 3.36 #2) id 18LD0z-0009pa-00 for idn@ops.ietf.org; Sun, 08 Dec 2002 17:47:21 -0800 Received: (qmail 25357 invoked by uid 506); 9 Dec 2002 01:47:19 -0000 Received: from shlee@netpia.com by qmail by uid 503 with qmail-scanner-1.15 ( Clear:. Processed in 0.051478 secs); 09 Dec 2002 01:47:19 -0000 Received: from unknown (HELO netpia.com) (220.76.132.165) by 0 with SMTP; 9 Dec 2002 01:47:19 -0000 Message-ID: <3DF3F626.4060709@netpia.com> Date: Mon, 09 Dec 2002 10:47:18 +0900 From: Seungho Lee Organization: Netpia.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko-KR; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: ko-kr, ko MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] Newbie's questions implementing the [IDNA] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello. Implementing [IDNA] spec, I found an incomprehensible parts, so I ask for your helps... Question1. What kind of sequence of code points can be the input of ToUnicode Operation? Only punycoded one or all the other ones? If in case of only punycoded one, it seems that the [NAMEPREP] operation is unnecessary... (They will be in the ASCII range...) And if all the other ones are permitted, isn't it that the [NAMEPREP] can't convert it to punycoded one? (There is no punycode encoding process in Step2, and From Step3, it is solid that the input is the ACE code points starting with ACE prefix.) Question2. What is the return value of DNS? I think it is the IP address just like the usual DNS return value... For example, when I send the query 'PREFIX-089a.com'(this is a Korean character) to the resolver, the DNS will return the IP address for 'PREFIX-089a.com', won't it? But the [IDNA] spec says in page 3, - The ToUnicode opeartion is used when displaying names to users, for example "names obtained from a DNS zone". Does the DNS return a name? Question3. I came to think that the ToUnicode opeation is not included in the major flow of 'sending query and receiving the return values'. This is the flow I pictured... (only when a person is to use IDN for web surfing...) 1) An user inputs an IDN to the browser... ( Let's suppose the input was '?.com' ) 2) The IDNA client program takes the input. 3) Through the conversion operation ( the Step 4 would be ToASCII ), the input is changed to a punycoded one. ( '?.com' is converted to 'zq-089a.com' ; suppose the prefix is 'zq--' ) 4) The IDNA client program sends the query to the resolver. 5) The resolver sends the query to the designated name server. 6) The name server sends the query to the .com name server. ( Suppose the user-designated name server has no cache for the query and also is not the authoratitive name server) 7) .com name server sends the query to the zq--089a.com name server. 8) The zq--089a.com name server returns the IP address. 9) The client's resolver receive the return value(IP address) So, even though ToUnicode indispensible process of [IDNA], (because the spec requires that the uses should not see the incomprehensible punycoded names), I think it is outside the major flow of 'sending query and receiving the reutrn values'... Is this an acceptable thought? And where exactly the ToUnicode operation should be done? Between 3) and 4)? Regards, Lee ----- Seungho Lee Netpia.com, Korea. From owner-idn@ops.ietf.org Sun Dec 8 21:47:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15390 for ; Sun, 8 Dec 2002 21:47:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LDqn-000CRY-00 for idn-data@psg.com; Sun, 08 Dec 2002 18:40:53 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18LDqk-000CRM-00 for idn@ops.ietf.org; Sun, 08 Dec 2002 18:40:51 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18LDqj-0006Jx-00 for ; Sun, 08 Dec 2002 18:40:49 -0800 Date: Mon, 9 Dec 2002 02:40:49 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021209024049.GB23572@nicemice.net> Reply-To: IETF idn working group References: <3DF3F626.4060709@netpia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DF3F626.4060709@netpia.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Seungho Lee wrote: > What kind of sequence of code points can be the input of ToUnicode > Operation? Only punycoded one or all the other ones? Any sequence of Unicode code points can be the input of ToUnicode. The first paragraph of the ToUnicode section (4.2) says: The ToUnicode operation takes a sequence of Unicode code points that make up one label and returns a sequence of Unicode code points. If the input sequence is a label in ACE form, then the result is an equivalent internationalized label that is not in ACE form, otherwise the original sequence is returned unaltered. > And if all the other ones are permitted, isn't it that the [NAMEPREP] > can't convert it to punycoded one? Right, Nameprep does not perform Punycode encoding. > From Step3, it is solid that the input is the ACE code points starting > with ACE prefix. Step 3 says "Verify that the sequence begins with the ACE prefix." If the sequence does not in fact begin with the ACE prefix, then the verification fails. The second paragraph of the ToUnicode section says: ToUnicode never fails. If any step fails, then the original input sequence is returned immediately in that step. > What is the return value of DNS? It depends on the query. You can ask the DNS for A records, which contain IP addresses, or PTR records, which contain domain names, or MX records, which contain mail exchanger information, or NS records, which contain name server information, and so on. > I came to think that the ToUnicode operation is not included in the > major flow of 'sending query and receiving the return values'. ToUnicode is useful for displaying names to users. That's the only purpose mentioned in the IDNA spec for ToUnicode. The "major flow" you have in mind does not involve displaying names to users, right? Therefore ToUnicode is not useful there. > And where exactly the ToUnicode operation should be done? Anywhere between where the application receives the domain name and where the application displays the domain name to the user. Domain names might be recieved in message headers, or in HTML markup, for example. AMC From owner-idn@ops.ietf.org Sun Dec 8 21:52:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15452 for ; Sun, 8 Dec 2002 21:52:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LDwd-000CmE-00 for idn-data@psg.com; Sun, 08 Dec 2002 18:46:55 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18LDwa-000Cm1-00 for idn@ops.ietf.org; Sun, 08 Dec 2002 18:46:52 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gB92ion23151; Mon, 9 Dec 2002 11:44:50 +0900 Date: Mon, 9 Dec 2002 11:44:50 +0900 From: Soobok Lee To: Seungho Lee Cc: idn@ops.ietf.org Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021209024449.GA31524@postel.co.kr> References: <3DF3F626.4060709@netpia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DF3F626.4060709@netpia.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, Dec 09, 2002 at 10:47:18AM +0900, Seungho Lee wrote: > Implementing [IDNA] spec, I found an incomprehensible parts, > so I ask for your helps... This list is not for a tutorial session, but i'll answer for your questions as a fellow korean. > > Question1. > What kind of sequence of code points can be the input of ToUnicode > Operation? > Only punycoded one or all the other ones? any legitimate labels. LDH domains or PREFIX--***. utf-8 and legacy-encoded labels are for presentation-only, and not for the wire format according to IDNA. > If in case of only punycoded one, it seems that the [NAMEPREP] operation > is unnecessary... > (They will be in the ASCII range...) Necessary for verification so that the output of ToUnicode must not contains unnameprepped/prohibited/(unassigned) codepoints. IF the output contain such ones, the input label should be displayed as it is in the form of the punycode encoding. > And if all the other ones are permitted, isn't it that the [NAMEPREP] What do you mean by "all the other ones"? Only LDH and PREFIX--** ones are allowed as valid inputs to ToUnicode according to IDNA. ToUnicode does not perform "legacy to unicode conversion", which are done before ToASCII is performed. > can't convert it to punycoded one? > (There is no punycode encoding process in Step2, > and From Step3, it is solid that the input is the ACE code points > starting with ACE prefix.) I can't understand your question. > > Question2. > What is the return value of DNS? > I think it is the IP address just like the usual DNS return value... Right. > For example, when I send the query 'PREFIX-089a.com'(this is a Korean > character) to the resolver, > the DNS will return the IP address for 'PREFIX-089a.com', won't it? Yes. PREFIX--** works like a usual LDH label. > > But the [IDNA] spec says in page 3, > - The ToUnicode opeartion is used when displaying names to users, > for example "names obtained from a DNS zone". > > Does the DNS return a name? "DNS zone" dones not mean the DNS server query response. It just mean "Visual representaion of zone file contents". You should read IDNA again. ToASCII is performed before DNS resolving. ToUnicode is for display and verification purpose for the punycode encoded labels later. > > Question3. > I came to think that the ToUnicode opeation is not included in the major > flow of 'sending query and receiving the return values'. > This is the flow I pictured... (only when a person is to use IDN for web > surfing...) > 1) An user inputs an IDN to the browser... ( Let's suppose the input was > '?.com' ) > 2) The IDNA client program takes the input. > 3) Through the conversion operation ( the Step 4 would be ToASCII ), the > input is changed to a punycoded one. > ( '?.com' is converted to 'zq-089a.com' ; suppose the prefix is 'zq--' ) > 4) The IDNA client program sends the query to the resolver. > 5) The resolver sends the query to the designated name server. > 6) The name server sends the query to the .com name server. > ( Suppose the user-designated name server has no cache for the query and > also is not the authoratitive name server) > 7) .com name server sends the query to the zq--089a.com name server. > 8) The zq--089a.com name server returns the IP address. > 9) The client's resolver receive the return value(IP address) > > So, even though ToUnicode indispensible process of [IDNA], (because the > spec requires that the uses should not see > the incomprehensible punycoded names), I think it is outside the major > flow of 'sending query and receiving the reutrn values'... > > Is this an acceptable thought? > > And where exactly the ToUnicode operation should be done? > Between 3) and 4)? Sorry. Nowhere in your all steps. When an user inputs an IDN label, he/she already see native IDN label , not punycode-encoded one. Why does he need toUnicode there? If prenameprepped form and nameprepped form have different glyphs (uppercase inputs?), step 10) will be added to perform toUnicode for displaying the nameprepped (lowercase?) one. But even in this case, i think respecting the user input in the display/location bar is preferrable. Soobok Lee From owner-idn@ops.ietf.org Mon Dec 9 18:32:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08140 for ; Mon, 9 Dec 2002 18:32:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXAW-000Kw8-00 for idn-data@psg.com; Mon, 09 Dec 2002 15:18:32 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18LXAU-000Kvu-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 15:18:30 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18LXAS-0008TI-00 for ; Mon, 09 Dec 2002 15:18:28 -0800 Date: Mon, 9 Dec 2002 23:18:28 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021209231828.GA32412@nicemice.net> Reply-To: IETF idn working group References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021209024449.GA31524@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > Only LDH and PREFIX--** ones are allowed as valid inputs to ToUnicode > according to IDNA. According to the first paragraph of the ToUnicode section, any sequence of Unicode code points can be the input of ToUnicode. > the output of ToUnicode must not contains > unnameprepped/prohibited/(unassigned) codepoints. The output of ToUnicode can contain unnameprepped, prohibited, and unassigned code points. Simply feed such a string as input to ToUnicode, and the string will be output unaltered by ToUnicode. > ToUnicode is for display and verification purpose for the punycode > encoded labels later. IDNA uses ToUnicode for exactly two purposes: to force labels to human-friendly form before displaying them to users, and to define the concept of ACE label (which is any label that ToUnicode would alter). IDNA uses ToASCII for exactly two purposes: to define the concept of internationalized label (which is anything that ToASCII can be applied to without failing), and to force labels to ASCII form before putting them into slots (protocol fields, function arguments, etc). AMC From owner-idn@ops.ietf.org Mon Dec 9 18:58:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08986 for ; Mon, 9 Dec 2002 18:58:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXfA-000OIA-00 for idn-data@psg.com; Mon, 09 Dec 2002 15:50:12 -0800 Received: from smtp-server1.tampabay.rr.com ([65.32.1.34]) by psg.com with esmtp (Exim 3.36 #2) id 18LXf7-000OHs-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 15:50:09 -0800 Received: from e0g0l1 (dt1b0n6e.tampabay.rr.com [24.92.212.110]) by smtp-server1.tampabay.rr.com (8.12.2/8.12.2) with SMTP id gB9No6dt000809 for ; Mon, 9 Dec 2002 18:50:06 -0500 (EST) Message-ID: <001b01c29fe0$9af17000$6ed45c18@tampabay.rr.com> From: "William Blackwood" To: "IETF idn working group" References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> Subject: Re: [idn] Newbie's questions implementing the [IDNA] Date: Mon, 9 Dec 2002 19:10:53 -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 X-Spam-Status: No, hits=1.5 required=5.0 tests=MAILTO_TO_REMOVE,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam, Do you have any estimate when the RFC is going to be published? How far behind, in terms of calendar months/years is this working group's output according to the original schedule? Thank you, William ----- Original Message ----- From: "Adam M. Costello" To: Sent: Monday, December 09, 2002 6:18 PM Subject: Re: [idn] Newbie's questions implementing the [IDNA] > Soobok Lee wrote: > > > Only LDH and PREFIX--** ones are allowed as valid inputs to ToUnicode > > according to IDNA. > > According to the first paragraph of the ToUnicode section, any sequence > of Unicode code points can be the input of ToUnicode. > > > the output of ToUnicode must not contains > > unnameprepped/prohibited/(unassigned) codepoints. > > The output of ToUnicode can contain unnameprepped, prohibited, and > unassigned code points. Simply feed such a string as input to > ToUnicode, and the string will be output unaltered by ToUnicode. > > > ToUnicode is for display and verification purpose for the punycode > > encoded labels later. > > IDNA uses ToUnicode for exactly two purposes: to force labels to > human-friendly form before displaying them to users, and to define the > concept of ACE label (which is any label that ToUnicode would alter). > > IDNA uses ToASCII for exactly two purposes: to define the concept of > internationalized label (which is anything that ToASCII can be applied > to without failing), and to force labels to ASCII form before putting > them into slots (protocol fields, function arguments, etc). > > AMC > From owner-idn@ops.ietf.org Mon Dec 9 19:08:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09512 for ; Mon, 9 Dec 2002 19:08:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXuT-000Pqh-00 for idn-data@psg.com; Mon, 09 Dec 2002 16:06:01 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18LXuP-000PqA-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 16:05:58 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gBA03mL13326; Tue, 10 Dec 2002 09:03:48 +0900 Date: Tue, 10 Dec 2002 09:03:48 +0900 From: Soobok Lee To: IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021210000347.GR31524@postel.co.kr> References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021209231828.GA32412@nicemice.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, Dec 09, 2002 at 11:18:28PM +0000, Adam M. Costello wrote: > Soobok Lee wrote: > > > Only LDH and PREFIX--** ones are allowed as valid inputs to ToUnicode > > according to IDNA. > > According to the first paragraph of the ToUnicode section, any sequence > of Unicode code points can be the input of ToUnicode. You are right. but, many novices would carelessly misinterpret "toUnicode()" as doing some legacy to unicode conversion (if he did not carefully read drafts or API manuals), and they may actually call "toUnicode("legacy encoded IDN")" expecting that. > > > the output of ToUnicode must not contains > > unnameprepped/prohibited/(unassigned) codepoints. > > The output of ToUnicode can contain unnameprepped, prohibited, and > unassigned code points. Simply feed such a string as input to > ToUnicode, and the string will be output unaltered by ToUnicode. right. IDNA states that such outputs should not be displayed as native ones, but just as ASCII ones as it is. "must not" is meant for that. I think it is clear enough in drafts. > > > ToUnicode is for display and verification purpose for the punycode > > encoded labels later. > > IDNA uses ToUnicode for exactly two purposes: to force labels to > human-friendly form before displaying them to users, and to define the > concept of ACE label (which is any label that ToUnicode would alter). > > IDNA uses ToASCII for exactly two purposes: to define the concept of > internationalized label (which is anything that ToASCII can be applied > to without failing), and to force labels to ASCII form before putting > them into slots (protocol fields, function arguments, etc). Thanks. > > AMC From owner-idn@ops.ietf.org Mon Dec 9 19:34:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10955 for ; Mon, 9 Dec 2002 19:34:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LYHa-0002MP-00 for idn-data@psg.com; Mon, 09 Dec 2002 16:29:54 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18LYHY-0002M1-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 16:29:52 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18LYHT-0000Tf-00 for ; Mon, 09 Dec 2002 16:29:47 -0800 Date: Tue, 10 Dec 2002 00:29:46 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021210002946.GD32412@nicemice.net> Reply-To: IETF idn working group References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021210000347.GR31524@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > > The output of ToUnicode can contain unnameprepped, prohibited, and > > unassigned code points. Simply feed such a string as input to > > ToUnicode, and the string will be output unaltered by ToUnicode. > > right. IDNA states that such outputs should not be displayed as native > ones, but just as ASCII ones as it is. "must not" is meant for that. > I think it is clear enough in drafts. I don't know what you could be referring to. Suppose X is a string consisting entirely of uppercase Greek letters. X is not nameprepped, because nameprepped things don't contain uppercase. X contains no ASCII characters. ToUnicode(X) equals X, exactly, which means it is perfectly acceptable to display X. AMC From owner-idn@ops.ietf.org Mon Dec 9 20:03:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11908 for ; Mon, 9 Dec 2002 20:03:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LYZ0-0004Di-00 for idn-data@psg.com; Mon, 09 Dec 2002 16:47:54 -0800 Received: from m3001.hostcentric.net ([216.157.79.237]) by psg.com with smtp (Exim 3.36 #2) id 18LYYw-0004CR-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 16:47:50 -0800 Received: (qmail 9220 invoked by alias); 10 Dec 2002 00:47:41 -0000 Received: from unknown (HELO DAVIS1) (32.97.110.142) by 0 with SMTP; 10 Dec 2002 00:47:41 -0000 Message-ID: <009b01c29fe5$ba848790$7ede2b09@DAVIS1> From: "Mark Davis" To: "Soobok Lee" , "James Seng" Cc: "IETF/IDN WG" , "Karlsson Kent - keka" , "Kent Karlsson" References: <008901c29dce$39c152f0$e400a8c0@JSENGTOSHIBA> <20021207131717.GA29626@postel.co.kr> Subject: Re: [idn] Fw: Results of BALLOT on Five Canonical Mapping Errors Date: Mon, 9 Dec 2002 16:47:31 -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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.7 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT_OE version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit One should not read too much into this decision. The Unicode stability policies only permit extremely constrained changes; see: http://www.unicode.org/standard/stability_policy.html#Normalization Jamo mappings would not fall under those criteria. However, Kent Karlsson has been working on additional mappings and information for aiding in the processing of Hangul/Jamo characters. Such mappings the UTC is open to considering, and you might contact him to find out the status of that effort. Mark __________________________________ http://www.macchiato.com ► “Eppur si muove” ◄ ----- Original Message ----- From: "Soobok Lee" To: "James Seng" Cc: "IETF/IDN WG" Sent: Saturday, December 07, 2002 05:17 Subject: Re: [idn] Fw: Results of BALLOT on Five Canonical Mapping Errors > > Thanks. I welcome Option A. This is the right decision! > > I hope to see Unicode 4.0 NFC also has > corrected version of hangul jamo processing. My concern was > that such false mappings become too heavily deployed and established > to be corrected sometime later, due to critical use in IDN identifiers. > But, Today, UTC decision opened the right way for correction. > I fullheartedly appreciate for their honest efforts around this. > > Then, what would be done on Stringprep ? Will it follow > future Unicode 4.0 ? Of course, it will take some time for authors > to give the answer. So, I won't prompt them today... :-) > > Soobok Lee > > > On Sat, Dec 07, 2002 at 04:54:17PM +0800, James Seng wrote: > > fyi > > > > ----- Original Message ----- > > From: "Lisa Moore" > > To: "unicore" > > Sent: Saturday, December 07, 2002 6:09 AM > > Subject: Results of BALLOT on Five Canonical Mapping Errors > > > > > > > Folks, > > > > > > We are closing the ballot - 14 out of 18 members have voted, a majority of > > > full members voted for Option A: > > > > > > A) Fix the canonical mappings and issue another normalization corrigendum > > > with corrected mappings in the Unicode 4.0 time frame, as follows: > > > > > > Make the following corrections in UnicodeData.txt for 4.0: > > > Correct canonical mapping for 2F868 from 2136A to 36FC. > > > Correct canonical mapping for 2F874 from 5F33 to 5F53. > > > Correct canonical mapping for 2F91F from 43AB to 243AB. > > > Correct canonical mapping for 2F95F from 7AAE to 7AEE. > > > Correct canonical mapping for 2F9BF from 4D57 to 45D7. > > > Add the following entries to NormalizationCorrections.txt: > > > 2F868;2136A;36FC;4.0.0 # Corrigendum 4 > > > 2F874;5F33;5F53;4.0.0 # Corrigendum 4 > > > 2F91F;43AB;243AB;4.0.0 # Corrigendum 4 > > > 2F95F;7AAE;7AEE;4.0.0 # Corrigendum 4 > > > 2F9BF;4D57;45D7;4.0.0 # Corrigendum 4 > > > > > > The vote was: > > > > > > 13 for A (Adobe, Apple, Basis, HP, Justsystem, Microsoft, Oracle, > > > Peoplesoft, RLG, SAP, Sun, Sybase, Unisys) > > > 1 for B (IBM) > > > > > > Thank you to all for voting so promptly. The UTC will now support > > > correcting the five above mappings at next week's WG2 meeting. > > > > > > Lisa > > > > > > > > > > > > > > > > From owner-idn@ops.ietf.org Mon Dec 9 20:15:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12232 for ; Mon, 9 Dec 2002 20:15:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LYoF-0005wU-00 for idn-data@psg.com; Mon, 09 Dec 2002 17:03:39 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18LYoC-0005wE-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 17:03:36 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18LYoA-0000a3-00 for ; Mon, 09 Dec 2002 17:03:34 -0800 Date: Tue, 10 Dec 2002 01:03:34 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021210010334.GF32412@nicemice.net> Reply-To: IETF idn working group References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <001b01c29fe0$9af17000$6ed45c18@tampabay.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001b01c29fe0$9af17000$6ed45c18@tampabay.rr.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk William Blackwood wrote: > Do you have any estimate when the RFC is going to be published? I don't. It's now in the hands of the RFC editor. People with more IETF experience than I have might be able to guess how long it will take. > How far behind, in terms of calendar months/years is this working > group's output according to the original schedule? I joined the working group after it was already a year old, so I'm not sure I ever saw the original schedule. The only schedule I can find now is shown here: http://www.ietf.org/html.charters/idn-charter.html It gives 2001-Jun as the goal for working group last call (which actually happened in 2002-Jan). The schedule gives no goals for IESG approval (which happened in 2002-Oct) or RFC publication (which has yet to happen). AMC From owner-idn@ops.ietf.org Mon Dec 9 20:19:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12325 for ; Mon, 9 Dec 2002 20:19:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LYio-00058G-00 for idn-data@psg.com; Mon, 09 Dec 2002 16:58:02 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18LYil-00057s-00 for idn@ops.ietf.org; Mon, 09 Dec 2002 16:57:59 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gBA0toj14441; Tue, 10 Dec 2002 09:55:50 +0900 Date: Tue, 10 Dec 2002 09:55:50 +0900 From: Soobok Lee To: IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021210005550.GS31524@postel.co.kr> References: <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021210002946.GD32412@nicemice.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, Dec 10, 2002 at 12:29:46AM +0000, Adam M. Costello wrote: > Soobok Lee wrote: > > > > The output of ToUnicode can contain unnameprepped, prohibited, and > > > unassigned code points. Simply feed such a string as input to > > > ToUnicode, and the string will be output unaltered by ToUnicode. > > > > right. IDNA states that such outputs should not be displayed as native > > ones, but just as ASCII ones as it is. "must not" is meant for that. > > I think it is clear enough in drafts. > > I don't know what you could be referring to. Suppose X is a string > consisting entirely of uppercase Greek letters. X is not nameprepped, > because nameprepped things don't contain uppercase. X contains no ASCII > characters. ToUnicode(X) equals X, exactly, which means it is perfectly > acceptable to display X. I mean that Punycode(X) [not Punycode(NAMEPREP(X)), not X ] can be inserted into RFC822 message headers. In that case, ToUnicode(Punycode(X)) should be treated differently than ToUnicode(Punycode(Nameprep(X))) . You are right if X is non-ASCII input, because toUnicode(X)==X. > > AMC From owner-idn@ops.ietf.org Tue Dec 10 10:08:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09468 for ; Tue, 10 Dec 2002 10:08:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Llot-0006pH-00 for idn-data@psg.com; Tue, 10 Dec 2002 06:57:11 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 18Lloq-0006p4-00 for idn@ops.ietf.org; Tue, 10 Dec 2002 06:57:08 -0800 Received: from lns02v-3-237.w.club-internet.fr ([212.194.26.237] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18Lloj-0003Z8-00; Tue, 10 Dec 2002 06:57:02 -0800 Message-Id: <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Dec 2002 13:12:31 +0100 To: Soobok Lee , IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Newbie's questions implementing the [IDNA] In-Reply-To: <20021210005550.GS31524@postel.co.kr> References: <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-275842C5; boundary="=======2FE67F9F=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======2FE67F9F======= Content-Type: text/plain; x-avg-checked=avg-ok-275842C5; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 01:55 10/12/02, Soobok Lee wrote: >You are right if X is non-ASCII input, because toUnicode(X)==X. if (ToASCII(nameprep(ToUnicode(ascii_text))) == ascii_text) babelname=true; if (babelname) "iesg--ascii_text" will display in ASCII mode on most of the systems while having been registered, and possibly TMed, as ToUnicode(ascii_text). I documented Adam with cases where babelname==true. Among them "coca-cola", "ibm", "vint-cerf", "adam-costello". IMHO multi-sub-profiling would keep interoperability while limiting such a practical inoperability. We could also investigate sub-profile SLDs as permitting better management and support and having ASCII labels as non protected 3LDs. jfc --=======2FE67F9F=======-- From owner-idn@ops.ietf.org Tue Dec 10 15:35:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20075 for ; Tue, 10 Dec 2002 15:35:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lqzm-000Hb4-00 for idn-data@psg.com; Tue, 10 Dec 2002 12:28:46 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18Lqzi-000HaX-00 for idn@ops.ietf.org; Tue, 10 Dec 2002 12:28:42 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14648; Tue, 10 Dec 2002 12:28:10 -0800 (PST) Received: from localhost (d-mpk17-88-129.Eng.Sun.COM [129.146.88.129]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gBAKS8H13994; Tue, 10 Dec 2002 21:28:08 +0100 (MET) Date: Tue, 10 Dec 2002 21:24:49 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Newbie's questions implementing the [IDNA] To: Seungho Lee Cc: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk > Question2. > What is the return value of DNS? > I think it is the IP address just like the usual DNS return value... > For example, when I send the query 'PREFIX-089a.com'(this is a Korean > character) to the resolver, > the DNS will return the IP address for 'PREFIX-089a.com', won't it? > > But the [IDNA] spec says in page 3, > - The ToUnicode opeartion is used when displaying names to users, > for example "names obtained from a DNS zone". > > Does the DNS return a name? An example of where a DNS lookup would return a name is when doing a reverse lookup i.e. a PTR lookup in the DNS. For example, 4.3.2.1.in-addr.arpa would return 'PREFIX-089a.com' to which you would apply ToUnicode before displaying it to the user. Erik From owner-idn@ops.ietf.org Tue Dec 10 20:18:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26872 for ; Tue, 10 Dec 2002 20:18:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LvP2-0004wN-00 for idn-data@psg.com; Tue, 10 Dec 2002 17:11:08 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18LvP0-0004wA-00 for idn@ops.ietf.org; Tue, 10 Dec 2002 17:11:06 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18LvOz-0002pY-00 for ; Tue, 10 Dec 2002 17:11:05 -0800 Date: Wed, 11 Dec 2002 01:11:04 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021211011104.GB8881@nicemice.net> Reply-To: IETF idn working group References: <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_08_13,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "JFC (Jefsey) Morfin" wrote: > if (ToASCII(nameprep(ToUnicode(ascii_text))) == ascii_text) babelname=true; > if (babelname) "iesg--ascii_text" will display in ASCII mode on most > of the systems while having been registered, and possibly TMed, as > ToUnicode(ascii_text). Your reference to "iesg--ascii_text" suggests that you expect ascii_text not to include the ACE prefix. But in that case, ToUnicode(ascii_text) is simply ascii_text itself, because ToUnicode won't alter a string that doesn't begin with the ACE prefix. > I documented Adam with cases where babelname==true. Among them > "coca-cola", "ibm", "vint-cerf", "adam-costello". babelname, as you've defined it, would be true for *every* lowercase ASCII string (up to 63 characters). I think the feature of those example strings that you're interested in is that if you prepend the ACE prefix to them, the result is an ACE (which is, by definition, something that ToUnicode would alter). So the test you're looking for is: ToUnicode(IESG--ascii_text) != IESG--ascii_text which is roughly approximated by this test: Punyencode(Nameprep(Punydecode(ascii_text))) == ascii_text which is similar in form to the test you proposed, but ToASCII is very different from Punyencode, and ToUnicode is very different from Punydecode. > if (babelname) "iesg--ascii_text" will display in ASCII mode on most > of the systems while having been registered, and possibly TMed, as > ToUnicode(ascii_text). IESG--ascii_text will be displayed in non-ASCII form by IDN-aware applications capable of displaying the characters, and will be displayed in ASCII form otherwise. AMC From owner-idn@ops.ietf.org Tue Dec 10 20:23:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26996 for ; Tue, 10 Dec 2002 20:23:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LvTP-000597-00 for idn-data@psg.com; Tue, 10 Dec 2002 17:15:39 -0800 Received: from imsmq09.netvigator.com ([218.102.48.122]) by psg.com with smtp (Exim 3.36 #2) id 18LvTH-00058p-00 for idn@ops.ietf.org; Tue, 10 Dec 2002 17:15:31 -0800 Received: (qmail 31840 invoked from network); 11 Dec 2002 01:15:28 -0000 Received: from pcd409200.netvigator.com (HELO EDMON15) (203.218.199.200) by imsmq09.netvigator.com with SMTP; 11 Dec 2002 01:15:28 -0000 Message-ID: <042701c2a0b2$c95551f0$0202a8c0@neteka.inc> From: "Edmon Chung" To: Subject: [idn] Fw: Newswire: WALID Transfers Key Internet Patent to IDN Technologies Date: Tue, 10 Dec 2002 20:15:25 -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 X-Spam-Status: No, hits=0.7 required=5.0 tests=CLICK_BELOW,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_OE version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I assume most people have read this release from WALID. Just in case you havent. Here it is for your reference. Edmon ----- Original Message ----- Sent: Monday, December 09, 2002 12:18 PM Subject: Newswire: WALID Transfers Key Internet Patent to IDN Technologies > > 1. WALID Transfers Key Internet Patent to IDN Technologies, a Joint Venture with IP Holdings; Internationalized Domain Name Patent to be Licensed and Enforced. > NPA 02-50 94804839 NDN- 214-0486-6746-6 > > NO-AUTHOR > > 2002-12-03 > PP. NYTU01703122002 > DOCUMENT TYPE- PR Newswire > SOURCE OF ARTICLE(S)- Newswire > LANGUAGE- English, (DEF) > > ANN ARBOR, Mich. -- WALID, Inc. (WALID), a pioneer in internationalized domain name (IDN) technology, announced today that it has decided to aggressively license its patent on internationalizing domain names that enables Internet users worldwide to access domain names and addresses with foreign, non-English characters. > > To this end, WALID has transferred ownership of its key Internet patent and related intellectual property (IDN Patents) to IDN Technologies LLC (IDNT) with a mandate to license and enforce the IDN Patents. IDNT is a joint venture between WALID and IP Holdings LLC (IP Holdings), an intellectual property incubator focused on patent commercialization. > > The IDN Patents provide fundamental and key technology for IDNs. The Internet Engineering Task Force's RFC 1035 standard does not allow non-English characters in domain names, which has hampered the proliferation of the Internet in non-English-speaking countries. Using the IDN patented technology, Internet users can access web pages and use various Internet applications with domain names that include foreign language and other special characters. The popularity of IDNs is expected to surge in view of the pent- up demand of non-English speaking Internet users and the Internet Engineering Steering Group's recent approval on October 24, 2002 of a proposed standard for "Internationalizing Domain Names in Applications". > > "We plan to pursue an aggressive licensing program to ensure the broad proliferation of Walid's technology," said Alexander Poltorak, managing director of IP Holdings. "Walid has created a fundamental technology which will undoubtedly drive the next round of Internet expansion into the non- English-speaking world. Soon people will be free to speak their native tongue anywhere on the Internet." > "Over the past several years, WALID tried to commercialize the patented technology," said Dr. Walid Tout, WALID's co-founder and the inventor of the patented technology. "Now that our technology is a de facto standard, we are confident that IDN Technologies, backed by IP Holdings, will successfully license our patents to the Internet industry," he concluded. > > Dr. Tout's IDN technology makes it possible for foreign language users to go beyond the English characters that currently control the Internet domain names . Using the patented technology, Internet users can access web pages and use various Internet applications with domain names that include foreign language and other special characters. This proprietary technology is protected by the U.S. Patent No. 6,182,148, pending U.S. patent applications and corresponding foreign patent applications. > > IDNT is exploring a number of alternatives pertaining to the licensing of the IDN Patents, including ways to make the technology widely available so as to promote the growth and use of IDNs. > > About IDN Technologies LLC > IDN Technologies LLC, headquartered in Suffern, New York, is a joint venture between WALID, Inc. and IP Holdings LLC, a leading intellectual property incubator also located in Suffern, N.Y. IDN Technologies was formed for the purpose of licensing and enforcing U.S. PatentNo. 6,182,148, a related pending U.S. application, and correspondingforeign patent applications throughout the world. For further information on IDN Technologies contact IDN Technologies LLC, Montebello Park, 75 Montebello Road, Suffern, NY 10901; telephone: (845) 368-4000; or e-mail: info@idntech.com. > > About WALID, Inc. > Headquartered in Ann Arbor, Michigan, WALID, Inc. was established in 1999 to provide a complete solution for registering and resolving multilingual Internet domain names . The WALID technology enables businesses, organizations, and individuals to communicate, conduct global commerce and establish a unique Internet presence in any language. > > About IP Holdings LLC > IP Holdings LLC is an intellectual property incubator with a focus on patent commercialization. For further information on IP Holdings contact IP Holdings LLC, Montebello Park, 75 Montebello Road, Suffern, NY 10901; telephone: (845) 368-4000; e-mail: info@ip-holdings.com or visit www.ip-holdings.com. > MAKE YOUR OPINION COUNT - Click Here http://tbutton.prnewswire.com/prn/11690X07439176 > CONTACT: Joel Strasser of WALID, Inc., +1-212-447-9292 ext. 14 > Web site: http://www.ip-holdings.com/ > From owner-idn@ops.ietf.org Wed Dec 11 08:10:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03437 for ; Wed, 11 Dec 2002 08:10:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M6Ub-0008US-00 for idn-data@psg.com; Wed, 11 Dec 2002 05:01:37 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 18M6UX-0008UG-00 for idn@ops.ietf.org; Wed, 11 Dec 2002 05:01:34 -0800 Received: from lns10m-8-56.w.club-internet.fr ([213.44.191.56] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18M6UV-0002rz-00 for idn@ops.ietf.org; Wed, 11 Dec 2002 05:01:32 -0800 Message-Id: <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Dec 2002 05:05:22 +0100 To: IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Newbie's questions implementing the [IDNA] In-Reply-To: <20021211011104.GB8881@nicemice.net> References: <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-12E018DF; boundary="=======2C14DA9=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-0.5 required=5.0 tests=DATE_IN_PAST_06_12,DEAR_SOMEBODY,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======2C14DA9======= Content-Type: text/plain; x-avg-checked=avg-ok-12E018DF; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Dear Adam, On 02:11 11/12/02, Adam M. Costello said: >"JFC (Jefsey) Morfin" wrote: > > if (ToASCII(nameprep(ToUnicode(ascii_text))) == ascii_text) babelname=true; > > if (babelname) "iesg--ascii_text" will display in ASCII mode on most > > of the systems while having been registered, and possibly TMed, as > > ToUnicode(ascii_text). > >Your reference to "iesg--ascii_text" suggests that you expect ascii_text >not to include the ACE prefix. But in that case, ToUnicode(ascii_text) >is simply ascii_text itself, because ToUnicode won't alter a string that >doesn't begin with the ACE prefix. True. I was interested in the general idea. >which is roughly approximated by this test: > > Punyencode(Nameprep(Punydecode(ascii_text))) == ascii_text actually it is: - punycode_encode () and punnycode_decode.() - and I am not interested in nameprep but just in making sure the Unicode stay invarient as per Paull Hoffman's draft. so it would be Paul_Hoffman_invarient() if I am correct. >which is similar in form to the test you proposed, but ToASCII is >very different from Punyencode, and ToUnicode is very different from >Punydecode. I am only interested to knowi if such a program permits me to correctly determine Unicode IDNs of which the >IESG--ascii_text will be displayed in non-ASCII form by IDN-aware >applications capable of displaying the characters, and will be displayed >in ASCII form otherwise. as "iesg--coca-cola.com" or "iesg--jonathan-cohen.net" or "iesg--vint-cerf.org". Thank you. jfc --=======2C14DA9=======-- From owner-idn@ops.ietf.org Wed Dec 11 08:45:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04681 for ; Wed, 11 Dec 2002 08:45:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M73u-0009fD-00 for idn-data@psg.com; Wed, 11 Dec 2002 05:38:06 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #2) id 18M73q-0009f1-00 for idn@ops.ietf.org; Wed, 11 Dec 2002 05:38:03 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gBBDbxgV1275428; Wed, 11 Dec 2002 14:38:00 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1000) id A994F10F29; Wed, 11 Dec 2002 14:37:59 +0100 (CET) Date: Wed, 11 Dec 2002 14:37:59 +0100 From: Stephane Bortzmeyer To: "JFC (Jefsey) Morfin" Cc: IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021211133759.GA14221@nic.fr> References: <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, UPPERCASE_25_50,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, Dec 11, 2002 at 05:05:22AM +0100, JFC (Jefsey) Morfin wrote a message of 48 lines which said: > as "iesg--coca-cola.com" or "iesg--jonathan-cohen.net" or > "iesg--vint-cerf.org". The Unicode strings which IDN-encodes into "iesg--coca-cola.com" is: LATIN SMALL LETTER C (Basic Latin) LATIN SMALL LETTER O (Basic Latin) ORIYA DIGIT THREE (Oriya) ORIYA DIGIT THREE (Oriya) LATIN SMALL LETTER C (Basic Latin) LATIN SMALL LETTER A (Basic Latin) FULL STOP (Basic Latin) LATIN SMALL LETTER C (Basic Latin) LATIN SMALL LETTER O (Basic Latin) LATIN SMALL LETTER M (Basic Latin) In what language does it make sense? It is certainly possible to find funny ACE encodings which have a meaningful Unicode form but it is not obvious. From owner-idn@ops.ietf.org Wed Dec 11 11:10:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10554 for ; Wed, 11 Dec 2002 11:10:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M9HG-000F74-00 for idn-data@psg.com; Wed, 11 Dec 2002 08:00:02 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 18M9HB-000F6j-00 for idn@ops.ietf.org; Wed, 11 Dec 2002 07:59:57 -0800 Received: from lns10m-8-56.w.club-internet.fr ([213.44.191.56] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18M9H7-0000pq-00; Wed, 11 Dec 2002 07:59:54 -0800 Message-Id: <5.1.0.14.0.20021211162651.02793240@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Dec 2002 16:50:00 +0100 To: Stephane Bortzmeyer From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Newbie's questions implementing the [IDNA] Cc: IETF idn working group In-Reply-To: <20021211133759.GA14221@nic.fr> References: <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-12E018DF; boundary="=======4C8A7731=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=1.4 required=5.0 tests=DRASTIC_REDUCED,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk --=======4C8A7731======= Content-Type: text/plain; x-avg-checked=avg-ok-12E018DF; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 14:37 11/12/02, Stephane Bortzmeyer wrote: >On Wed, Dec 11, 2002 at 05:05:22AM +0100, > JFC (Jefsey) Morfin wrote > a message of 48 lines which said: > > > as "iesg--coca-cola.com" or "iesg--jonathan-cohen.net" or > > "iesg--vint-cerf.org". > >The Unicode strings which IDN-encodes into "iesg--coca-cola.com" is: >LATIN SMALL LETTER C (Basic Latin) >LATIN SMALL LETTER O (Basic Latin) >ORIYA DIGIT THREE (Oriya) >ORIYA DIGIT THREE (Oriya) >LATIN SMALL LETTER C (Basic Latin) >LATIN SMALL LETTER A (Basic Latin) >FULL STOP (Basic Latin) >LATIN SMALL LETTER C (Basic Latin) >LATIN SMALL LETTER O (Basic Latin) >LATIN SMALL LETTER M (Basic Latin) My program tells: u+0063 u+006F u+0B69 u+0B69 u+0063 u+0061 . fr are we in agreement? >In what language does it make sense? It is certainly possible to find >funny ACE encodings which have a meaningful Unicode form but it is not >obvious. The Unicode form is of no real interest except that the more character sets the more chances the IDN displays in ACE form and the less chances it is already registered as a multilingual design, TM or even patent (?). The target is only to see printed "From: iesg--coca-cola.com" when the registrant sends a mail. I feel multi-sub-profiling could drastically reduce that capacity. But what about u+A317.com? Even then it will print in most of the cases as iesg-ibm.com. Again, unless I have misunderstood something. This is what I ask. jfc --=======4C8A7731=======-- From owner-idn@ops.ietf.org Wed Dec 11 11:31:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11326 for ; Wed, 11 Dec 2002 11:31:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M9dZ-000G5u-00 for idn-data@psg.com; Wed, 11 Dec 2002 08:23:05 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #2) id 18M9dV-000G5i-00 for idn@ops.ietf.org; Wed, 11 Dec 2002 08:23:01 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gBBGMxgV1307814; Wed, 11 Dec 2002 17:22:59 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1000) id D9CD610F29; Wed, 11 Dec 2002 17:22:58 +0100 (CET) Date: Wed, 11 Dec 2002 17:22:58 +0100 From: Stephane Bortzmeyer To: "JFC (Jefsey) Morfin" Cc: Stephane Bortzmeyer , IETF idn working group Subject: Re: [idn] Newbie's questions implementing the [IDNA] Message-ID: <20021211162258.GA16447@nic.fr> References: <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> <5.1.0.14.0.20021211162651.02793240@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021211162651.02793240@mail.jefsey.com> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, Dec 11, 2002 at 04:50:00PM +0100, JFC (Jefsey) Morfin wrote a message of 46 lines which said: > My program tells: > u+0063 u+006F u+0B69 u+0B69 u+0063 u+0061 . fr > are we in agreement? Yes. That's the good thing with standards :-) But I used the official Unicode names to make easier to see there are no semantics in the Unicode string. > about u+A317.com? Even then it will print in most of the cases as > iesg-ibm.com. It's u+3A17 and it does not seem registered at this time (although I agree that such unfortunate collisions are possible, I simply believe they are very uncommon). From owner-idn@ops.ietf.org Wed Dec 11 14:41:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18030 for ; Wed, 11 Dec 2002 14:41:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MCbN-0000XF-00 for idn-data@psg.com; Wed, 11 Dec 2002 11:33:01 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 18MCbJ-0000Wt-00 for idn@ops.ietf.org; Wed, 11 Dec 2002 11:32:57 -0800 Received: from lns10m-8-56.w.club-internet.fr ([213.44.191.56] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18MCbD-00067m-00; Wed, 11 Dec 2002 11:32:52 -0800 Message-Id: <5.1.0.14.0.20021211203511.04498570@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Dec 2002 20:36:02 +0100 To: Stephane Bortzmeyer From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Newbie's questions implementing the [IDNA] Cc: IETF idn working group In-Reply-To: <20021211162258.GA16447@nic.fr> References: <5.1.0.14.0.20021211162651.02793240@mail.jefsey.com> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <20021210002946.GD32412@nicemice.net> <3DF3F626.4060709@netpia.com> <20021209024449.GA31524@postel.co.kr> <20021209231828.GA32412@nicemice.net> <20021210000347.GR31524@postel.co.kr> <20021210002946.GD32412@nicemice.net> <5.1.0.14.0.20021210125313.02c89ec0@mail.jefsey.com> <5.1.0.14.0.20021211045151.029e8560@mail.jefsey.com> <5.1.0.14.0.20021211162651.02793240@mail.jefsey.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-4ECA1935; boundary="=======480EE31=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======480EE31======= Content-Type: text/plain; x-avg-checked=avg-ok-4ECA1935; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit My question expected just a simple response: - either yes, the proposed draft permits to defeat TMs rights on a great scale in using what you call "unfortunate collisions" and others call "babel names". - or no, it does not (and may be why). jfc At 17:22 11/12/02, Stephane Bortzmeyer wrote: >On Wed, Dec 11, 2002 at 04:50:00PM +0100, > JFC (Jefsey) Morfin wrote > a message of 46 lines which said: > > > My program tells: > > u+0063 u+006F u+0B69 u+0B69 u+0063 u+0061 . fr > > are we in agreement? > >Yes. That's the good thing with standards :-) But I used the official >Unicode names to make easier to see there are no semantics in the >Unicode string. > > > about u+A317.com? Even then it will print in most of the cases as > > iesg-ibm.com. > >It's u+3A17 and it does not seem registered at this time (although I >agree that such unfortunate collisions are possible, I simply believe >they are very uncommon). > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/02 --=======480EE31=======-- From owner-idn@ops.ietf.org Mon Dec 23 08:08:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28956 for ; Mon, 23 Dec 2002 08:08:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QS9y-000LKs-00 for idn-data@psg.com; Mon, 23 Dec 2002 04:58:18 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18QS9l-000LK0-00; Mon, 23 Dec 2002 04:58:06 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27469; Mon, 23 Dec 2002 07:54:51 -0500 (EST) Message-Id: <200212231254.HAA27469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: idn@ops.ietf.org, ietf-provreg@cafax.se, intloc-discuss@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-jseng-idn-admin-02.txt,.pdf Date: Mon, 23 Dec 2002 07:54:49 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean Author(s) : J. Seng et al. Filename : draft-jseng-idn-admin-02.txt,.pdf Pages : 20 Date : 2002-12-20 Achieving internationalized access to domain names raises many complex issues. These include are not only associated with basic protocol design (i.e., how the names are represented on the network, compared, and converted to appropriate forms) but also issues and options for deployment, transition, registration and administration. The IETF IDN working group focused on the development of a standards track specification for access to domain names in a broader range of scripts than the original ASCII. It became clear during its efforts that there was great potential for confusion, and difficulties in deployment and transition, due to characters with similar appearances or interpretations and that those issues could best be addressed administratively, rather than through restrictions embedded in the protocols. This document provides guidelines for zone administrators (including but not limited to registry operators and registrars), and information for all domain names holders, on the administration of those domain names which contain characters drawn from Chinese, Japanese and Korean scripts (CJK). Other language groups are encouraged to develop their own guidelines as needed, based on these guideline if that is helpful. Comments on this document can be sent to the authors at idn-admin@jdna.jp. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jseng-idn-admin-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jseng-idn-admin-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20125921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jseng-idn-admin-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-jseng-idn-admin-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20125921.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Dec 23 08:32:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00984 for ; Mon, 23 Dec 2002 08:32:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QSdA-0000NQ-00 for idn-data@psg.com; Mon, 23 Dec 2002 05:28:28 -0800 Received: from [211.45.79.102] (helo=jupiter.jmi.co.kr) by psg.com with smtp (Exim 3.36 #2) id 18QSd7-0000Me-00 for idn@ops.ietf.org; Mon, 23 Dec 2002 05:28:25 -0800 Received: (qmail 13308 invoked by uid 525); 23 Dec 2002 22:29:25 +0900 Received: (qmail 13191 invoked from network); 23 Dec 2002 22:28:45 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 23 Dec 2002 22:28:45 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id WAA29287 for ; Mon, 23 Dec 2002 22:30:12 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QSEg-0003kC-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 08:03:10 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QSBW-0003eS-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 07:59:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27469; Mon, 23 Dec 2002 07:54:51 -0500 (EST) Message-Id: <200212231254.HAA27469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com CC: idn@ops.ietf.org, ietf-provreg@cafax.se, intloc-discuss@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-jseng-idn-admin-02.txt,.pdf Date: Mon, 23 Dec 2002 07:54:49 -0500 X-Spam-Status: No, hits=4.0 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: **** Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean Author(s) : J. Seng et al. Filename : draft-jseng-idn-admin-02.txt,.pdf Pages : 20 Date : 2002-12-20 Achieving internationalized access to domain names raises many complex issues. These include are not only associated with basic protocol design (i.e., how the names are represented on the network, compared, and converted to appropriate forms) but also issues and options for deployment, transition, registration and administration. The IETF IDN working group focused on the development of a standards track specification for access to domain names in a broader range of scripts than the original ASCII. It became clear during its efforts that there was great potential for confusion, and difficulties in deployment and transition, due to characters with similar appearances or interpretations and that those issues could best be addressed administratively, rather than through restrictions embedded in the protocols. This document provides guidelines for zone administrators (including but not limited to registry operators and registrars), and information for all domain names holders, on the administration of those domain names which contain characters drawn from Chinese, Japanese and Korean scripts (CJK). Other language groups are encouraged to develop their own guidelines as needed, based on these guideline if that is helpful. Comments on this document can be sent to the authors at idn-admin@jdna.jp. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jseng-idn-admin-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jseng-idn-admin-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20125921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jseng-idn-admin-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-jseng-idn-admin-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20125921.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Dec 24 08:42:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07319 for ; Tue, 24 Dec 2002 08:42:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qp8W-000JSm-00 for idn-data@psg.com; Tue, 24 Dec 2002 05:30:20 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 18Qp8R-000JQM-00 for idn@ops.ietf.org; Tue, 24 Dec 2002 05:30:16 -0800 Received: (qmail 29610 invoked from network); 24 Dec 2002 13:25:54 -0000 Received: from unknown (HELO JSENGTOSHIBA) (202.63.154.39) by sentosa.post1.com with SMTP; 24 Dec 2002 13:25:54 -0000 Message-ID: <02d501c2ab50$80ab2b70$779a3fca@JSENGTOSHIBA> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] Farewell my friends ... Date: Tue, 24 Dec 2002 21:22: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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.6 required=5.0 tests=SPAM_PHRASE_08_13,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After three years, IDN working group is finally reaching its end. It is a honor for me to co-chair this group, although I admit this is no easy task. I would like to thanks everyone for your contributions and participations. To friends, thank you for all your support. To adveraries, thank you, for we have benefit from your views too. There is no right or wrong...there is only rough consensus. There are also many people who have encouraged me over these years. While I wont name each individually here, you have my deepest gratitude for all the help and advises you given me and making me a better person. Thank you. Personally, this is a very special new year for me -- closing down this group conclude one phase of my life; I will be starting the next phase with my newly wedded wife and also a new job with the Singapore government looking at Internet technologies. So, while I say farewell, I am sure we will have other opportunities to see each another again in future. Lastly, merry christmas and have a happy new year. Thank you. -James Seng