From owner-idn@ops.ietf.org Tue Oct 8 07:39:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07195 for ; Tue, 8 Oct 2002 07:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ysLZ-000EKd-00 for idn-data@psg.com; Tue, 08 Oct 2002 04:16:17 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17ysLX-000EKR-00 for idn@ops.ietf.org; Tue, 08 Oct 2002 04:16:15 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06242; Tue, 8 Oct 2002 07:14:09 -0400 (EDT) Message-Id: <200210081114.HAA06242@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-idna-13.txt Date: Tue, 08 Oct 2002 07:14:09 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 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. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Domain Names In Applications (IDNA) Author(s) : P. Faltstrom, P. Hoffman, A. Costello Filename : draft-ietf-idn-idna-13.txt Pages : 0 Date : 2002-10-7 Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called IDNA for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-idna-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-idna-13.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-10-7141245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-7141245.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Oct 8 10:12:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14369 for ; Tue, 8 Oct 2002 10:12:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17yut2-000HbX-00 for idn-data@psg.com; Tue, 08 Oct 2002 06:59:00 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17yusy-000HbK-00 for idn@ops.ietf.org; Tue, 08 Oct 2002 06:58:56 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id g98DwqFt020636 for ; Tue, 8 Oct 2002 15:58:52 +0200 To: idn@ops.ietf.org Subject: [idn] BOM in draft-hoffman-stringprep-07 X-Hashcash: 0:021008:idn@ops.ietf.org:fb0f08e174619a43 From: Simon Josefsson Date: Tue, 08 Oct 2002 15:58:51 +0200 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,SUBJ_HAS_UNIQ_ID,USER_AGENT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk (If there is a more appropriate mailing list for stringprep, let me know.) I see that draft-hoffman-stringprep-07 maps U+FEFF (ZWNBSP/BOM) to nothing (older versions did too) and also prohibits the character in the output. Why? U+FEFF used as a byte order mark have its uses in some Unicode transformation formats (UTF-16 and UTF-32), and I don't see stringprep requiring the use of UTF-8, where I would agree that it makes sense to prohibit it. My interpretation is that any protocol that uses UTF-16 and UTF-32 in byte order independent mode will thus have to modify the stringprep tables, to have BOM signatures work, before they can use stringprep. Only UTF-8 and byte order tagged UTF-16 and UTF-32 can use stringprep tables as is. Is this a correct interpretation? In that case, the text in section 5 should make it more clear that it is allowed to use partial tables (right now it says all or some of the tables may be used), and also note that byte order independent UTF-16 and UTF-32 applications need to remove U+FEFF from the tables. An alternate solution would be to only define stringprep for UTF-8. Thanks. From owner-idn@ops.ietf.org Tue Oct 8 12:22:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20439 for ; Tue, 8 Oct 2002 12:22:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ywyn-000Knn-00 for idn-data@psg.com; Tue, 08 Oct 2002 09:13:05 -0700 Received: from pheidippides.md.chalmers.se ([129.16.237.91]) by psg.com with esmtp (Exim 3.36 #1) id 17ywyi-000Kna-00 for idn@ops.ietf.org; Tue, 08 Oct 2002 09:13:01 -0700 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 g98GCoE07415; Tue, 8 Oct 2002 18:12:50 +0200 (MET DST) From: "Kent Karlsson" To: "'Simon Josefsson'" , Subject: RE: [idn] BOM in draft-hoffman-stringprep-07 Date: Tue, 8 Oct 2002 18:08:11 +0200 Message-ID: <000701c26ee4$e75d5e90$d5d61081@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-5.2 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,SUBJ_HAS_UNIQ_ID,USER_AGENT_OUTLOOK version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The double use of U+FEFF as BOM and ZWNBSP has been disunified. U+FEFF is now (from Unicode 3.2) used only as BOM, though it retains the name ZWNBSP (spelled out in full, of course...). The function of "true" ZWNBSP has been taken over by 2060;WORD JOINER. A BOM is not part of any text, just some byte serialisation of that text, and stringprep can be applied to some text, but not to the (byte) serialisation of the text, that is a lower level, regardless of whether UTF-8, UTF-16, UTF-32 or something else is used as processing code. After stringprep, the text can again be serialised, so (byte oriented) protocols can use BOM with (byte serialised) UTF-16 or UTF-32 (or even UTF-8) if desired. (Though I would prefer fixating the byte order, rather than ever use BOM where possible.) So as long as it is ok to remove WORD JOINER (which is what non-BOM uses of U+FEFF should be turned into), ZWNBSP should be removed to. /Kent Karlsson > -----Original Message----- > From: owner-idn@ops.ietf.org > [mailto:owner-idn@ops.ietf.org]On Behalf Of > Simon Josefsson > Sent: den 8 oktober 2002 15:59 > To: idn@ops.ietf.org > Subject: [idn] BOM in draft-hoffman-stringprep-07 > > > (If there is a more appropriate mailing list for stringprep, > let me know.) > > I see that draft-hoffman-stringprep-07 maps U+FEFF (ZWNBSP/BOM) to > nothing (older versions did too) and also prohibits the character in > the output. Why? > > U+FEFF used as a byte order mark have its uses in some Unicode > transformation formats (UTF-16 and UTF-32), and I don't see stringprep > requiring the use of UTF-8, where I would agree that it makes sense to > prohibit it. > > My interpretation is that any protocol that uses UTF-16 and UTF-32 in > byte order independent mode will thus have to modify the stringprep > tables, to have BOM signatures work, before they can use stringprep. > Only UTF-8 and byte order tagged UTF-16 and UTF-32 can use stringprep > tables as is. Is this a correct interpretation? In that case, the > text in section 5 should make it more clear that it is allowed to use > partial tables (right now it says all or some of the tables may be > used), and also note that byte order independent UTF-16 and UTF-32 > applications need to remove U+FEFF from the tables. An alternate > solution would be to only define stringprep for UTF-8. > > Thanks. > > From owner-idn@ops.ietf.org Thu Oct 10 07:29:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28877 for ; Thu, 10 Oct 2002 07:29:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zbMN-000IBV-00 for idn-data@psg.com; Thu, 10 Oct 2002 04:20:07 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 17zbML-000IBJ-00 for idn@ops.ietf.org; Thu, 10 Oct 2002 04:20:05 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28451; Thu, 10 Oct 2002 07:17:58 -0400 (EDT) Message-Id: <200210101117.HAA28451@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-punycode-03.txt Date: Thu, 10 Oct 2002 07:17:58 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 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. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Punycode:A Bootstring encoding of Unicode for IDNA Author(s) : A. Costello Filename : draft-ietf-idn-punycode-03.txt Pages : 26 Date : 2002-10-9 Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications [IDNA]. It uniquely and reversibly transforms a Unicode string [UNICODE] into an ASCII string [ASCII]. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-punycode-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-punycode-03.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-10-9145042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-punycode-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-punycode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-9145042.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sun Oct 13 03:21:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15891 for ; Sun, 13 Oct 2002 03:21:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180cfq-0004yB-00 for idn-data@psg.com; Sat, 12 Oct 2002 23:56:26 -0700 Received: from [218.154.6.96] (helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #2) id 180cfn-0004xz-00 for idn@ops.ietf.org; Sat, 12 Oct 2002 23:56:24 -0700 Received: from backup.lsb.org (backup.lsb.org [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id g9D6v1Wa022876; Sun, 13 Oct 2002 15:57:02 +0900 Received: (from root@localhost) by backup.lsb.org (8.12.5/8.12.5/Submit) id g9D6uufM022874; Sun, 13 Oct 2002 15:56:56 +0900 Date: Sun, 13 Oct 2002 15:56:56 +0900 From: Soobok Lee To: idn@ops.ietf.org Subject: [idn] length restrictions on IDN label Message-ID: <20021013065656.GA22861@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk [ When i read IDNA draft today, I still can't find the answer from it for the following question about IDN label length. If the following issue is already addressed in the draft, please correct me. ] I have a punycode label of length 63 octets: L1: zq--o39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA L2=ToUnicode(L1) produces: U+AC00 x 56 times ( Hangul "KA" repeated 56 times) L2: U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 U+AC00 But this L2 can be encoded in various unicode/legacy encodings into various lengths of octets: UTF8 : 3 x 56 = 168 octets UCS2 : 2 x 56 = 112 octets UCS4 : 4 x 56 = 224 octets KSX1001/EUC-KR : 2 x 56 = 112 octets These encodings produce labels longer than 63 octets Moreover, each ACE label of valid (<256 octets) ACE-form FQDN IDN may be converted into below-63-octets valid UTF8 labels, while the cumulative sum of the length of each UTF8 label of the FQDN IDN may exceed 256 octets limits. Many internet applications impose/assumes the 63-octets-limit of label lengths. IF this assumption is violated, the label will be regarded as invalid labels, and produce unpredictable errors by some implementations. From implementators' point of view, more precise specificiation is needed about whether IDN label/FQDN has *NEW* length restrictions in various char encodings, if IDNA tries to extend the character repertoires of allowable characters. The above case is very rare, but in any cases, the implementors have practical security-related need to impose some limits on the iDN lables in non-ACE encodings. (for example, to avoid buffer overflow errors due to expanded ToUnicode labels) Cheers, Soobok Lee From owner-idn@ops.ietf.org Sun Oct 13 05:24:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16800 for ; Sun, 13 Oct 2002 05:24:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180ep7-0007PM-00 for idn-data@psg.com; Sun, 13 Oct 2002 02:14:09 -0700 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 180ep2-0007PA-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 02:14:05 -0700 Received: from lns13v-12-8.w.club-internet.fr ([212.195.183.8] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 180eoy-0007P2-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 02:14:02 -0700 Message-Id: <5.1.0.14.0.20021013111229.03a53a90@pop.online.fr> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 13 Oct 2002 11:18:53 +0200 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: [idn] ITU position. Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-50FC79AE; boundary="=======3B83777F=======" 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.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======3B83777F======= Content-Type: text/plain; x-avg-checked=avg-ok-50FC79AE; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit This will probably lead to the major controversy I tried to avoid in coming in here. Are you sure you do not want to discuss babelization before we must fight it? jfc cf. http://www.itu.int/newsroom/pp02/Highlights/1010.html ITU stakes claim on Internet names The Working Group of the Plenary approved a resolution on the management of internationalized multilingual domain names. This resolution aims at promoting the role of Member States in the internationalization of domain names and addresses of their respective languages. This will be increasingly important in the coming years as a majority of Internet users is expected to prefer to conduct online activities in their own language. It is also important because the current Domain Names System (DNS) mapping does not reflect the growing language needs of all. The resolution stresses that the registration and allocation of Internet domain names and addresses should reflect the geographical and functional nature of the Internet with an equitable balance of interests of all stakeholders. It also emphasizes that the non-discriminatory access to Internet domain names and addresses, and more generally to the Internet, should be available to all citizens and that the management of Internet Domain Names and addresses is of concern to both governments and the private sector. It also reiterates the need to fully maintain country code numbering plans and addresses as in ITU-T recommendation E.164 which defines the international public telecommunication numbering plan. Under this resolution, ITU will be providing assistance to its Member States to promote the use of their languages for domain names and addresses and will cooperate with the World Intellectual Property Organization whose role includes protection against misuse of intellectual property rights in the use of countries' languages for domain names and addresses. --=======3B83777F=======-- From owner-idn@ops.ietf.org Sun Oct 13 11:44:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20955 for ; Sun, 13 Oct 2002 11:44:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180kho-000ENs-00 for idn-data@psg.com; Sun, 13 Oct 2002 08:31:00 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180khn-000EN2-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 08:30:59 -0700 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id g9DFUYc11672; Mon, 14 Oct 2002 00:30:34 +0900 Date: Mon, 14 Oct 2002 00:30:34 +0900 From: Soobok Lee To: idn@ops.ietf.org Subject: [idn] another question about IDN label length Message-ID: <20021013153034.GA11130@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk L1 is a utf8-encoded IDN label. L2=nameprep(L1), L2 is still in utf8. A1=ToASCII(L2) Function length(X) returns the octet length of the string X in unknown encoding and charset. My question in previous questions was: in the case of length(A1)<=63 and length(L2)>63, is L2 a valid iDN label conforming to DNS label length restrictions ? My second question is: if length(L2) <= 63 < length(L1), is L1 is valid iDN label ? if length(L1) <= 63 < length(L2), is L2 is valid iDN label ? I can repeat similar questions by changing utf8 to other charset encodings, which will further complicate the problem. Some applications may exchange non-ASCII-form IDN instead of ACE-form IDN after negotiations. Non-ASCII-form IDN may be used and stored and transfered and processed as its equivalent ACE version by the new application protocols. If some of above labels should be declared as invalid, there may be needed more complex definitions of what labels are invalid and therefore related protocol actions and exception handlings of such too-long IDN labels. This problem has security implications from the implementors' viewpoints. If IDNA draft already contains any clues about iDN label length restrictions, suggest me the section please, so that i remain comfortable with this issue. Regards, Soobok Lee From owner-idn@ops.ietf.org Sun Oct 13 12:46:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21872 for ; Sun, 13 Oct 2002 12:46:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180lmR-000Flf-00 for idn-data@psg.com; Sun, 13 Oct 2002 09:39:51 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 180lmP-000FlT-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 09:39:49 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9DGdhv06287; Sun, 13 Oct 2002 09:39:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20021013065656.GA22861@postel.co.kr> References: <20021013065656.GA22861@postel.co.kr> 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: Sun, 13 Oct 2002 09:39:42 -0700 To: Soobok Lee , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] length restrictions on IDN label Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-12.9 required=5.0 tests=HABEAS_SWE,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:56 PM +0900 10/13/02, Soobok Lee wrote: >[ When i read IDNA draft today, I still can't find > the answer from it for the following question about IDN label length. > If the following issue is already addressed in the draft, please >correct me. ] It is indeed covered in the draft. The input to IDNA is code points, not encoded characters. As you point out, different encodings give different lengths for the same string. The only lengths that matter are those that are already in STD 13. > Many internet applications impose/assumes the 63-octets-limit of >label lengths. > IF this assumption is violated, the label will be regarded as invalid > labels, and produce unpredictable errors by some implementations. Which Internet applications are you speaking of? Which encodings are they using? As you pointed out, different encodings give different lengths. Thus, no sensible application could assume a 63-octet length if it deals with different encodings. > From implementators' point of view, more precise specificiation is needed > about whether IDN label/FQDN has *NEW* length restrictions in >various char encodings, > if IDNA tries to extend the character repertoires of allowable characters. It seems likely that most implementers can understand that they must continue to follow the same rules that they always have for the length of domain names and labels. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Oct 13 22:07:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27954 for ; Sun, 13 Oct 2002 22:07:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180uS0-0000Pz-00 for idn-data@psg.com; Sun, 13 Oct 2002 18:55:20 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180uRy-0000Pm-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 18:55:18 -0700 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id g9E1sWH20816; Mon, 14 Oct 2002 10:54:32 +0900 Date: Mon, 14 Oct 2002 10:54:32 +0900 From: Soobok Lee To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021014015432.GA20396@postel.co.kr> References: <20021013065656.GA22861@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-10.8 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk On Sun, Oct 13, 2002 at 09:39:42AM -0700, Paul Hoffman / IMC wrote: > At 3:56 PM +0900 10/13/02, Soobok Lee wrote: > >[ When i read IDNA draft today, I still can't find > > the answer from it for the following question about IDN label length. > > If the following issue is already addressed in the draft, please > >correct me. ] > > It is indeed covered in the draft. The input to IDNA is code points, > not encoded characters. As you point out, different encodings give > different lengths for the same string. The only lengths that matter > are those that are already in STD 13. > > > Many internet applications impose/assumes the 63-octets-limit of > >label lengths. > > IF this assumption is violated, the label will be regarded as invalid > > labels, and produce unpredictable errors by some implementations. > > Which Internet applications are you speaking of? Which encodings are > they using? As you pointed out, different encodings give different > lengths. Thus, no sensible application could assume a 63-octet length > if it deals with different encodings. UTF8,EUC-KR etc are all ASCII compatible encoding/charset. Applications don't need to give up/modify old 63-octets restrictions for LDH labels even in utf8 or euc-kr, because those encodings produce the same octets string as pure ASCII encoding does. That is, in those ASCII compatible encoding of LDH chars, the number of codepoints and the number of octets are equal, while they are not equal in encoding of non-LDH chars like Hangul, CJK letters (the octet length is doubled or tripled). > > > From implementators' point of view, more precise specificiation is needed > > about whether IDN label/FQDN has *NEW* length restrictions in > >various char encodings, > > if IDNA tries to extend the character repertoires of allowable characters. > > It seems likely that most implementers can understand that they must > continue to follow the same rules that they always have for the > length of domain names and labels. The unit of length restriction matters: # of code points or # of octets ? That should be made clearer. RFC1035 uses "octets", not a character/code point. I enclose related RFC1035 (STD13) sections here. Mockapetris [Page 9] RFC 1035 Domain Implementation and Specification November 1987 (snip) 2.3.4. Size limits Various objects and parameters in the DNS have size limits. They are listed below. Some could be easily changed, others are more fundamental. labels 63 octets or less names 255 octets or less TTL positive values of a signed 32 bit number. UDP messages 512 octets or less 3. DOMAIN NAME SPACE AND RR DEFINITIONS 3.1. Name space definitions Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less. Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII [Soobok Lee] From owner-idn@ops.ietf.org Sun Oct 13 22:28:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28145 for ; Sun, 13 Oct 2002 22:28:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180umE-0000pG-00 for idn-data@psg.com; Sun, 13 Oct 2002 19:16:14 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 180umB-0000p4-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 19:16:12 -0700 Received: from [165.227.249.18] (165-227-249-21.client.dsl.net [165.227.249.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9E2G4v02856; Sun, 13 Oct 2002 19:16:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20021014015432.GA20396@postel.co.kr> References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> 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: Sun, 13 Oct 2002 19:16:02 -0700 To: Soobok Lee From: Paul Hoffman / IMC Subject: Re: [idn] length restrictions on IDN label Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-13.5 required=5.0 tests=HABEAS_SWE,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:54 AM +0900 10/14/02, Soobok Lee wrote: >On Sun, Oct 13, 2002 at 09:39:42AM -0700, Paul Hoffman / IMC wrote: > > It seems likely that most implementers can understand that they must >> continue to follow the same rules that they always have for the > > length of domain names and labels. > >The unit of length restriction matters: # of code points or # of octets ? >That should be made clearer. RFC1035 uses "octets", not a >character/code point. Exactly right. It seems like you have answered your own question! In case I'm missing something, where in any of the IDN documents does it indicate that the length restrictions are in number of code points instead of number of octets? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Oct 13 22:48:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28673 for ; Sun, 13 Oct 2002 22:48:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180vBT-0001Or-00 for idn-data@psg.com; Sun, 13 Oct 2002 19:42:19 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180vBP-0001Od-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 19:42:15 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E2fjb21526; Mon, 14 Oct 2002 11:41:45 +0900 Message-ID: <3DAA2F3C.8080109@postel.co.kr> Date: Mon, 14 Oct 2002 11:43:08 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Paul Hoffman / IMC CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Then, U+AC00 x 56 times (in my previous posting) is a valid label conforming to RFC1035 ? and its equivalent ACE label (of 63 octets ) is a valid label ? UTF8-encoded IDN labels are not governed by RFC1035 length restrictions ? IDNA contains brand new length restrictions for 8bit labels which obsoletes RFC1035 ? Soobok Lee Paul Hoffman / IMC wrote: > At 10:54 AM +0900 10/14/02, Soobok Lee wrote: > >> On Sun, Oct 13, 2002 at 09:39:42AM -0700, Paul Hoffman / IMC wrote: >> > It seems likely that most implementers can understand that they must >> >>> continue to follow the same rules that they always have for the >> >> > length of domain names and labels. >> >> The unit of length restriction matters: # of code points or # of >> octets ? >> That should be made clearer. RFC1035 uses "octets", not a >> character/code point. > > > Exactly right. It seems like you have answered your own question! > > In case I'm missing something, where in any of the IDN documents does > it indicate that the length restrictions are in number of code points > instead of number of octets? > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Oct 13 23:07:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28820 for ; Sun, 13 Oct 2002 23:07:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180vHO-0001YG-00 for idn-data@psg.com; Sun, 13 Oct 2002 19:48:26 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 180vHN-0001Y3-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 19:48:25 -0700 Received: from [165.227.249.18] (165-227-249-21.client.dsl.net [165.227.249.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9E2mIv03563; Sun, 13 Oct 2002 19:48:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3DAA2F3C.8080109@postel.co.kr> References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> 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: Sun, 13 Oct 2002 19:47:51 -0700 To: Soobok Lee From: Paul Hoffman / IMC Subject: Re: [idn] length restrictions on IDN label Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-13.5 required=5.0 tests=HABEAS_SWE,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:43 AM +0900 10/14/02, Soobok Lee wrote: >Then, > U+AC00 x 56 times (in my previous posting) is a valid label >conforming to RFC1035 ? > and its equivalent ACE label (of 63 octets ) is a valid label ? If it follows the rules for ToASCII, yes. > UTF8-encoded IDN labels are not governed by RFC1035 length restrictions ? There is no such thing. IDN labels are always encoded in ASCII following the rules of STD 13, just as it says in the draft. > IDNA contains brand new length restrictions for 8bit labels >which obsoletes RFC1035 ? No. Where in the draft do you see such "brand new length restrictions"? The current goal of the WG is to fix any unclear statements in the document. We can't do that if you don't say exactly what text you find unclear. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Oct 13 23:11:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28983 for ; Sun, 13 Oct 2002 23:11:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180vXH-0001vU-00 for idn-data@psg.com; Sun, 13 Oct 2002 20:04:51 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180vXF-0001vI-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 20:04:49 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E34Jb21895; Mon, 14 Oct 2002 12:04:19 +0900 Message-ID: <3DAA3486.1050003@postel.co.kr> Date: Mon, 14 Oct 2002 12:05:42 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Paul Hoffman / IMC CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > At 11:43 AM +0900 10/14/02, Soobok Lee wrote: > > >> UTF8-encoded IDN labels are not governed by RFC1035 length >> restrictions ? > > > There is no such thing. IDN labels are always encoded in ASCII > following the rules of STD 13, just as it says in the draft. > That is true only in protocols predating IDNA draft. IDN labels can be typed in/ displayed/ copy&pasted/ or exchanged in UTF8 (or other) encoding in now and future applications or protocols slots as described in IDNA draft itself. See enclosed excerpts from IDNA draft ( "SEE HERE"). I think some length restriction in code points is needed, rather than in octets .... IDNA is the right place to put such things.. Soobok Lee 6.3 DNS servers Domain names stored in zones follow the rules for "stored strings" from [STRINGPREP]. For internationalized labels that cannot be represented directly in ASCII, DNS servers MUST use the ACE form produced by the ToASCII operation. All IDNs served by DNS servers MUST contain only ASCII characters. If a signaling system which makes negotiation possible between old and new DNS clients and servers is standardized in the future, the encoding of the query in the DNS protocol itself can be changed from ACE to something else, such as UTF-8. The question whether or not this should (SEE HERE) be used is, however, a separate problem and is not discussed in this memo. 6.1 Entry and display in applications (snip) In protocols and document formats that define how to handle specification or negotiation of charsets, labels can be encoded in any charset allowed by the protocol or document format. If a protocol or document format only allows one charset, the labels MUST be given in that charset. In any place where a protocol or document format allows transmission of the characters in internationalized labels, internationalized labels SHOULD be transmitted using whatever character encoding and escape ( SEE HERE ) mechanism that the protocol or document format uses at that place. All protocols that use domain name slots already have the capacity for handling domain names in the ASCII charset. Thus, ACE labels (internationalized labels that have been processed with the ToASCII operation) can inherently be handled by those protocols. 6. Implications for typical applications using DNS In IDNA, applications perform the processing needed to input internationalized domain names from users, display internationalized domain names to users, and process the inputs and outputs from DNS and other protocols that carry domain names. The components and interfaces between them can be represented pictorially as: +------+ | User | +------+ ^ | Input and display: local interface methods | (pen, keyboard, glowing phosphorus, ...) +-------------------|-------------------------------+ | v | | +-----------------------------+ | | | Application | | | | (ToASCII and ToUnicode | | | | operations may be | | | | called here) | | | +-----------------------------+ | | ^ ^ | End system | | | | | Call to resolver: | | Application-specific | | ACE | | protocol: | | v | ACE unless the | | +----------+ | protocol is updated | | | Resolver | | to handle other | | +----------+ | encodings | (SEE HERE) | ^ | | +-----------------|----------|----------------------+ DNS protocol: | | ACE | | v v +-------------+ +---------------------+ | DNS servers | | Application servers | +-------------+ +---------------------+ From owner-idn@ops.ietf.org Sun Oct 13 23:53:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29562 for ; Sun, 13 Oct 2002 23:53:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180wDW-0002yD-00 for idn-data@psg.com; Sun, 13 Oct 2002 20:48:30 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 180wDU-0002x7-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 20:48:28 -0700 Received: (qmail 7252 invoked from network); 14 Oct 2002 03:50:01 -0000 Received: from bb-203-125-82-30.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.82.30) by sentosa.post1.com with SMTP; 14 Oct 2002 03:50:01 -0000 Message-ID: <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "Soobok Lee" , "Paul Hoffman / IMC" Cc: References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> Subject: Re: [idn] length restrictions on IDN label Date: Mon, 14 Oct 2002 11:45:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.7 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is already restriction in the number of codepoint or octets in UTF-8 (or other) encoding. The restriction is defined currently as octet(ToASCII(X)) < 63. -James Seng > That is true only in protocols predating IDNA draft. > IDN labels can be typed in/ displayed/ copy&pasted/ or exchanged in > UTF8 (or other) encoding > in now and future applications or protocols slots as described in IDNA > draft itself. > See enclosed excerpts from IDNA draft ( "SEE HERE"). > > I think some length restriction in code points is needed, rather than in > octets .... > IDNA is the right place to put such things.. > > Soobok Lee > > 6.3 DNS servers > > Domain names stored in zones follow the rules for "stored strings" from > [STRINGPREP]. > > For internationalized labels that cannot be represented directly in > ASCII, DNS servers MUST use the ACE form produced by the ToASCII > operation. All IDNs served by DNS servers MUST contain only ASCII > characters. > > If a signaling system which makes negotiation possible between old and > new DNS clients and servers is standardized in the future, the encoding > of the query in the DNS protocol itself can be changed from ACE to > something else, such as UTF-8. The question whether or not this should (SEE HERE) > be used is, however, a separate problem and is not discussed in this > memo. > > > > 6.1 Entry and display in applications > > (snip) > > In protocols and document formats that define how to handle > specification or negotiation of charsets, labels can be encoded in any > charset allowed by the protocol or document format. If a protocol or > document format only allows one charset, the labels MUST be given in > that charset. > > In any place where a protocol or document format allows transmission of > the characters in internationalized labels, internationalized labels > SHOULD be transmitted using whatever character encoding and escape ( SEE HERE ) > mechanism that the protocol or document format uses at that place. > > All protocols that use domain name slots already have the capacity for > handling domain names in the ASCII charset. Thus, ACE labels > (internationalized labels that have been processed with the ToASCII > operation) can inherently be handled by those protocols. > > > 6. Implications for typical applications using DNS > > In IDNA, applications perform the processing needed to input > internationalized domain names from users, display internationalized > domain names to users, and process the inputs and outputs from DNS and > other protocols that carry domain names. > > The components and interfaces between them can be represented > pictorially as: > > +------+ > | User | > +------+ > ^ > | Input and display: local interface methods > | (pen, keyboard, glowing phosphorus, ...) > +-------------------|-------------------------------+ > | v | > | +-----------------------------+ | > | | Application | | > | | (ToASCII and ToUnicode | | > | | operations may be | | > | | called here) | | > | +-----------------------------+ | > | ^ ^ | End system > | | | | > | Call to resolver: | | Application-specific | > | ACE | | protocol: | > | v | ACE unless the | > | +----------+ | protocol is updated | > | | Resolver | | to handle other | > | +----------+ | encodings | (SEE HERE) > | ^ | | > +-----------------|----------|----------------------+ > DNS protocol: | | > ACE | | > v v > +-------------+ +---------------------+ > | DNS servers | | Application servers | > +-------------+ +---------------------+ > > > > > From owner-idn@ops.ietf.org Mon Oct 14 00:01:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29674 for ; Mon, 14 Oct 2002 00:01:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180wGw-0003AQ-00 for idn-data@psg.com; Sun, 13 Oct 2002 20:52:02 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 180wGu-0003A5-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 20:52:00 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 180wGt-0001jx-00 for ; Sun, 13 Oct 2002 20:51:59 -0700 Date: Mon, 14 Oct 2002 03:51:58 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021014035158.GB2930@nicemice.net> Reply-To: IETF idn working group References: <3DAA3486.1050003@postel.co.kr> <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <20021013065656.GA22861@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021013153034.GA11130@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <20021013065656.GA22861@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > I have a punycode label of length 63 octets: > L1: zq--o39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > > L2=ToUnicode(L1) produces: U+AC00 x 56 times ( Hangul "KA" repeated 56 times) > > But this L2 can be encoded in various unicode/legacy encodings into > various lengths of octets: > > UTF8 : 3 x 56 = 168 octets > UCS2 : 2 x 56 = 112 octets > UCS4 : 4 x 56 = 224 octets > KSX1001/EUC-KR : 2 x 56 = 112 octets > > Many internet applications impose/assumes the 63-octets-limit of > label lengths. IDN-unaware applications use this simple 63-octet limit. These applications also assume that the domain label is ASCII. IDN-aware applications will be careful to use the ASCII form when talking to IDN-unaware applications. Applications that use non-ASCII representations will know the more complex syntax rule for non-ASCII labels (namely, that the label is valid if and only if ToASCII can be applied to it without failing). > From implementators' point of view, more precise specificiation is > needed about whether IDN label/FQDN has *NEW* length restrictions in > various char encodings Section 2 defines "internationalized label" as a label to which the ToASCII operation can be applied without failing. There is no other restriction on IDN label syntax. > the implementors have practical security-related need to impose some > limits on the iDN lables in non-ACE encodings. (for example, to avoid > buffer overflow errors due to expanded ToUnicode labels) That's true. A cursory examination of the Punycode algorithm reveals that each ASCII character can represent at most one code point; therefore an internationalized label can represent at most 63 code points, whether it's ACE or not. A given encoding uses a bounded number of octets per code point, so you can allocate your buffers based on that. > The unit of length restriction matters: # of code points or # of > octets ? That should be made clearer. RFC1035 uses "octets", not a > character/code point. RFC 1035 limits domain labels to 63 octets, but RFC 1035 predates IDNA, and it speaks under the explicit assumption that text is ASCII. Because DNS is IDN-unaware, all internationalized labels in DNS are in their ASCII forms. For these reasons, the 63-octet limit applies only to the ASCII forms of internationalized labels. IDNA does not introduce any new length restrictions. The 63-octet limit on ASCII labels is the only length restriction on internationalized labels. > Then, U+AC00 x 56 times (in my previous posting) is a valid label > conforming to RFC1035 ? No, it's not, and that's why IDNA requires that it be converted to its ASCII form before being passed into an IDN-unaware protocol like DNS. > UTF8-encoded IDN labels are not governed by RFC1035 length > restrictions ? Not directly. The 63-octet limit applies to the ASCII form, not the UTF-8 form. It would be absurd to apply the 63-octet limit to every possible encoding form. You'd have to transcode a label into every possible encoding just to check whether it's valid. > IDNA contains brand new length restrictions for 8bit labels which > obsoletes RFC1035 ? No, it contains no new length restrictions. The RFC 1035 restriction on the ASCII form is still the only restriction on the length of internationalized labels. AMC From owner-idn@ops.ietf.org Mon Oct 14 00:23:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00045 for ; Mon, 14 Oct 2002 00:23:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180waB-0003hQ-00 for idn-data@psg.com; Sun, 13 Oct 2002 21:11:55 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180wa9-0003hD-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 21:11:53 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E4BBb22849; Mon, 14 Oct 2002 13:11:11 +0900 Message-ID: <3DAA4434.5050707@postel.co.kr> Date: Mon, 14 Oct 2002 13:12:36 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: James Seng CC: Paul Hoffman / IMC , idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: >There is already restriction in the number of codepoint or octets in UTF-8 >(or other) encoding. > >The restriction is defined currently as octet(ToASCII(X)) < 63. > I already mentioned this in my first posting. What I request is confirmation and clarification about that restriction. If UTF8-encoded, that valid 8bit label will exceed 63 octets limits (up to 168 octets or more) which is imposed by RFC1035 even upon non-ASCII 8bit labels . IDNA section 6.3 does not rule out that utf8 encoded labels may be used in DNS wire protocols in the future. And that will affect UDP based DNS protocols which suffers from lack of space in the UDP packet length limits (512). Packet truncation or protcol errors are inevitable. That is why i suggest that some separate length restriction on utf8 (other encoding) IDN labels be needed. Or clarifications about those problems, at least. Soobok Lee > >-James Seng > > > >>That is true only in protocols predating IDNA draft. >>IDN labels can be typed in/ displayed/ copy&pasted/ or exchanged in >> UTF8 (or other) encoding >>in now and future applications or protocols slots as described in IDNA >>draft itself. >>See enclosed excerpts from IDNA draft ( "SEE HERE"). >> >>I think some length restriction in code points is needed, rather than in >>octets .... >>IDNA is the right place to put such things.. >> >>Soobok Lee >> >>6.3 DNS servers >> >>Domain names stored in zones follow the rules for "stored strings" from >>[STRINGPREP]. >> >>For internationalized labels that cannot be represented directly in >>ASCII, DNS servers MUST use the ACE form produced by the ToASCII >>operation. All IDNs served by DNS servers MUST contain only ASCII >>characters. >> >>If a signaling system which makes negotiation possible between old and >>new DNS clients and servers is standardized in the future, the encoding >>of the query in the DNS protocol itself can be changed from ACE to >>something else, such as UTF-8. The question whether or not this should >> >> >(SEE HERE) > > >>be used is, however, a separate problem and is not discussed in this >>memo. >> >> >> >>6.1 Entry and display in applications >> >>(snip) >> >>In protocols and document formats that define how to handle >>specification or negotiation of charsets, labels can be encoded in any >>charset allowed by the protocol or document format. If a protocol or >>document format only allows one charset, the labels MUST be given in >>that charset. >> >>In any place where a protocol or document format allows transmission of >>the characters in internationalized labels, internationalized labels >>SHOULD be transmitted using whatever character encoding and escape ( SEE >> >> >HERE ) > > >>mechanism that the protocol or document format uses at that place. >> >>All protocols that use domain name slots already have the capacity for >>handling domain names in the ASCII charset. Thus, ACE labels >>(internationalized labels that have been processed with the ToASCII >>operation) can inherently be handled by those protocols. >> >> >>6. Implications for typical applications using DNS >> >>In IDNA, applications perform the processing needed to input >>internationalized domain names from users, display internationalized >>domain names to users, and process the inputs and outputs from DNS and >>other protocols that carry domain names. >> >>The components and interfaces between them can be represented >>pictorially as: >> >> +------+ >> | User | >> +------+ >> ^ >> | Input and display: local interface methods >> | (pen, keyboard, glowing phosphorus, ...) >> +-------------------|-------------------------------+ >> | v | >> | +-----------------------------+ | >> | | Application | | >> | | (ToASCII and ToUnicode | | >> | | operations may be | | >> | | called here) | | >> | +-----------------------------+ | >> | ^ ^ | End system >> | | | | >> | Call to resolver: | | Application-specific | >> | ACE | | protocol: | >> | v | ACE unless the | >> | +----------+ | protocol is updated | >> | | Resolver | | to handle other | >> | +----------+ | encodings | (SEE HERE) >> | ^ | | >> +-----------------|----------|----------------------+ >> DNS protocol: | | >> ACE | | >> v v >> +-------------+ +---------------------+ >> | DNS servers | | Application servers | >> +-------------+ +---------------------+ >> >> >> >> >> >> >> From owner-idn@ops.ietf.org Mon Oct 14 00:35:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00189 for ; Mon, 14 Oct 2002 00:35:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180wix-0003v6-00 for idn-data@psg.com; Sun, 13 Oct 2002 21:20:59 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 180wiv-0003uo-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 21:20:57 -0700 Received: (qmail 7767 invoked from network); 14 Oct 2002 04:22:31 -0000 Received: from bb-203-125-82-30.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.82.30) by sentosa.post1.com with SMTP; 14 Oct 2002 04:22:31 -0000 Message-ID: <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "Soobok Lee" Cc: "Paul Hoffman / IMC" , References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> Subject: Re: [idn] length restrictions on IDN label Date: Mon, 14 Oct 2002 12:18:00 +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=-4.7 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me repeat again, the restriction is octet(ToASCII(X)) <= 63 (sorry, forget the =). The length restriction of a domain name (incidently, UTF-8 encoded string which looks like domain name is not a domain name) in a DNS UDP packet is something beyond this working group. Please bring it to the DNSEXT working group. -James Seng > What I request is confirmation and clarification about that restriction. > > If UTF8-encoded, that valid 8bit label will exceed 63 octets limits (up > to 168 octets or more) > which is imposed by RFC1035 even upon non-ASCII 8bit labels . > IDNA section 6.3 does not rule out that utf8 encoded labels may be used > in DNS wire protocols in the future. And that will affect UDP based > DNS protocols > which suffers from lack of space in the UDP packet length limits (512). > Packet truncation or protcol errors are inevitable. > > That is why i suggest that some separate length restriction on utf8 > (other encoding) IDN labels > be needed. Or clarifications about those problems, at least. > > Soobok Lee > > > > >-James Seng > > > > > > > >>That is true only in protocols predating IDNA draft. > >>IDN labels can be typed in/ displayed/ copy&pasted/ or exchanged in > >> UTF8 (or other) encoding > >>in now and future applications or protocols slots as described in IDNA > >>draft itself. > >>See enclosed excerpts from IDNA draft ( "SEE HERE"). > >> > >>I think some length restriction in code points is needed, rather than in > >>octets .... > >>IDNA is the right place to put such things.. > >> > >>Soobok Lee > >> > >>6.3 DNS servers > >> > >>Domain names stored in zones follow the rules for "stored strings" from > >>[STRINGPREP]. > >> > >>For internationalized labels that cannot be represented directly in > >>ASCII, DNS servers MUST use the ACE form produced by the ToASCII > >>operation. All IDNs served by DNS servers MUST contain only ASCII > >>characters. > >> > >>If a signaling system which makes negotiation possible between old and > >>new DNS clients and servers is standardized in the future, the encoding > >>of the query in the DNS protocol itself can be changed from ACE to > >>something else, such as UTF-8. The question whether or not this should > >> > >> > >(SEE HERE) > > > > > >>be used is, however, a separate problem and is not discussed in this > >>memo. > >> > >> > >> > >>6.1 Entry and display in applications > >> > >>(snip) > >> > >>In protocols and document formats that define how to handle > >>specification or negotiation of charsets, labels can be encoded in any > >>charset allowed by the protocol or document format. If a protocol or > >>document format only allows one charset, the labels MUST be given in > >>that charset. > >> > >>In any place where a protocol or document format allows transmission of > >>the characters in internationalized labels, internationalized labels > >>SHOULD be transmitted using whatever character encoding and escape ( SEE > >> > >> > >HERE ) > > > > > >>mechanism that the protocol or document format uses at that place. > >> > >>All protocols that use domain name slots already have the capacity for > >>handling domain names in the ASCII charset. Thus, ACE labels > >>(internationalized labels that have been processed with the ToASCII > >>operation) can inherently be handled by those protocols. > >> > >> > >>6. Implications for typical applications using DNS > >> > >>In IDNA, applications perform the processing needed to input > >>internationalized domain names from users, display internationalized > >>domain names to users, and process the inputs and outputs from DNS and > >>other protocols that carry domain names. > >> > >>The components and interfaces between them can be represented > >>pictorially as: > >> > >> +------+ > >> | User | > >> +------+ > >> ^ > >> | Input and display: local interface methods > >> | (pen, keyboard, glowing phosphorus, ...) > >> +-------------------|-------------------------------+ > >> | v | > >> | +-----------------------------+ | > >> | | Application | | > >> | | (ToASCII and ToUnicode | | > >> | | operations may be | | > >> | | called here) | | > >> | +-----------------------------+ | > >> | ^ ^ | End system > >> | | | | > >> | Call to resolver: | | Application-specific | > >> | ACE | | protocol: | > >> | v | ACE unless the | > >> | +----------+ | protocol is updated | > >> | | Resolver | | to handle other | > >> | +----------+ | encodings | (SEE HERE) > >> | ^ | | > >> +-----------------|----------|----------------------+ > >> DNS protocol: | | > >> ACE | | > >> v v > >> +-------------+ +---------------------+ > >> | DNS servers | | Application servers | > >> +-------------+ +---------------------+ > >> > >> > >> > >> > >> > >> > >> > > > > From owner-idn@ops.ietf.org Mon Oct 14 00:53:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00349 for ; Mon, 14 Oct 2002 00:53:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180x98-0004dC-00 for idn-data@psg.com; Sun, 13 Oct 2002 21:48:02 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 180x95-0004d0-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 21:47:59 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 180x95-0001wk-00 for ; Sun, 13 Oct 2002 21:47:59 -0700 Date: Mon, 14 Oct 2002 04:47:58 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021014044758.GC2930@nicemice.net> Reply-To: IETF idn working group References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAA4434.5050707@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > If UTF8-encoded, that valid 8bit label will exceed 63 octets limits > (up to 168 octets or more) True. > which is imposed by RFC1035 even upon non-ASCII 8bit labels . Yes, but labels in DNS containing octets >= 128 are not internationalized labels, because internationalized labels use only octets <= 127 in DNS. Labels in DNS containing octets >= 128 are mysterious creatures that have no standard interpretation as text (because ASCII is the only text encoding used by the DNS standard). > IDNA section 6.3 does not rule out that utf8 encoded labels may be > used in DNS wire protocols in the future. In which case the specification of those future wire protocols will need to deal with the fact that UTF-8 forms of internationalized labels can have more than 63 octets. (255 is an upper bound, though not the least upper bound.) AMC From owner-idn@ops.ietf.org Mon Oct 14 01:01:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00432 for ; Mon, 14 Oct 2002 01:01:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180xGq-0004q9-00 for idn-data@psg.com; Sun, 13 Oct 2002 21:56:00 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180xGo-0004pv-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 21:55:58 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E4t6b23523; Mon, 14 Oct 2002 13:55:06 +0900 Message-ID: <3DAA4E7F.3030504@postel.co.kr> Date: Mon, 14 Oct 2002 13:56:31 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: James Seng CC: Paul Hoffman / IMC , idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: >Let me repeat again, > >the restriction is octet(ToASCII(X)) <= 63 (sorry, forget the =). > >The length restriction of a domain name (incidently, UTF-8 encoded string >which looks like domain name is not a domain name) in a DNS UDP packet is >something beyond this working group. > The restriction orginated from RFC1035 affects all label creation/validations. And "octet(ToASCII(X)) <= 63" seems to loosen the restrictions about 8bit labels. That is why i think RFC1035 restriction is about to be obsoleted. >Please bring it to the DNSEXT working group. > As a novice IETF pariticpant, I have little experience with DNSEXT WG. Would Area Directors make comment on this issue, Erik ? Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 01:19:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00609 for ; Mon, 14 Oct 2002 01:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180xQr-0005Bq-00 for idn-data@psg.com; Sun, 13 Oct 2002 22:06:21 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180xQp-0005Bd-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 22:06:19 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E55Wb23749; Mon, 14 Oct 2002 14:05:32 +0900 Message-ID: <3DAA50F1.5030200@postel.co.kr> Date: Mon, 14 Oct 2002 14:06:57 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Soobok Lee CC: James Seng , Paul Hoffman / IMC , idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_AND_TO_SAME_2,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee wrote: > > > James Seng wrote: > >> Let me repeat again, >> >> the restriction is octet(ToASCII(X)) <= 63 (sorry, forget the =). >> >> The length restriction of a domain name (incidently, UTF-8 encoded >> string >> which looks like domain name is not a domain name) > I cant' agree on your parenthesized claims. Please look into IDNA draft sections which mention utf8 encoding as alternative encoding for labels in applications and future protocols and even in future DNS protocols. Soobok Lee >> in a DNS UDP packet is >> something beyond this working group. > > The restriction orginated from RFC1035 affects all label > creation/validations. > And "octet(ToASCII(X)) <= 63" seems to loosen the restrictions about > 8bit labels. That is why i think RFC1035 restriction is about to be > obsoleted. > >> Please bring it to the DNSEXT working group. >> > As a novice IETF pariticpant, I have little experience with DNSEXT WG. > Would Area Directors make comment on this issue, Erik ? > > Soobok Lee > From owner-idn@ops.ietf.org Mon Oct 14 01:30:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00793 for ; Mon, 14 Oct 2002 01:30:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180xeM-0005Xj-00 for idn-data@psg.com; Sun, 13 Oct 2002 22:20:18 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180xeK-0005XV-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 22:20:17 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E5Jkb23963 for ; Mon, 14 Oct 2002 14:19:47 +0900 Message-ID: <3DAA5443.7000404@postel.co.kr> Date: Mon, 14 Oct 2002 14:21:07 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I read your previous long answer. Thanks, Adams. My comments begins... Adam M. Costello wrote: >Soobok Lee wrote: > > > >>If UTF8-encoded, that valid 8bit label will exceed 63 octets limits >>(up to 168 octets or more) >> >> > >True. > > > >>which is imposed by RFC1035 even upon non-ASCII 8bit labels . >> >> > >Yes, but labels in DNS containing octets >= 128 are not >internationalized labels, because internationalized labels use only >octets <= 127 in DNS. > Really ? then, please goto to the next comment below and compare your claim with IDNA's utf8 position. Length restriction itself in RFC1035 seems to have nothing to do with ASCII and non-ASCII distinctions, from the contexts. UDP packets length limit or practical label needs consideration seem to be behind that. > Labels in DNS containing octets >= 128 are >mysterious creatures that have no standard interpretation as text >(because ASCII is the only text encoding used by the DNS standard). > > > >>IDNA section 6.3 does not rule out that utf8 encoded labels may be >>used in DNS wire protocols in the future. >> >> > >In which case the specification of those future wire protocols will need >to deal with the fact that UTF-8 forms of internationalized labels can >have more than 63 octets. (255 is an upper bound, though not the least >upper bound.) > "UTF-8 forms of internationalized labels" are not "internationalized labels" ? if not, we should call them just " strings" as someone said ? I can't understand why utf8-form of a label is not a label. Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 01:41:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00997 for ; Mon, 14 Oct 2002 01:41:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180xn9-0005oL-00 for idn-data@psg.com; Sun, 13 Oct 2002 22:29:23 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 180xn6-0005nL-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 22:29:21 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9E5Rno1064733; Mon, 14 Oct 2002 15:27:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210140527.g9E5Rno1064733@drugs.dv.isc.org> To: Soobok Lee Cc: James Seng , Paul Hoffman / IMC , idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] length restrictions on IDN label In-reply-to: Your message of "Mon, 14 Oct 2002 13:56:31 +0900." <3DAA4E7F.3030504@postel.co.kr> Date: Mon, 14 Oct 2002 15:27:49 +1000 X-Spam-Status: No, hits=-5.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > > > James Seng wrote: > > >Let me repeat again, > > > >the restriction is octet(ToASCII(X)) <= 63 (sorry, forget the =). > > > >The length restriction of a domain name (incidently, UTF-8 encoded string > >which looks like domain name is not a domain name) in a DNS UDP packet is > >something beyond this working group. > > > The restriction orginated from RFC1035 affects all label > creation/validations. > And "octet(ToASCII(X)) <= 63" seems to loosen the restrictions about > 8bit labels. That is why i think RFC1035 restriction is about to be > obsoleted. There is nothing new with the number of octets in presentation form being greater those presented on the wire. In RFC 1034 0x00 is presented as "\000", 0x5c as "\\" or "\093", 0x2e as "\." or "\046". Mark > > >Please bring it to the DNSEXT working group. > > > As a novice IETF pariticpant, I have little experience with DNSEXT WG. > Would Area Directors make comment on this issue, Erik ? > > Soobok Lee > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Mon Oct 14 01:45:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01048 for ; Mon, 14 Oct 2002 01:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180xwz-00066e-00 for idn-data@psg.com; Sun, 13 Oct 2002 22:39:33 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180xwx-00066R-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 22:39:31 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E5cxb24368; Mon, 14 Oct 2002 14:38:59 +0900 Message-ID: <3DAA58C7.5080805@postel.co.kr> Date: Mon, 14 Oct 2002 14:40:23 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <200210140527.g9E5Rno1064733@drugs.dv.isc.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: >>The restriction orginated from RFC1035 affects all label >>creation/validations. >>And "octet(ToASCII(X)) <= 63" seems to loosen the restrictions about >>8bit labels. That is why i think RFC1035 restriction is about to be >>obsoleted. >> >> > > There is nothing new with the number of octets in presentation > form being greater those presented on the wire. In RFC > 1034 0x00 is presented as "\000", 0x5c as "\\" or "\093", > 0x2e as "\." or "\046". > UTF8-form of a label may be used as protocol elements , in addition to presentation forms. In the latter case, there will be no problem as you said above: just display it. But, in the former case of being used as protocols elements, utf8-form label length limit is of our concern. IDNA drafts does not rule out that utf-8 form of labels may be used as protocol elements. This will clairfy my point. Thanks. Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 02:02:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04538 for ; Mon, 14 Oct 2002 02:02:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180y9s-0006WD-00 for idn-data@psg.com; Sun, 13 Oct 2002 22:52:52 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 180y9r-0006W1-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 22:52:51 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 180y9q-0002DE-00 for ; Sun, 13 Oct 2002 22:52:50 -0700 Date: Mon, 14 Oct 2002 05:52:50 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021014055250.GD2930@nicemice.net> Reply-To: IETF idn working group References: <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAA5443.7000404@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > > Yes, but labels in DNS containing octets >= 128 are not > > internationalized labels, because internationalized labels use only > > octets <= 127 in DNS. > > Really ? Really. > "UTF-8 forms of internationalized labels" are not "internationalized > labels" ? The UTF-8 form of an internationalized label is an internationalized label. But that's irrelevant, because labels in DNS containing octets >= 128 are not UTF-8. The only text encoding used by DNS is ASCII (according to the current DNS standard). The octets >= 128 in DNS are non-ASCII, but that doesn't mean they are UTF-8. We don't know what they are, except octets. The UTF-8 form of an internationalized label is an internationalized label, but a sequence of octets with no charset tag is not an internationalized label (it's not even text). So I stand by my position quoted at the top of this message. AMC From owner-idn@ops.ietf.org Mon Oct 14 02:21:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10641 for ; Mon, 14 Oct 2002 02:21:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180yQP-0006ty-00 for idn-data@psg.com; Sun, 13 Oct 2002 23:09:57 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 180yQM-0006tm-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 23:09:55 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9E69qo1064916; Mon, 14 Oct 2002 16:09:52 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210140609.g9E69qo1064916@drugs.dv.isc.org> To: Soobok Lee Cc: idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] length restrictions on IDN label In-reply-to: Your message of "Mon, 14 Oct 2002 14:40:23 +0900." <3DAA58C7.5080805@postel.co.kr> Date: Mon, 14 Oct 2002 16:09:52 +1000 X-Spam-Status: No, hits=-6.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org wrote: > > >>The restriction orginated from RFC1035 affects all label > >>creation/validations. > >>And "octet(ToASCII(X)) <= 63" seems to loosen the restrictions about > >>8bit labels. That is why i think RFC1035 restriction is about to be > >>obsoleted. > >> > >> > > > > There is nothing new with the number of octets in presentation > > form being greater those presented on the wire. In RFC > > 1034 0x00 is presented as "\000", 0x5c as "\\" or "\093", > > 0x2e as "\." or "\046". > > > UTF8-form of a label may be used as protocol elements , in addition to > presentation forms. > In the latter case, there will be no problem as you said above: just > display it. > > But, in the former case of being used as protocols elements, utf8-form > label length limit is > of our concern. IDNA drafts does not rule out that utf-8 form of labels > may be used as protocol > elements. This will clairfy my point. The restrictions have always derived from the DNS wire format. Each individual presentation format will have its own maximum number of octets however just because a string fits within that number of octets doesn't mean that it will be valid. Invalid 0123456789012345678901234567890123456789012345678901234567891234 Valid \048\049\050\051\052\053\054\055\056\057\048\049\050\051\052\053 Both of the above presentation strings are 64 octets long. Only one is a legal label, both are < 252 octets that you would have to allow to convert a arbitary label from wire format to to RFC 1034 presentation format. Similar things will happen with UTF-8 as a presentation format. Only after you have attempted to covert to wire format can you determine if a arbitarty string of UTF-8 characters that is less than the maximum number of octets long will fit. Mark > Thanks. > > Soobok Lee > > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Mon Oct 14 02:38:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10877 for ; Mon, 14 Oct 2002 02:38:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180yih-0007Hj-00 for idn-data@psg.com; Sun, 13 Oct 2002 23:28:51 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180yif-0007HX-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 23:28:49 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E6SJb25189 for ; Mon, 14 Oct 2002 15:28:19 +0900 Message-ID: <3DAA6455.3010302@postel.co.kr> Date: Mon, 14 Oct 2002 15:29:41 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label References: <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> <20021014055250.GD2930@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: >Soobok Lee wrote: > > > >>>Yes, but labels in DNS containing octets >= 128 are not >>>internationalized labels, because internationalized labels use only >>>octets <= 127 in DNS. >>> >>> >>Really ? >> >> > >Really. > > > >>"UTF-8 forms of internationalized labels" are not "internationalized >>labels" ? >> >> > >The UTF-8 form of an internationalized label is an internationalized >label. But that's irrelevant, because labels in DNS containing octets > > >>= 128 are not UTF-8. The only text encoding used by DNS is ASCII >> >> >(according to the current DNS standard). The octets >= 128 in DNS are >non-ASCII, but that doesn't mean they are UTF-8. We don't know what >they are, except octets. > But, UTF-8 forms make subset of the entire set of non-ASCII forms. Thus, the utf8-compliant subset has been under the oversall length restriction imposed by RFC1035 on the entire set. > >The UTF-8 form of an internationalized label is an internationalized >label, but a sequence of octets with no charset tag is not an >internationalized label (it's not even text). > UTF8-form of labels carry no language/encoding tag in them (unlike MIME does.) They can be only assumed or negotiated through other channel in protocols. Soobok Lee > >So I stand by my position quoted at the top of this message. > >AMC > > From owner-idn@ops.ietf.org Mon Oct 14 03:07:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11133 for ; Mon, 14 Oct 2002 03:07:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 180z7r-0007rR-00 for idn-data@psg.com; Sun, 13 Oct 2002 23:54:51 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 180z7o-0007rF-00 for idn@ops.ietf.org; Sun, 13 Oct 2002 23:54:48 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E6sGb25651; Mon, 14 Oct 2002 15:54:16 +0900 Message-ID: <3DAA6A6F.4050307@postel.co.kr> Date: Mon, 14 Oct 2002 15:55:43 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <200210140609.g9E69qo1064916@drugs.dv.isc.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.4 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit About presentation formats, you argument stands. UTF8 form of labels further can be URLEncoded with %xx sequences into tripled length of character streams. That means "56 x U+AC00 " can be converted into 56 x 3 (utf8) x 3 (URLencode) = 504 octets string. RFC1035 length restriction does not apply to presentation forms. This is your point. right? But, my question is about utf8 form as protocol elements (wire format for future application or DNS protocols), not as presentation forms. You can find that in IDNA section 6.3. Would you make another comments on that section ? THanks. Soobok Lee Mark.Andrews@isc.org wrote: > The restrictions have always derived from the DNS wire format. > Each individual presentation format will have its own maximum > number of octets however just because a string fits within > that number of octets doesn't mean that it will be valid. > > Invalid > 0123456789012345678901234567890123456789012345678901234567891234 > > Valid > \048\049\050\051\052\053\054\055\056\057\048\049\050\051\052\053 > > Both of the above presentation strings are 64 octets long. Only > one is a legal label, both are < 252 octets that you would have > to allow to convert a arbitary label from wire format to > to RFC 1034 presentation format. Similar things will happen > with UTF-8 as a presentation format. Only after you have attempted > to covert to wire format can you determine if a arbitarty string > of UTF-8 characters that is less than the maximum number of octets > long will fit. > > Mark > > From owner-idn@ops.ietf.org Mon Oct 14 04:03:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11892 for ; Mon, 14 Oct 2002 04:03:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18104A-0009Ok-00 for idn-data@psg.com; Mon, 14 Oct 2002 00:55:06 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 181048-0009OY-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 00:55:04 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 181047-0002YX-00 for ; Mon, 14 Oct 2002 00:55:03 -0700 Date: Mon, 14 Oct 2002 07:55:02 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021014075502.GE2930@nicemice.net> Reply-To: IETF idn working group References: <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> <20021014055250.GD2930@nicemice.net> <3DAA6455.3010302@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAA6455.3010302@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > UTF-8 forms make subset of the entire set of non-ASCII forms. > Thus, the utf8-compliant subset has been under the overall length > restriction imposed by RFC1035 on the entire set. UTF-8 data stored directly in 8-bit DNS labels would be subject to the 63-octet limit. This is irrelevant to IDNs, because IDNs do not store UTF-8 data directly in 8-bit DNS labels. IDNA requires that internationalized labels use their 7-bit ASCII form in DNS. If someday you want to use UTF-8 forms of internationalized labels directly in newDNS, you will need to make sure that newDNS allows more than 63 octets per label. Or you could use the UTF-8 form when it fits, and fall back to the ASCII form when UTF-8 doesn't fit. (Or you could decide it's easier to stick with ASCII in the DNS protocol, and create the illusion of UTF-8 using a new resolver on the client.) Your argument seems to be: 1. An internationalized label in UTF-8 form is a sequence of octets. 2. RFC 1035 limits labels to 63 octets. 3. Therefore internationalized labels must have no more than 63 octets in UTF-8 form. But you could try the same argument for UTF-16, and EUC-KR, and iso-2022-jp, and BIG5, etc. Do we conclude that any string that uses more than 63 octets in any encoding cannot be an internationalized label? That would be absurd. Perhaps the key to understanding this is to recognize that 8-bit DNS labels are not internationalized labels. IDNA makes no use of them. Neither IDNA nor DNS defines any textual interpretation for them. They are just opaque binary data (except for the values <= 127, which are ASCII characters). We have no way of deciding whether 8-bit labels are UTF-8 or ISO-8859-1 or EUC-JP, etc. Until the DNS standard is updated to assign some semantics, they are none of the above. IDNA created some brand new kinds of labels that had never existed before: non-ASCII textual labels. They have never appeared in DNS, cannot appear in DNS, and will not be able to appear in DNS unless DNS is updated to support them (because the only text supported by today's DNS is ASCII). These new non-ASCII textual labels are outside the universe of labels defined by RFC 1035, and therefore the RFC 1035 length restriction does not apply to them (not directly, although it applies to their corresponding ASCII forms). AMC From owner-idn@ops.ietf.org Mon Oct 14 04:05:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11917 for ; Mon, 14 Oct 2002 04:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18101R-0009KY-00 for idn-data@psg.com; Mon, 14 Oct 2002 00:52:17 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18101P-0009KM-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 00:52:15 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9E7qAo1065368; Mon, 14 Oct 2002 17:52:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210140752.g9E7qAo1065368@drugs.dv.isc.org> To: Soobok Lee Cc: idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] length restrictions on IDN label In-reply-to: Your message of "Mon, 14 Oct 2002 15:55:43 +0900." <3DAA6A6F.4050307@postel.co.kr> Date: Mon, 14 Oct 2002 17:52:10 +1000 X-Spam-Status: No, hits=-7.1 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > About presentation formats, you argument stands. > UTF8 form of labels further can be URLEncoded with %xx sequences into > tripled length of character streams. > That means "56 x U+AC00 " can be converted into > 56 x 3 (utf8) x 3 (URLencode) = 504 octets string. > RFC1035 length restriction does not apply to presentation forms. This is > your point. right? Yes. > But, my question is about utf8 form as protocol elements (wire format > for future > application or DNS protocols), not as presentation forms. > You can find that in IDNA section 6.3. > Would you make another comments on that section ? Well if you use raw utf-8 today int the DNS you are limited to 63 octets per label. 255 octets for a domain name. As long as you continue to use the same label encoding you are limited to 63 octets. YMMV at levels other than the DNS. However > THanks. > > Soobok Lee > > > Mark.Andrews@isc.org wrote: > > > The restrictions have always derived from the DNS wire format. > > Each individual presentation format will have its own maximum > > number of octets however just because a string fits within > > that number of octets doesn't mean that it will be valid. > > > > Invalid > > 0123456789012345678901234567890123456789012345678901234567891234 > > > > Valid > > \048\049\050\051\052\053\054\055\056\057\048\049\050\051\052\053 > > > > Both of the above presentation strings are 64 octets long. Only > > one is a legal label, both are < 252 octets that you would have > > to allow to convert a arbitary label from wire format to > > to RFC 1034 presentation format. Similar things will happen > > with UTF-8 as a presentation format. Only after you have attempted > > to covert to wire format can you determine if a arbitarty string > > of UTF-8 characters that is less than the maximum number of octets > > long will fit. > > > > Mark > > > > > > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Mon Oct 14 04:36:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12239 for ; Mon, 14 Oct 2002 04:36:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1810X7-000A6l-00 for idn-data@psg.com; Mon, 14 Oct 2002 01:25:01 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1810X3-000A6M-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 01:24:57 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E8OQb27261 for ; Mon, 14 Oct 2002 17:24:26 +0900 Message-ID: <3DAA7F93.2080100@postel.co.kr> Date: Mon, 14 Oct 2002 17:25:55 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label References: <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> <20021014055250.GD2930@nicemice.net> <3DAA6455.3010302@postel.co.kr> <20021014075502.GE2930@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > > >IDNA created some brand new kinds of labels that had never existed >before: non-ASCII textual labels. They have never appeared in DNS, >cannot appear in DNS, and will not be able to appear in DNS unless DNS >is updated to support them (because the only text supported by today's >DNS is ASCII). These new non-ASCII textual labels are outside the >universe of labels defined by RFC 1035, and therefore the RFC 1035 >length restriction does not apply to them (not directly, although it >applies to their corresponding ASCII forms). > Okay. non-ACE textual labels can be used and rendered in document format. But, IDNA section 6.1 goes further than that by allowing _protocols_ to use non-ACE labels which are not presentation forms nor textual labels, but protocol elements. What if future ESMTP allows utf8 encodings in RCPT: headers ? Would you comment on this section? 6.1 Entry and display in applications (snip) In protocols and document formats that define how to handle specification or negotiation of charsets, labels can be encoded in any charset allowed by the protocol or document format. If a protocol or document format only allows one charset, the labels MUST be given in that charset. In any place where a protocol or document format allows transmission of the characters in internationalized labels, internationalized labels SHOULD be transmitted using whatever character encoding and escape mechanism that the protocol or document format uses at that place. From owner-idn@ops.ietf.org Mon Oct 14 05:23:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12862 for ; Mon, 14 Oct 2002 05:23:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1811KN-000BLw-00 for idn-data@psg.com; Mon, 14 Oct 2002 02:15:55 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 1811KL-000BLe-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 02:15:53 -0700 Received: (qmail 12395 invoked from network); 14 Oct 2002 09:17:25 -0000 Received: from bb-203-125-95-28.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.95.28) by sentosa.post1.com with SMTP; 14 Oct 2002 09:17:25 -0000 Message-ID: <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "Soobok Lee" Cc: "Paul Hoffman / IMC" , References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> Subject: Re: [idn] length restrictions on IDN label Date: Mon, 14 Oct 2002 17:13:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-6.0 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >>(incidently, UTF-8 encoded string which looks like domain name is > >>not a domain name) > > I cant' agree on your parenthesized claims. Please look into IDNA draft > sections which mention utf8 encoding as alternative encoding for labels in > applications and future protocols and even in future DNS protocols. Adam has already answered you on this. "Yes, but labels in DNS containing octets >= 128 are not internationalized labels, because internationalized labels use only octets <= 127 in DNS. Labels in DNS containing octets >= 128 are mysterious creatures that have no standard interpretation as text (because ASCII is the only text encoding used by the DNS standard)." Therefore, a UTF-8 string which was somehow squeeze into the DNS packet has no meaning right now. IDNA do not ignore the possibility of using UTF-8 in DNS Packet. But the use is yet to be defined. Until it is defined, it is useless to discuss that possibility. > As a novice IETF pariticpant, I have little experience with DNSEXT WG. > Would Area Directors make comment on this issue, Erik ? I think even a novice participiant like yourself would know better to lookup the the DNSEXT yourself then to bother ADs with such little nitpicks. http://www.ietf.org/html.charters/dnsext-charter.html "Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group." So bring your problem of label length (which I am not very sure what you arguing...expand? reduce?) and propose a solution for that in DNSEXT. Alternatively, you can look at some of the past proposal which utilized UTF-8 and EDNS. One of them (the one written by Marc) allows about 255 UTF-8 octet and considering getting the authors resubmit them again to the DNSEXT WG. Of course, you may continue to talk about the confusion of the label length limit here. But it will do you no good especially it seem that you are the only one who is confused. -James Seng From owner-idn@ops.ietf.org Mon Oct 14 06:00:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13367 for ; Mon, 14 Oct 2002 06:00:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1811nm-000CAg-00 for idn-data@psg.com; Mon, 14 Oct 2002 02:46:18 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1811nj-000CAT-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 02:46:15 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E9jfb28696; Mon, 14 Oct 2002 18:45:41 +0900 Message-ID: <3DAA929F.1070409@postel.co.kr> Date: Mon, 14 Oct 2002 18:47:11 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: James Seng CC: Paul Hoffman / IMC , idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: >Therefore, a UTF-8 string which was somehow squeeze into the DNS packet has >no meaning right now. > >IDNA do not ignore the possibility of using UTF-8 in DNS Packet. But the use >is yet to be defined. Until it is defined, it is useless to discuss that >possibility. > > > Your argument stands only in DNS on-the-wire context. IN all other protocol/display contexts, utf8 labels are legitimate domain labels. That is why zone admins may input their labels in utf8 into their zone files and end users recoginze them as domain names. Moreover, I didn't limit my question into DNS and its protocols (just 'protocol', DNS is not the 'all') Rather, that may span into all application protocols that use domain names, like future ESMTP. There will be many application protocols (IETF's or home-made) that may exchange utf8-form labels as protocols elements (not for human eyes) according to IDNA section 6.1-3. IDNA draft granted such use of utf8 labels as legitimate one. Length restriction should be clarified before IDN deployments. Currently valid IDN label should not be invalidated in the future due to today's misspecifications. To avoid buffer overflow errors and security breaches, label length issues are practically important to implementors who want to estimate enough buffer spaces for IDN labels. Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 06:09:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13492 for ; Mon, 14 Oct 2002 06:09:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1811ve-000CO1-00 for idn-data@psg.com; Mon, 14 Oct 2002 02:54:26 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1811vb-000CNl-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 02:54:25 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9E9rib28837; Mon, 14 Oct 2002 18:53:44 +0900 Message-ID: <3DAA9482.5040807@postel.co.kr> Date: Mon, 14 Oct 2002 18:55:14 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Soobok Lee CC: James Seng , Paul Hoffman / IMC , idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> <3DAA929F.1070409@postel.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_AND_TO_SAME_2,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee wrote: > James Seng wrote: > >> Therefore, a UTF-8 string which was somehow squeeze into the DNS >> packet has >> no meaning right now. >> >> IDNA do not ignore the possibility of using UTF-8 in DNS Packet. But >> the use >> is yet to be defined. Until it is defined, it is useless to discuss that >> possibility. >> >> >> > Your argument stands only in DNS on-the-wire context. IN all other > protocol/display > contexts, utf8 labels are legitimate domain labels. That is why zone > admins may input > their labels in utf8 into their zone files and of course, the dns server may read them and convert into ACE forms on the fly in reading zone files. Just to prevent misunderstating the sentence. Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 06:30:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13861 for ; Mon, 14 Oct 2002 06:30:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1812Lw-000D7k-00 for idn-data@psg.com; Mon, 14 Oct 2002 03:21:36 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 1812Lt-000D6M-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 03:21:33 -0700 Received: (qmail 13501 invoked from network); 14 Oct 2002 10:23:06 -0000 Received: from bb-203-125-95-28.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.95.28) by sentosa.post1.com with SMTP; 14 Oct 2002 10:23:06 -0000 Message-ID: <03fe01c2736b$18ef0e10$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "Soobok Lee" Cc: "Paul Hoffman / IMC" , References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> <3DAA929F.1070409@postel.co.kr> Subject: Re: [idn] length restrictions on IDN label Date: Mon, 14 Oct 2002 18:18:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-5.4 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Your argument stands only in DNS on-the-wire context. IN all other > protocol/display > contexts, utf8 labels are legitimate domain labels. That is why zone > admins may input > their labels in utf8 into their zone files and end users recoginze them > as domain names. utf8 labels have no meaning as domain name labels, as currently defined in RFC 1034/1035, whether on wire or otherwise. anything above 127 is a no-man-zone-use-it-at-your-own-risk. If you mean IDN labels encoded in UTF-8, then the restriction is fairly simply, one already explained to you multiple times, octet(ToASCII(X))<=63. > Moreover, > I didn't limit my question into DNS and its protocols (just 'protocol', > DNS is not the 'all') > Rather, that may span into all application protocols that use domain names, > like future ESMTP. Then it is worst then you think. This working group is definately not going to be able to address all the concerns of all application protocols that uses domain names, much less a future work in ESMTP. That work should be address in other specific applications protocol and DEFINATELY not in this working group. I still hope to conclude this working group within the next few months and get on with my life, dealing with other IDN related issues. > There will be many application protocols (IETF's or home-made) that > may exchange utf8-form labels as protocols elements (not for human eyes) > according to IDNA section 6.1-3. IDNA draft granted such use of utf8 > labels as legitimate one. Then shouldn't that application protocol be updated? > Length restriction should be clarified before IDN deployments. > Currently valid IDN label should not be invalidated in the future due to > today's misspecifications. Yes, it should be clarify if there is any confusion. But there is no confusion as far as I know. The length restriction is quite clear, octet(ToASCII(X))<=63. Or are you still confused? > To avoid buffer overflow errors and security breaches, label length issues > are practically important to implementors who want to estimate enough > buffer > spaces for IDN labels. Since when implementation issue is part of the working group charter? Please stop....Some might be scared by your FUD. -James Seng From owner-idn@ops.ietf.org Mon Oct 14 07:00:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14195 for ; Mon, 14 Oct 2002 07:00:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1812s3-000E2x-00 for idn-data@psg.com; Mon, 14 Oct 2002 03:54:47 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 1812s0-000E2b-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 03:54:45 -0700 Received: (qmail 13931 invoked from network); 14 Oct 2002 10:56:17 -0000 Received: from bb-203-125-95-28.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.95.28) by sentosa.post1.com with SMTP; 14 Oct 2002 10:56:17 -0000 Message-ID: <047301c2736f$b9719cf0$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "Soobok Lee" Cc: References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> <3DAA929F.1070409@postel.co.kr> <03fe01c2736b$18ef0e10$ad00a8c0@JSENGTOSHIBA> <3DAAA153.8010203@postel.co.kr> Subject: Re: [idn] length restrictions on IDN label Date: Mon, 14 Oct 2002 18:52:00 +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=-4.7 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Then, you should not convert ACE-form iDN int UTF8 and render it for users. > Doesn't this Looks absurd ? You claims seem against IDNA drafts. > My current argument is based on IDNA draft section 6. Section 6.1 describe how "Entry and display in application". It makes no mention of UTF-8 as can read. Which paragraph are you referring to? > As one security programmer, i think the above issue is very important. > James, you begin to be nervous, typical of you. Be comfortable and easy. > The audiences are knowledgable,experienced and prudent enough. What makes you think I am nervous? Obviously you didnt catch the sacarism in FUD... -James Seng From owner-idn@ops.ietf.org Mon Oct 14 07:01:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14218 for ; Mon, 14 Oct 2002 07:01:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1812mX-000Dt9-00 for idn-data@psg.com; Mon, 14 Oct 2002 03:49:05 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1812mV-000Dsj-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 03:49:03 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9EAmOb29746; Mon, 14 Oct 2002 19:48:24 +0900 Message-ID: <3DAAA153.8010203@postel.co.kr> Date: Mon, 14 Oct 2002 19:49:55 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: James Seng CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> <3DAA929F.1070409@postel.co.kr> <03fe01c2736b$18ef0e10$ad00a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.1 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: >>Your argument stands only in DNS on-the-wire context. IN all other >>protocol/display >> contexts, utf8 labels are legitimate domain labels. That is why zone >>admins may input >>their labels in utf8 into their zone files and end users recoginze them >>as domain names. >> >> > >utf8 labels have no meaning as domain name labels, as currently defined in >RFC 1034/1035, whether on wire or otherwise. anything above 127 is a >no-man-zone-use-it-at-your-own-risk. > Then, you should not convert ACE-form iDN int UTF8 and render it for users. Doesn't this Looks absurd ? You claims seem against IDNA drafts. My current argument is based on IDNA draft section 6. > >If you mean IDN labels encoded in UTF-8, then the restriction is fairly >simply, one already explained to you multiple times, octet(ToASCII(X))<=63. > > > >>Moreover, >>I didn't limit my question into DNS and its protocols (just 'protocol', >>DNS is not the 'all') >>Rather, that may span into all application protocols that use domain >> >> >names, > > >>like future ESMTP. >> >> > >Then it is worst then you think. This working group is definately not going >to be able to address all the concerns of all application protocols that >uses domain names, much less a future work in ESMTP. That work should be >address in other specific applications protocol and DEFINATELY not in this >working group. > >I still hope to conclude this working group within the next few months and >get on with my life, dealing with other IDN related issues. > > > > >>There will be many application protocols (IETF's or home-made) that >>may exchange utf8-form labels as protocols elements (not for human eyes) >>according to IDNA section 6.1-3. IDNA draft granted such use of utf8 >>labels as legitimate one. >> >> > >Then shouldn't that application protocol be updated? > Home-made or legacy protocols outnumbers IETF protocols. Moreoever, when even IETFers begin to update some protocols to use utf8 labels under IETF umbrella, they will be stuck at this stone: utf8 label length. They will find an utf8 label may have 168 octets, contrary to RFC1035. When IDNA draft granted utf8 label use in application protocols, it is natural that it should have also specified utf8 label length restrictions. > > > >>Length restriction should be clarified before IDN deployments. >>Currently valid IDN label should not be invalidated in the future due to >>today's misspecifications. >> >> > >Yes, it should be clarify if there is any confusion. > >But there is no confusion as far as I know. The length restriction is quite >clear, octet(ToASCII(X))<=63. Or are you still confused? > > > >>To avoid buffer overflow errors and security breaches, label length >> >> >issues > > >>are practically important to implementors who want to estimate enough >>buffer >>spaces for IDN labels. >> >> > >Since when implementation issue is part of the working group charter? > >Please stop....Some might be scared by your FUD. > >-James Seng > > As one security programmer, i think the above issue is very important. James, you begin to be nervous, typical of you. Be comfortable and easy. The audiences are knowledgable,experienced and prudent enough. Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 07:07:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14294 for ; Mon, 14 Oct 2002 07:07:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1812zW-000EHh-00 for idn-data@psg.com; Mon, 14 Oct 2002 04:02:30 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1812zS-000EHQ-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 04:02:26 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9EB1rb30070; Mon, 14 Oct 2002 20:01:53 +0900 Message-ID: <3DAAA474.70607@postel.co.kr> Date: Mon, 14 Oct 2002 20:03:16 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: James Seng CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> <3DAA929F.1070409@postel.co.kr> <03fe01c2736b$18ef0e10$ad00a8c0@JSENGTOSHIBA> <3DAAA153.8010203@postel.co.kr> <047301c2736f$b9719cf0$ad00a8c0@JSENGTOSHIBA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: >>Then, you should not convert ACE-form iDN int UTF8 and render it for >> >> >users. > > >>Doesn't this Looks absurd ? You claims seem against IDNA drafts. >>My current argument is based on IDNA draft section 6. >> >> > >Section 6.1 describe how "Entry and display in application". It makes no >mention of UTF-8 as can read. Which paragraph are you referring to? > > Look into Section 6.1 and the IDNA architecture figure, please. The authors themselves may clarifiy the reading of the section, better than you James and me. ============================ 6.1 Entry and display in applications (snip) In protocols and document formats that define how to handle specification or negotiation of charsets, labels can be encoded in any charset allowed by the protocol or document format. If a protocol or document format only allows one charset, the labels MUST be given in that charset. In any place where a protocol or document format allows transmission of the characters in internationalized labels, internationalized labels SHOULD be transmitted using whatever character encoding and escape mechanism that the protocol or document format uses at that place From owner-idn@ops.ietf.org Mon Oct 14 07:09:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14314 for ; Mon, 14 Oct 2002 07:09:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1812zq-000EI9-00 for idn-data@psg.com; Mon, 14 Oct 2002 04:02:50 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 1812zo-000EHD-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 04:02:48 -0700 Received: (qmail 14011 invoked from network); 14 Oct 2002 11:04:20 -0000 Received: from bb-203-125-95-28.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.95.28) by sentosa.post1.com with SMTP; 14 Oct 2002 11:04:20 -0000 Message-ID: <049301c27370$d98ec8e0$ad00a8c0@JSENGTOSHIBA> From: "James Seng" To: "James Seng" , "Soobok Lee" Cc: References: <20021013065656.GA22861@postel.co.kr> <20021014015432.GA20396@postel.co.kr> <3DAA2F3C.8080109@postel.co.kr> <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <030201c27338$af22a000$ad00a8c0@JSENGTOSHIBA> <3DAA4E7F.3030504@postel.co.kr> <3DAA50F1.5030200@postel.co.kr> <034101c27361$ebd54600$ad00a8c0@JSENGTOSHIBA> <3DAA929F.1070409@postel.co.kr> <03fe01c2736b$18ef0e10$ad00a8c0@JSENGTOSHIBA> <3DAAA153.8010203@postel.co.kr> <047301c2736f$b9719cf0$ad00a8c0@JSENGTOSHIBA> Subject: Re: [idn] length restrictions on IDN label Date: Mon, 14 Oct 2002 19:00:03 +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.5 required=5.0 tests=FROM_AND_TO_SAME_6,INVALID_MSGID,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The length restriction in IDN label is confusing comes from a confused individual. The specification is quite clear that the only restriction is based on the octet length of the ToASCII string. So unless there is others who wish to continue this topic, lets put this thread to a rest. -James Seng From owner-idn@ops.ietf.org Mon Oct 14 09:18:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18949 for ; Mon, 14 Oct 2002 09:18:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1814y7-000I6I-00 for idn-data@psg.com; Mon, 14 Oct 2002 06:09:11 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1814y5-000I66-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 06:09:10 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9ED8Zb32211; Mon, 14 Oct 2002 22:08:35 +0900 Message-ID: <3DAAC230.40100@postel.co.kr> Date: Mon, 14 Oct 2002 22:10:08 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <200210140752.g9E7qAo1065368@drugs.dv.isc.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > Well if you use raw utf-8 today int the DNS you are limited to > 63 octets per label. 255 octets for a domain name. As long as > you continue to use the same label encoding you are limited to > 63 octets. YMMV at levels other than the DNS. > Sure. If the limit may vary at levels (applications)other than the DNS, the utf8 labels may exceed 63 octets in appliction protocol formats (not for display) and the implementors should reserve enough buffer spaces for ToUnicoded(ACE) utf8 labels. This really matters because many programmers favor utf8 as internal representation format of unicode strings for its ascii compatibility. Most applications programmer have been reserving 256 bytes for any LDH FQDN buffer space . But that convention should be changed to cover the cases of long utf8 IDN FQDN which may be 3 or 4 times longer than 256 octets. So, 1024 or 768 bytes are good. But those utf8 FQDN cannot be put into single UDP packet of DNS response/query. This will constrain future DNS protocol update efforts around utf8 supports in wire format. TOday's long iDNs may be one of the obstacles in the way to the effort. If this warning is neglected by application programmers, some remote malicious crackers will send to users' applications long ACE IDNs manufactured to cause buffer overflow errors when toUnicoded and seaze control of the machine. Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 09:57:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20591 for ; Mon, 14 Oct 2002 09:57:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1815ZQ-000JJ2-00 for idn-data@psg.com; Mon, 14 Oct 2002 06:47:44 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 1815ZP-000JIq-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 06:47:43 -0700 Received: from [165.227.249.18] (165-227-249-21.client.dsl.net [165.227.249.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9EDlXv03086; Mon, 14 Oct 2002 06:47:33 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3DAAC230.40100@postel.co.kr> References: <200210140752.g9E7qAo1065368@drugs.dv.isc.org> <3DAAC230.40100@postel.co.kr> 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: Mon, 14 Oct 2002 06:47:33 -0700 To: Soobok Lee From: Paul Hoffman / IMC Subject: Re: [idn] length restrictions on IDN label Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.7 required=5.0 tests=HABEAS_SWE,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:10 PM +0900 10/14/02, Soobok Lee wrote: >Most applications programmer have been reserving 256 bytes for any LDH >FQDN buffer space . It is amazingly arrogant for anyone to make statements about "most applications programmer". >But that convention should be changed to cover the cases of long utf8 >IDN FQDN which may be >3 or 4 times longer than 256 octets. Why just UTF8? Why not UTF16? Or GB? Or ... ? >If this warning is neglected by application programmers, >some remote malicious crackers will send to users' applications long ACE >IDNs manufactured to >cause buffer overflow errors when toUnicoded and seaze control of the >machine. Oh, come on. Step 6 of ToUnicode is exactly two words long. Which one of those two words do you think that other applications programmers will not understand? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Oct 14 10:02:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20832 for ; Mon, 14 Oct 2002 10:02:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1815dm-000JSr-00 for idn-data@psg.com; Mon, 14 Oct 2002 06:52:14 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 1815dk-000JSG-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 06:52:13 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25067 for ; Mon, 14 Oct 2002 07:52:10 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9EDq8Q15279 for ; Mon, 14 Oct 2002 15:52:09 +0200 (MEST) Date: Mon, 14 Oct 2002 15:49:20 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] length restrictions on IDN label To: IETF idn working group In-Reply-To: "Your message with ID" <20021014035158.GB2930@nicemice.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > That's true. A cursory examination of the Punycode algorithm reveals > that each ASCII character can represent at most one code point; > therefore an internationalized label can represent at most 63 code > points, whether it's ACE or not. A given encoding uses a bounded number > of octets per code point, so you can allocate your buffers based on > that. 63 code points is presumably a conservative number. Given the 4 octet ACE prefix you can only fit a 59 octets worth of punycode output per label, hence presumably 59 code points is a tighter limit for non-ASCII internationalized labels while 63 code points is the limit for ASCII labels. Erik From owner-idn@ops.ietf.org Mon Oct 14 10:19:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21436 for ; Mon, 14 Oct 2002 10:19:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1815n1-000Jms-00 for idn-data@psg.com; Mon, 14 Oct 2002 07:01:47 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1815mz-000Jme-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 07:01:45 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9EE1Ab00714; Mon, 14 Oct 2002 23:01:10 +0900 Message-ID: <3DAACE84.2020203@postel.co.kr> Date: Mon, 14 Oct 2002 23:02:44 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Paul Hoffman / IMC CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <200210140752.g9E7qAo1065368@drugs.dv.isc.org> <3DAAC230.40100@postel.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > At 10:10 PM +0900 10/14/02, Soobok Lee wrote: > >> Most applications programmer have been reserving 256 bytes for any LDH >> FQDN buffer space . > > > It is amazingly arrogant for anyone to make statements about "most > applications programmer". I accepted. :-) > > >> But that convention should be changed to cover the cases of long utf8 >> IDN FQDN which may be >> 3 or 4 times longer than 256 octets. > > > Why just UTF8? Why not UTF16? Or GB? Or ... ? I already mentioned other encodings in the early postings. > > >> If this warning is neglected by application programmers, >> some remote malicious crackers will send to users' applications long ACE >> IDNs manufactured to >> cause buffer overflow errors when toUnicoded and seaze control of the >> machine. > > > Oh, come on. Step 6 of ToUnicode is exactly two words long. Which one > of those two words do you think that other applications programmers > will not understand? "6. Apply ToASCII " is for verification purpose and it won't change that situation. Step 8 of ToUnicode function which may have enough buffer space itself will return long unicode string result to cal;ling applications that may have shorter buffer space. > > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Oct 14 10:38:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22005 for ; Mon, 14 Oct 2002 10:38:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1816GL-000Kvr-00 for idn-data@psg.com; Mon, 14 Oct 2002 07:32:05 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 1816GI-000Kvf-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 07:32:02 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17742; Mon, 14 Oct 2002 08:32:00 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9EEVwQ19582; Mon, 14 Oct 2002 16:31:59 +0200 (MEST) Date: Mon, 14 Oct 2002 16:29:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] length restrictions on IDN label To: Soobok Lee Cc: James Seng , Paul Hoffman / IMC , idn@ops.ietf.org In-Reply-To: "Your message with ID" <3DAA4E7F.3030504@postel.co.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > >Please bring it to the DNSEXT working group. > > > As a novice IETF pariticpant, I have little experience with DNSEXT WG. > Would Area Directors make comment on this issue, Erik ? When and if there is a need to carry IDNs in the DNS protocol using octet values above 127 the DNSEXT WG would be the place to discuss this. However, I still haven't seen a fully worked out approach for doing this that takes DNSSEC into account. (draft-hall-dm-idns is the clostest I've seen, but it doesn't get into DNSSEC issues). When and if this is approach, there are presumably multiple encodings that can be used. One is UTF-8; another possibility would be to define a bootstring algorithm from Unicode to octets in the range 0-255. The latter would carry the bootstring compression features forward into these encodings. Taking length limits into account would be one part of that work. > UTF8-form of a label may be used as protocol elements , in addition to > presentation forms. > In the latter case, there will be no problem as you said above: just > display it. > > But, in the former case of being used as protocols elements, utf8-form > label length limit is > of our concern. IDNA drafts does not rule out that utf-8 form of labels > may be used as protocol > elements. This will clairfy my point. See above. But perhaps IDNA should be more clear that there is a length issue for such future work. For instance, would adding a sentence at the end of this paragraph be helpful? If a signaling system which makes negotiation possible between old and new DNS clients and servers is standardized in the future, the encoding of the query in the DNS protocol itself can be changed from ACE to something else, such as UTF-8. The question whether or not this should be used is, however, a separate problem and is not discussed in this memo. E.g. "Such work would have to take into account the length limit for IDNs as specified in this document". It might also be useful to make the IDNA specification more clear about the length limit and its implications somewhere in the document. Strawman: The length limit for internationalized labels is the limit of at most 63 octets of output from ToASCII. The design of the Punycode encoding is such that some sequences of up to 63 Unicode code points result in ToASCII output of 63 or less octets, but all possible Unicode strings of 64 code points result in ToASCII output of 64 or more octets. Implementation Note: Depending on the local encoding the software uses for Unicode this can correspond to a lot more than 63 octets. Similarely, the total length of a IDN expressed in the local encoding can significantly exceed 255 octets. Erik From owner-idn@ops.ietf.org Mon Oct 14 17:44:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03525 for ; Mon, 14 Oct 2002 17:44:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181CsK-000AMN-00 for idn-data@psg.com; Mon, 14 Oct 2002 14:35:44 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 181CsI-000AM2-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 14:35:42 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9ELZco1066696; Tue, 15 Oct 2002 07:35:38 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210142135.g9ELZco1066696@drugs.dv.isc.org> To: Soobok Lee Cc: idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] length restrictions on IDN label In-reply-to: Your message of "Mon, 14 Oct 2002 22:10:08 +0900." <3DAAC230.40100@postel.co.kr> Date: Tue, 15 Oct 2002 07:35:38 +1000 X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org wrote: > > > Well if you use raw utf-8 today int the DNS you are limited to > > 63 octets per label. 255 octets for a domain name. As long as > > you continue to use the same label encoding you are limited to > > 63 octets. YMMV at levels other than the DNS. > > > Sure. > If the limit may vary at levels (applications)other than the DNS, the > utf8 labels may exceed 63 octets > in appliction protocol formats (not for display) and the implementors > should reserve enough buffer > spaces for ToUnicoded(ACE) utf8 labels. This really matters because many > programmers favor > utf8 as internal representation format of unicode strings for its ascii > compatibility. > > Most applications programmer have been reserving 256 bytes for any LDH > FQDN buffer space . Most applications will use NS_MAXDNAME or MAXDNAME to store a domain name today as that is enough to cover all the potential expansions from wire to RFC 1034 presentation format. Have a look at NS_MAXDNAME in . Unless you have a really old OS it will be at least (250*4 + 5) (minimum number of label that can appear in a full length domain name is 4 labels + root, all 4 periods + null). As I said what you are talking about is NOT new. These issues have existed for years. > But that convention should be changed to cover the cases of long utf8 > IDN FQDN which may be > 3 or 4 times longer than 256 octets. So, 1024 or 768 bytes are good. But > those utf8 FQDN cannot > be put into single UDP packet of DNS response/query. This will constrain > future DNS protocol > update efforts around utf8 supports in wire format. TOday's long iDNs > may be one of the obstacles > in the way to the effort. That was one of the reasons why raw utf8 was rejected for the wire, > If this warning is neglected by application programmers, > some remote malicious crackers will send to users' applications long ACE > IDNs manufactured to > cause buffer overflow errors when toUnicoded and seaze control of the > machine. FUD. > > Soobok Lee > > > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Mon Oct 14 18:25:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04558 for ; Mon, 14 Oct 2002 18:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181DbR-000Cc6-00 for idn-data@psg.com; Mon, 14 Oct 2002 15:22:21 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 181DbP-000Cay-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 15:22:19 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 181DbN-000629-00 for ; Mon, 14 Oct 2002 15:22:17 -0700 Date: Mon, 14 Oct 2002 22:22:17 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021014222216.GB15892@nicemice.net> Reply-To: IETF idn working group References: <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> <20021014055250.GD2930@nicemice.net> <3DAA6455.3010302@postel.co.kr> <20021014075502.GE2930@nicemice.net> <3DAA7F93.2080100@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAAC230.40100@postel.co.kr> <3DAAA153.8010203@postel.co.kr> <3DAA7F93.2080100@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik Nordmark wrote: > > an internationalized label can represent at most 63 code points, > > whether it's ACE or not. A given encoding uses a bounded number of > > octets per code point, so you can allocate your buffers based on > > that. > > 63 code points is presumably a conservative number. Given the 4 octet > ACE prefix you can only fit a 59 octets worth of punycode output > per label, hence presumably 59 code points is a tighter limit for > non-ASCII internationalized labels while 63 code points is the limit > for ASCII labels. True, but which limit you care about depends on the encoding. For example, if you're using UTF-32, then a regular ASCII label can have 63 code points each occupying 4 octets. Soobok Lee wrote: > IDNA section 6.1 goes further than that by allowing _protocols_ to use > non-ACE labels which are not presentation forms nor textual labels, > but protocol elements. What if future ESMTP allows utf8 encodings in > RCPT: headers ? Then applications that implement future ESMTP will need to be prepared for UTF-8 labels to contain more than 63 octets. This is not a problem, because any application that can even think about using non-ASCII labels is aware of IDNA, and therefore knows the definition of internationalized label, and therefore knows that the maximum possible label length depends on the encoding used. Soobok Lee wrote: > They will find an utf8 label may have 168 octets, contrary to RFC1035. There is no contradiction. RFC 1035 says nothing about UTF-8 labels. The RFC 1035 limit of 63 octets per label applies to the universe of labels that RFC 1035 defined. IDNA defines some new labels outside that universe (each of which is equivalent to a label inside that universe, for backward compatibility). If you want to know the maximum possible length of these new labels that were created by IDNA, don't bother looking at RFC 1035, because it can't possibly tell you, because it doesn't even know about the new labels. Look at IDNA, which contains the complete definition of internationalized label. > When IDNA draft granted utf8 label use in application protocols, > it is natural that it should have also specified utf8 label length > restrictions. It did, by defining internationalized label as anything that ToASCII can be applied to without failing. From this you can easily conclude that internationalized labels, when encoded in UTF-8, can exceed 63 octets, but cannot exceed 63*4 octets. A tight upper bound is trickier to figure out, but you don't need it in practice. > So, 1024 or 768 bytes are good. But those utf8 FQDN cannot be put > into single UDP packet of DNS response/query. This will constrain > future DNS protocol update efforts around utf8 supports in wire > format. Today's long iDNs may be one of the obstacles in the way to > the effort. That will indeed be an issue that any UTF-8 DNS protocol update will need to address. AMC From owner-idn@ops.ietf.org Mon Oct 14 21:19:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06928 for ; Mon, 14 Oct 2002 21:19:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181GAQ-000Lo6-00 for idn-data@psg.com; Mon, 14 Oct 2002 18:06:38 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 181GAC-000Llv-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 18:06:24 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9F15cb11050; Tue, 15 Oct 2002 10:05:39 +0900 Message-ID: <3DAB6A4D.3050309@postel.co.kr> Date: Tue, 15 Oct 2002 10:07:25 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <200210142135.g9ELZco1066696@drugs.dv.isc.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.1 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: >> Most applications programmer have been reserving 256 bytes for any LDH >> >>FQDN buffer space . >> >> > > Most applications will use NS_MAXDNAME or MAXDNAME to store > a domain name today as that is enough to cover all the > potential expansions from wire to RFC 1034 presentation > format. Have a look at NS_MAXDNAME in . > Unless you have a really old OS it will be at least (250*4 > + 5) (minimum number of label that can appear in a full > length domain name is 4 labels + root, all 4 periods + > null). > If you have a linux (Redhat) box, "chdir /usr/include; grep MAXHOST */*". Then you will get the enclosed header lists. Many applications headers use 64/65/257 except for resolver/network libraries headers which use 1024/1025 for FQDN. If you have openssh 3.4p1 sources, you can find that it uses MAXHOSTNAMELEN (64) in some place in addition to 1025 in other places. of course, 64 is for a hostname label length. See rpc/* headers. asm/param.h:#define MAXHOSTNAMELEN 64 /* max length of hostname */ imap/mail.h:#define NETMAXHOST 65 imap/mail.h: char host[NETMAXHOST]; /* host name (may be canonicalized) */ imap/mail.h: char orighost[NETMAXHOST]; /* host name before canonicalization */ lwres/netdb.h:#undef NI_MAXHOST lwres/netdb.h:#define NI_MAXHOST 1025 mozilla/plresolv.h:#define PL_RESOLVE_MAXHOSTENTBUF 1024 protocols/timed.h: char tsp_name[MAXHOSTNAMELEN]; rpcsvc/rusers.h:#define RUSERS_MAXHOSTLEN 257 rpcsvc/rusers.x:const RUSERS_MAXHOSTLEN = 257; rpcsvc/rusers.x: string ut_host; /* host user logged on from */ rpc/types.h:#ifndef MAXHOSTNAMELEN rpc/types.h:#define MAXHOSTNAMELEN 64 w3c-libwww/wwwsys.h:#ifndef MAXHOSTNAMELEN w3c-libwww/wwwsys.h:#define MAXHOSTNAMELEN 64 /* Any better ideas? */ X11/Xos_r.h: char h_name[MAXHOSTNAMELEN]; > > As I said what you are talking about is NOT new. These > issues have existed for years. > yes, for presentation formats, it is not new. But for protocol elements, it is new. isn't it ? Soobok Lee From owner-idn@ops.ietf.org Mon Oct 14 22:35:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08718 for ; Mon, 14 Oct 2002 22:35:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181HMo-00004S-00 for idn-data@psg.com; Mon, 14 Oct 2002 19:23:30 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 181HMl-00003W-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 19:23:28 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g9F2NLo1068305; Tue, 15 Oct 2002 12:23:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200210150223.g9F2NLo1068305@drugs.dv.isc.org> To: Soobok Lee Cc: idn@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: [idn] length restrictions on IDN label In-reply-to: Your message of "Tue, 15 Oct 2002 10:07:25 +0900." <3DAB6A4D.3050309@postel.co.kr> Date: Tue, 15 Oct 2002 12:23:21 +1000 X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org wrote: > > >> Most applications programmer have been reserving 256 bytes for any LDH > >> > >>FQDN buffer space . > >> > >> > > > > Most applications will use NS_MAXDNAME or MAXDNAME to store > > a domain name today as that is enough to cover all the > > potential expansions from wire to RFC 1034 presentation > > format. Have a look at NS_MAXDNAME in . > > Unless you have a really old OS it will be at least (250*4 > > + 5) (minimum number of label that can appear in a full > > length domain name is 4 labels + root, all 4 periods + > > null). > > > If you have a linux (Redhat) box, "chdir /usr/include; grep MAXHOST */*". > Then you will get the enclosed header lists. > Many applications headers use 64/65/257 except for resolver/network > libraries headers which > use 1024/1025 for FQDN. If you have openssh 3.4p1 sources, you can find > that it uses MAXHOSTNAMELEN (64) in > some place in addition to 1025 in other places. of course, 64 is for a > hostname label length. > See rpc/* headers. Repeat after me: "HOSTNAME != DOMAIN NAME". Hostnames are a subset of domain names (ignoring hostnames that are larger that 253 and hence not supported by the DNS). If you are only dealing with hostnames then you should be rejecting domain names that are not legal hostnames. Anything reading unsanitized domainnames has to expect a strings bigger than 255 when converted to RFC 1034 presentation format. Some implementations of gethostbyaddr() do this sanitization for you. This was also one of the reasons IDNs are converted to and from ACSII. ToUnicode should be perform outside of gethostbyaddr(). Moving it inside of gethostbyaddr() is a API change. Mark > asm/param.h:#define MAXHOSTNAMELEN 64 /* max length of hostname */ > imap/mail.h:#define NETMAXHOST 65 > imap/mail.h: char host[NETMAXHOST]; /* host name (may be canonicalized) */ > imap/mail.h: char orighost[NETMAXHOST]; /* host name before > canonicalization */ > lwres/netdb.h:#undef NI_MAXHOST > lwres/netdb.h:#define NI_MAXHOST 1025 > mozilla/plresolv.h:#define PL_RESOLVE_MAXHOSTENTBUF 1024 > protocols/timed.h: char tsp_name[MAXHOSTNAMELEN]; > rpcsvc/rusers.h:#define RUSERS_MAXHOSTLEN 257 > rpcsvc/rusers.x:const RUSERS_MAXHOSTLEN = 257; > rpcsvc/rusers.x: string ut_host; /* host user logged > on from */ > rpc/types.h:#ifndef MAXHOSTNAMELEN > rpc/types.h:#define MAXHOSTNAMELEN 64 > w3c-libwww/wwwsys.h:#ifndef MAXHOSTNAMELEN > w3c-libwww/wwwsys.h:#define MAXHOSTNAMELEN 64 /* Any better ideas? */ > X11/Xos_r.h: char h_name[MAXHOSTNAMELEN]; > > > > > > As I said what you are talking about is NOT new. These > > issues have existed for years. > > > yes, for presentation formats, it is not new. But for protocol elements, > it is new. isn't it ? > > Soobok Lee > > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org From owner-idn@ops.ietf.org Mon Oct 14 23:24:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09550 for ; Mon, 14 Oct 2002 23:24:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181ICb-0002tn-00 for idn-data@psg.com; Mon, 14 Oct 2002 20:17:01 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 181ICZ-0002tb-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 20:16:59 -0700 Received: from postel.co.kr ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9F3GKb12934 for ; Tue, 15 Oct 2002 12:16:20 +0900 Message-ID: <3DAB88F1.7040206@postel.co.kr> Date: Tue, 15 Oct 2002 12:18:09 +0900 From: Soobok Lee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label References: <200210150223.g9F2NLo1068305@drugs.dv.isc.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > > Repeat after me: "HOSTNAME != DOMAIN NAME". > Everyone knows that here. :-) Applications , in general, deal with hostnames (smtp?), not abstact domain names (nslookup,dig?). It has been clear that i am saying in the context of appliations's hostname label buffer space problems. > > Hostnames are a subset of domain names (ignoring hostnames > that are larger that 253 and hence not supported by the > DNS). If you are only dealing with hostnames then you > should be rejecting domain names that are not legal hostnames. > Yes. > Anything reading unsanitized domainnames has to expect a > strings bigger than 255 when converted to RFC 1034 presentation > format. > You repeated this twice. And i had agreed. > > Some implementations of gethostbyaddr() do this sanitization > for you. This was also one of the reasons IDNs are converted > to and from ACSII. ToUnicode should be perform outside of > gethostbyaddr(). Moving it inside of gethostbyaddr() is a API > change. > True. Soobok Lee > > Mark > > > >>asm/param.h:#define MAXHOSTNAMELEN 64 /* max length of hostname */ >>imap/mail.h:#define NETMAXHOST 65 >>imap/mail.h: char host[NETMAXHOST]; /* host name (may be canonicalized) */ >>imap/mail.h: char orighost[NETMAXHOST]; /* host name before >>canonicalization */ >>lwres/netdb.h:#undef NI_MAXHOST >>lwres/netdb.h:#define NI_MAXHOST 1025 >>mozilla/plresolv.h:#define PL_RESOLVE_MAXHOSTENTBUF 1024 >>protocols/timed.h: char tsp_name[MAXHOSTNAMELEN]; >>rpcsvc/rusers.h:#define RUSERS_MAXHOSTLEN 257 >>rpcsvc/rusers.x:const RUSERS_MAXHOSTLEN = 257; >>rpcsvc/rusers.x: string ut_host; /* host user logged >>on from */ >>rpc/types.h:#ifndef MAXHOSTNAMELEN >>rpc/types.h:#define MAXHOSTNAMELEN 64 >>w3c-libwww/wwwsys.h:#ifndef MAXHOSTNAMELEN >>w3c-libwww/wwwsys.h:#define MAXHOSTNAMELEN 64 /* Any better ideas? */ >>X11/Xos_r.h: char h_name[MAXHOSTNAMELEN]; >> >> >> >> >>> As I said what you are talking about is NOT new. These >>> issues have existed for years. >>> >>> >>> >>yes, for presentation formats, it is not new. But for protocol elements, >>it is new. isn't it ? >> >>Soobok Lee >> >> >> >> >> >-- >Mark Andrews, Internet Software Consortium >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > From owner-idn@ops.ietf.org Tue Oct 15 01:55:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12327 for ; Tue, 15 Oct 2002 01:55:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181KUP-000As6-00 for idn-data@psg.com; Mon, 14 Oct 2002 22:43:33 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 181KUN-000Arr-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 22:43:32 -0700 Received: from [10.1.1.10] ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9F5gXb16153; Tue, 15 Oct 2002 14:42:33 +0900 Subject: Re: [idn] length restrictions on IDN label From: Soobok Lee To: Erik Nordmark Cc: James Seng , Paul Hoffman / IMC , idn@ops.ietf.org In-Reply-To: References: Content-Type: text/plain; charset=EUC-KR X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Oct 2002 14:44:22 +0900 Message-Id: <1034660665.31499.11.camel@backup.lsb.org> Mime-Version: 1.0 X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA12327 2002-10-14 23:29, Erik Nordmark : > > But perhaps IDNA should be more clear that there is a length issue for > such future work. For instance, would adding a sentence at the end of > this paragraph be helpful? > If a signaling system which makes negotiation possible between old and > new DNS clients and servers is standardized in the future, the encoding > of the query in the DNS protocol itself can be changed from ACE to > something else, such as UTF-8. The question whether or not this should > be used is, however, a separate problem and is not discussed in this > memo. > E.g. "Such work would have to take into account the length limit for IDNs > as specified in this document". > > It might also be useful to make the IDNA specification more clear about > the length limit and its implications somewhere in the document. > Strawman: > The length limit for internationalized labels is the limit > of at most 63 octets of output from ToASCII. The design > of the Punycode encoding is such that some sequences of up to 63 Unicode > code points result in ToASCII output of 63 or less octets, but > all possible Unicode strings of 64 code points result in ToASCII > output of 64 or more octets. > > Implementation Note: > Depending on the local encoding the software uses for > Unicode this can correspond to a lot more than 63 octets. > Similarely, the total length of a IDN expressed in the local > encoding can significantly exceed 255 octets. > > Erik > This clarification will really help. Thanks. Soobok Lee From owner-idn@ops.ietf.org Tue Oct 15 02:23:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21859 for ; Tue, 15 Oct 2002 02:23:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181Ktb-000CNR-00 for idn-data@psg.com; Mon, 14 Oct 2002 23:09:35 -0700 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 181KtZ-000CNC-00 for idn@ops.ietf.org; Mon, 14 Oct 2002 23:09:33 -0700 Received: from [10.1.1.10] ([218.154.6.96]) by postel3.postel.co.kr (8.11.0/8.11.0) with ESMTP id g9F68rb16882 for ; Tue, 15 Oct 2002 15:08:53 +0900 Subject: Re: [idn] length restrictions on IDN label From: Soobok Lee To: IETF idn working group In-Reply-To: <20021014222216.GB15892@nicemice.net> References: <3DAA3486.1050003@postel.co.kr> <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> <20021014055250.GD2930@nicemice.net> <3DAA6455.3010302@postel.co.kr> <20021014075502.GE2930@nicemice.net> <3DAA7F93.2080100@postel.co.kr> <20021014222216.GB15892@nicemice.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 15 Oct 2002 15:10:45 +0900 Message-Id: <1034662245.31499.27.camel@backup.lsb.org> Mime-Version: 1.0 X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 2002-10-15 07:22, Adam M. Costello : > Erik Nordmark wrote: > > > > an internationalized label can represent at most 63 code points, > > > whether it's ACE or not. A given encoding uses a bounded number of > > > octets per code point, so you can allocate your buffers based on > > > that. > > > > 63 code points is presumably a conservative number. Given the 4 octet > > ACE prefix you can only fit a 59 octets worth of punycode output > > per label, hence presumably 59 code points is a tighter limit for > > non-ASCII internationalized labels while 63 code points is the limit > > for ASCII labels. > > True, but which limit you care about depends on the encoding. For > example, if you're using UTF-32, then a regular ASCII label can have 63 > code points each occupying 4 octets. YES. > > Soobok Lee wrote: > > > IDNA section 6.1 goes further than that by allowing _protocols_ to use > > non-ACE labels which are not presentation forms nor textual labels, > > but protocol elements. What if future ESMTP allows utf8 encodings in > > RCPT: headers ? > > Then applications that implement future ESMTP will need to be prepared > for UTF-8 labels to contain more than 63 octets. This is not a My focus was on whether the "UTF-8 labels in ESMTP sessions" are legitimate internationalized hostnames (labels) or not at the future and at the present time, since IDNA section 6.1 allows utf8 encodings of transmitted labels. Does this section seems to propose changes in hostname rules ? But, you and other authors denied that. Authors's real intent alway wins over other's interpretations (mine) in the draft. ;-) Don't you think you authors be more clear about that section? > problem, because any application that can even think about using > non-ASCII labels is aware of IDNA, and therefore knows the definition of > internationalized label, and therefore knows that the maximum possible > label length depends on the encoding used. But label length restrictions are not added per application prptocol basis, rather they should be added at lower level like the DNS (and so IDNA ) as has been done at RFC1035. How do you think about that? > > Soobok Lee wrote: > > > They will find an utf8 label may have 168 octets, contrary to RFC1035. > > There is no contradiction. RFC 1035 says nothing about UTF-8 labels. > The RFC 1035 limit of 63 octets per label applies to the universe of > labels that RFC 1035 defined. IDNA defines some new labels outside that > universe (each of which is equivalent to a label inside that universe, > for backward compatibility). If you want to know the maximum possible > length of these new labels that were created by IDNA, don't bother > looking at RFC 1035, because it can't possibly tell you, because it > doesn't even know about the new labels. Look at IDNA, which contains > the complete definition of internationalized label. See My first above paragraph. > > > When IDNA draft granted utf8 label use in application protocols, > > it is natural that it should have also specified utf8 label length > > restrictions. > > It did, by defining internationalized label as anything that ToASCII > can be applied to without failing. From this you can easily conclude > that internationalized labels, when encoded in UTF-8, can exceed 63 > octets, but cannot exceed 63*4 octets. A tight upper bound is trickier > to figure out, but you don't need it in practice. I prefer Erik's suggestion for explicit clarifications, rather than implicit ones. > > > So, 1024 or 768 bytes are good. But those utf8 FQDN cannot be put > > into single UDP packet of DNS response/query. This will constrain > > future DNS protocol update efforts around utf8 supports in wire > > format. Today's long iDNs may be one of the obstacles in the way to > > the effort. > > That will indeed be an issue that any UTF-8 DNS protocol update will > need to address. Sure. Regards, Soobok Lee From owner-idn@ops.ietf.org Tue Oct 15 08:45:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29221 for ; Tue, 15 Oct 2002 08:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181Qqz-00019Z-00 for idn-data@psg.com; Tue, 15 Oct 2002 05:31:17 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 181Qqy-00019M-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 05:31:16 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06729; Tue, 15 Oct 2002 06:31:14 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9FCVDQ29404; Tue, 15 Oct 2002 14:31:13 +0200 (MEST) Date: Tue, 15 Oct 2002 14:28:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] length restrictions on IDN label To: Dave Crocker Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <39262716546.20021015005933@svpal.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > If this limit is a new and independent from the underlying "native" DNS, > what is the reason for it? If it is not independent, why duplicate it? It isn't independent since the limit derives from the label length limit in the DNS protocol, but the limit is also a function of the amount of compression that punycode performs. The fact that punycode will never generate a string with less number of code points than the number of code points in the input is far from obvious, hence it makes sense in my mind to state this limit. Erik From owner-idn@ops.ietf.org Tue Oct 15 08:47:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29304 for ; Tue, 15 Oct 2002 08:47:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181R1m-0001Tx-00 for idn-data@psg.com; Tue, 15 Oct 2002 05:42:26 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 181R1j-0001Ta-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 05:42:23 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12552 for ; Tue, 15 Oct 2002 06:42:22 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9FCgLQ00115; Tue, 15 Oct 2002 14:42:21 +0200 (MEST) Date: Tue, 15 Oct 2002 14:39:31 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] IDNA problem statement To: idn@ops.ietf.org Cc: erik.nordmark@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Back in May when I sent AD review comments on the IDNA specification I raised a desire to make the problem IDNA claims to solve more clear and some relatively recent discussion on the IDN mailing list has re-emphasized the need for this. I think the text below is not very controversial in that it tries to summarize what IDNA does and what it does not. If you see a particular problem with the text please suggest alternative text. The intent is to add this text to draft-ietf-idn-idna in section 1. Erik 1.1 Problem Statement The IDNA specification solves the problem of extending the repertoire of characters that can be used in domain names to include the Unicode repertoire. IDNA does not extend the service offered by DNS to the applications. Instead, the applications (and, by implication, the users) continue to see an exact-match lookup service. Either there is a single exactly-matching name or there is no match. This model has served the existing applications well, but it requires that users know the exact spelling of the domain names that the users type into applications such as web browsers and mail user agents. The introduction of the larger repertoire of characters potentially makes the set of misspellings larger, especially given that in some cases the same appearance, for example on a business card, might visually match several Unicode code points or several sequences of code points. IDNA allows the graceful introduction of IDNs not only by avoiding upgrades to existing DNS infrastructure (servers, caches, stub resolvers), but also by allowing some rudimentary use of IDNs in applications by using the ASCII representation of the non-ASCII name labels. While such names are very user-unfriendly to read and type, and hence are not suitable for user input, they allow (for instance) replying to email and clicking on URLs even though the domain name displayed is incomprehensible to the user. In order to allow user-friendly input and output of the IDNs, the applications need to be modified to conform to this specification. IDNA uses the Unicode character repertoire which avoids the significant delays that that would be inherent in waiting for a different and specific character set be defined for IDN purposes by some other standards developing organization. 1.2 Limitations of IDNA The IDNA protocol does not solve all linguistic issues with users inputting names in different scripts. Many important language-based and script-based mappings are not covered in IDNA and need to be handled outside the protocol. For example, names that are entered in a mix of traditional and simplified Chinese characters will not be mapped to a single canonical name. Another example is Scandinavian names that are entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE). An example of an important issue that is not considered in detail in IDNA is how to provide a high probability that a user who is entering a domain name based on visual information (such as from a business card or billboard) or aural information (such as from a telephone or radio) would correctly enter the IDN. This a complex issue relating to languages, input methods on computers, and so on. Furthermore, the kind of matching and searching necessary for a high probability of success would not fit the role of the DNS and its exact matching function. --- From owner-idn@ops.ietf.org Tue Oct 15 09:18:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00594 for ; Tue, 15 Oct 2002 09:18:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181RWE-0002Jg-00 for idn-data@psg.com; Tue, 15 Oct 2002 06:13:54 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 181RWA-0002JP-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 06:13:51 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id g9FDDlFu027572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Oct 2002 15:13:48 +0200 To: Erik Nordmark Cc: idn@ops.ietf.org Subject: [idn] Re: IDNA problem statement References: X-Hashcash: 0:021015:Erik.Nordmark@sun.com:b24b3b9d7da13f03 X-Hashcash: 0:021015:idn@ops.ietf.org:b66bceace4ef12e4 From: Simon Josefsson Date: Tue, 15 Oct 2002 15:13:45 +0200 In-Reply-To: (Erik Nordmark's message of "Tue, 15 Oct 2002 14:39:31 +0200 (CEST)") 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=-10.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik Nordmark writes: > The IDNA specification solves the problem of extending the repertoire > of characters that can be used in domain names to include the Unicode > repertoire. Your text is very useful. I have only one minor comment on that first sentence -- it might be good to make it clear that not the entire Unicode repertoire is included, but a Unicode repertoire with some restrictions. Having this in mind early on makes it easier to comprehend what is going on later when some strings trigger errors. "... to include the Unicode repertoire with some restrictions." From owner-idn@ops.ietf.org Tue Oct 15 10:44:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03778 for ; Tue, 15 Oct 2002 10:44:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181Sh8-0003wz-00 for idn-data@psg.com; Tue, 15 Oct 2002 07:29:14 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by psg.com with esmtp (Exim 3.36 #2) id 181Sh6-0003wn-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 07:29:12 -0700 Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA15021; Tue, 15 Oct 2002 07:29:10 -0700 Date: Tue, 15 Oct 2002 07:16:50 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.61) UNREG / CD5BF9353B3B7091 Reply-To: Dave Crocker Organization: Silicon Valley / Public Access Link X-Priority: 3 (Normal) Message-ID: <190285353787.20021015071650@svpal.org> To: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.9 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NOSPAM_INC,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_THEBAT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Tuesday, October 15, 2002, 5:28:23 AM, you wrote: EN> It isn't independent since the limit derives from the label length limit ... EN> The fact that punycode will never generate a string with less number of EN> code points than the number of code points in the input is far from EN> obvious, hence it makes sense in my mind to state this limit. makes sense. thanks. /d ----- Dave From owner-idn@ops.ietf.org Tue Oct 15 11:01:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04224 for ; Tue, 15 Oct 2002 11:01:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181SzK-0004PX-00 for idn-data@psg.com; Tue, 15 Oct 2002 07:48:02 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #2) id 181SzJ-0004PF-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 07:48:01 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 620C74B3E; Tue, 15 Oct 2002 16:48:06 +0200 (CEST) Date: Tue, 15 Oct 2002 16:48:06 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Simon Josefsson Cc: Erik Nordmark , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA problem statement Message-ID: <20021015144806.GB3556@rap.rap.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, Oct 15, 2002 at 03:13:45PM +0200, Simon Josefsson wrote: > Erik Nordmark writes: > > > The IDNA specification solves the problem of extending the repertoire > > of characters that can be used in domain names to include the Unicode > > repertoire. > > Your text is very useful. I have only one minor comment on that first > sentence -- it might be good to make it clear that not the entire > Unicode repertoire is included, but a Unicode repertoire with some > restrictions. Having this in mind early on makes it easier to > comprehend what is going on later when some strings trigger errors. I would still like it to be called the ISO 10646 repertoire. Kind regards Keld Simonsen From owner-idn@ops.ietf.org Tue Oct 15 12:03:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05984 for ; Tue, 15 Oct 2002 12:03:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181U27-0005zy-00 for idn-data@psg.com; Tue, 15 Oct 2002 08:54:59 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 181U25-0005zl-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 08:54:57 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08060; Tue, 15 Oct 2002 09:54:48 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9FFsdQ17642; Tue, 15 Oct 2002 17:54:40 +0200 (MEST) Date: Tue, 15 Oct 2002 17:51:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: IDNA problem statement To: Simon Josefsson Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > Your text is very useful. I have only one minor comment on that first > sentence -- it might be good to make it clear that not the entire > Unicode repertoire is included, but a Unicode repertoire with some > restrictions. Having this in mind early on makes it easier to > comprehend what is going on later when some strings trigger errors. > > "... to include the Unicode repertoire with some restrictions." While I agree with the intent, I wonder if the text should be more specific that just saying "some". But it is hard to do this without having a forward reference to either sections in the document, or referring to nameprep. Ideas? Erik From owner-idn@ops.ietf.org Tue Oct 15 12:12:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06227 for ; Tue, 15 Oct 2002 12:12:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181UGc-0006S0-00 for idn-data@psg.com; Tue, 15 Oct 2002 09:09:58 -0700 Received: from crow.verisign.com ([216.168.237.103]) by psg.com with esmtp (Exim 3.36 #2) id 181UGb-0006Ro-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 09:09:57 -0700 Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA25675; Tue, 15 Oct 2002 12:09:55 -0400 (EDT) Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <4RC6084P>; Tue, 15 Oct 2002 12:09:55 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Erik Nordmark'" Cc: idn@ops.ietf.org Subject: RE: [idn] Re: IDNA problem statement Date: Tue, 15 Oct 2002 12:09:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-4.7 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > > Your text is very useful. I have only one minor comment on > that first > > sentence -- it might be good to make it clear that not the entire > > Unicode repertoire is included, but a Unicode repertoire with some > > restrictions. Having this in mind early on makes it easier to > > comprehend what is going on later when some strings trigger errors. > > > > "... to include the Unicode repertoire with some restrictions." > > While I agree with the intent, I wonder if the text should > be more specific that just saying "some". > But it is hard to do this without having a forward reference > to either sections in the document, or referring to nameprep. > > Ideas? A reference to nameprep would work: "... to include the Unicode repertoire with restrictions described in [NAMEPREP]." -Scott- From owner-idn@ops.ietf.org Tue Oct 15 12:14:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06253 for ; Tue, 15 Oct 2002 12:14:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181UGk-0006TP-00 for idn-data@psg.com; Tue, 15 Oct 2002 09:10:06 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 181UGj-0006Ra-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 09:10:05 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23342; Tue, 15 Oct 2002 09:09:33 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9FG9IQ18919; Tue, 15 Oct 2002 18:09:19 +0200 (MEST) Date: Tue, 15 Oct 2002 18:06:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: IDNA problem statement To: =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= Cc: Simon Josefsson , Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <20021015144806.GB3556@rap.rap.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > I would still like it to be called the ISO 10646 repertoire. Doing that change to this added text would be very odd given that that the rest of the document has no mention of ISO 10646. Thus I think consistency is the overriding concern here. Erik From owner-idn@ops.ietf.org Tue Oct 15 12:42:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07163 for ; Tue, 15 Oct 2002 12:42:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181Ugs-0007KD-00 for idn-data@psg.com; Tue, 15 Oct 2002 09:37:06 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #2) id 181Ugq-0007Jx-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 09:37:05 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 1121E4B3F; Tue, 15 Oct 2002 18:37:11 +0200 (CEST) Date: Tue, 15 Oct 2002 18:37:11 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Erik Nordmark Cc: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen , Simon Josefsson , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA problem statement Message-ID: <20021015163710.GB4021@rap.rap.dk> References: <20021015144806.GB3556@rap.rap.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk On Tue, Oct 15, 2002 at 06:06:26PM +0200, Erik Nordmark wrote: > > I would still like it to be called the ISO 10646 repertoire. > > Doing that change to this added text would be very odd given > that that the rest of the document has no mention of ISO 10646. > Thus I think consistency is the overriding concern here. Is that not a major change from IETF policy? We should mention ISO standards when they are applicable. Kind regards keld From owner-idn@ops.ietf.org Tue Oct 15 12:46:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07270 for ; Tue, 15 Oct 2002 12:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181UhQ-0007Mr-00 for idn-data@psg.com; Tue, 15 Oct 2002 09:37:40 -0700 Date: Tue, 15 Oct 2002 00:59:33 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.61) UNREG / CD5BF9353B3B7091 Reply-To: Dave Crocker Organization: Silicon Valley / Public Access Link X-Priority: 3 (Normal) Message-ID: <39262716546.20021015005933@svpal.org> To: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] length restrictions on IDN label Sender: owner-idn@ops.ietf.org Precedence: bulk Erik, Monday, October 14, 2002, 7:29:11 AM, you wrote: EN> It might also be useful to make the IDNA specification more clear about EN> the length limit and its implications somewhere in the document. EN> Strawman: The length limit for internationalized labels is the EN> limit of at most 63 octets of output from ToASCII. The design EN> of the Punycode encoding is such that some sequences of up to 63 Unicode EN> code points result in ToASCII output of 63 or less octets, but EN> all possible Unicode strings of 64 code points result in ToASCII EN> output of 64 or more octets. If this limit is a new and independent from the underlying "native" DNS, what is the reason for it? If it is not independent, why duplicate it? d/ From owner-idn@ops.ietf.org Tue Oct 15 15:42:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13293 for ; Tue, 15 Oct 2002 15:42:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181X6e-000BeC-00 for idn-data@psg.com; Tue, 15 Oct 2002 12:11:52 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #2) id 181X6Q-000Bdv-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 12:11:39 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 181X52-000MQc-00; Tue, 15 Oct 2002 19:10:12 +0000 Date: Tue, 15 Oct 2002 15:10:11 -0400 From: John C Klensin To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= , Erik Nordmark cc: Simon Josefsson , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA problem statement Message-ID: <78865393.1034694611@localhost> In-Reply-To: <20021015163710.GB4021@rap.rap.dk> References: <20021015144806.GB3556@rap.rap.dk> <20021015163710.GB4021@rap.rap.dk> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA13293 --On Tuesday, 15 October, 2002 18:37 +0200 Keld Jrn Simonsen wrote: > On Tue, Oct 15, 2002 at 06:06:26PM +0200, Erik Nordmark wrote: >> > I would still like it to be called the ISO 10646 repertoire. >> >> Doing that change to this added text would be very odd given >> that that the rest of the document has no mention of ISO >> 10646. Thus I think consistency is the overriding concern >> here. > > Is that not a major change from IETF policy? We should mention > ISO standards when they are applicable. Keld, this is an old argument in the IDN WG, and I think ISO basically decided to lose it a year or two ago. While, I, too, prefer to reference ISO standards where possible, the situation here is that the IDN effort needed both a character and code point repertoire and a collection of norms about how those code points were to be used, compared, etc. My preference, and I think that of the IETF generally, would have been to reference ISO Standards for all of this but, as you know, the complementary "usage" standards did not follow the code point ones. Even where TRs exist, ISO generally doesn't like having its TRs referenced normatively. We approached ISO about the problem of the missing standards at the JTC1 level and stressed that, if they couldn't respond usefully and fairly quickly, we would have to rely on UTC. We didn't get a response for a long time, and then, in my opinion, were brushed off. And you are all-too-aware what happened when we tried to work something with SC22... from my perspective, not only did we not get active cooperation, we were deliberately insulted by their "agreeing" to something we had previously told them (formally and informally) we would not accept. While this was going on, the Unicode folks were actively working with the WG, inviting IETF participation in their meetings and in liaisons with on their Board, and trying to be responsive to our needs in their ongoing work. I think they are entitled to recognition for those efforts, including having their preferred name for the CCS and associated materials used. And, if JTC1 wants to isolate themselves from the Internet in this area, and to hint that they are doing so because the IETF is just not important enough to deal with on a peer basis, I don't see any reason to respond by advertising the relevant ISO Standard in more than a footnote. Just my opinion, of course. But, if my analysis is correct or rings true, the problem you are addressing needs to be raised within JTC1, not in this working group or over these documents. john From owner-idn@ops.ietf.org Tue Oct 15 16:28:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14887 for ; Tue, 15 Oct 2002 16:28:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181Y2Y-000DcE-00 for idn-data@psg.com; Tue, 15 Oct 2002 13:11:42 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 181Y2X-000Dby-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 13:11:41 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9FKBaW24282; Tue, 15 Oct 2002 13:11:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> 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: Tue, 15 Oct 2002 13:11:33 -0700 To: "Hollenbeck, Scott" , "'Erik Nordmark'" From: Paul Hoffman / IMC Subject: RE: [idn] Re: IDNA problem statement Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-12.2 required=5.0 tests=HABEAS_SWE,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:09 PM -0400 10/15/02, Hollenbeck, Scott wrote: > > > Your text is very useful. I have only one minor comment on >> that first >> > sentence -- it might be good to make it clear that not the entire >> > Unicode repertoire is included, but a Unicode repertoire with some >> > restrictions. Having this in mind early on makes it easier to >> > comprehend what is going on later when some strings trigger errors. >> > >> > "... to include the Unicode repertoire with some restrictions." >> >> While I agree with the intent, I wonder if the text should >> be more specific that just saying "some". >> But it is hard to do this without having a forward reference >> to either sections in the document, or referring to nameprep. >> >> Ideas? > >A reference to nameprep would work: > >"... to include the Unicode repertoire with restrictions described in >[NAMEPREP]." > Although this is true, it feels like it is too early in the IDNA document to say this. Having the problem statement contain no references makes it much easier to read. "with some restrictions" tells the reader enough to know what Simon wanted, which is that it isn't the entire repertoire. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Oct 15 17:42:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16689 for ; Tue, 15 Oct 2002 17:42:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181ZKp-000Fxf-00 for idn-data@psg.com; Tue, 15 Oct 2002 14:34:39 -0700 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 181ZKm-000FxS-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 14:34:36 -0700 Received: from lns11v-12-126.w.club-internet.fr ([213.44.171.126] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 181ZKY-0003eQ-00; Tue, 15 Oct 2002 14:34:23 -0700 Message-Id: <5.1.0.14.0.20021015233350.02c39080@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Oct 2002 23:40:33 +0200 To: "'Erik Nordmark'" From: "JFC (Jefsey) Morfin" Subject: RE: [idn] Re: IDNA problem statement Cc: idn@ops.ietf.org In-Reply-To: References: < <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-26E24232; boundary="=======58CC2084=======" 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=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======58CC2084======= Content-Type: text/plain; x-avg-checked=avg-ok-26E24232; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 22:11 15/10/02, Paul Hoffman / IMC wrote: >>> > "... to include the Unicode repertoire with some restrictions." >>> >>> While I agree with the intent, I wonder if the text should >>> be more specific that just saying "some". >>> But it is hard to do this without having a forward reference >>> to either sections in the document, or referring to nameprep. >>> >>> Ideas? >> >>A reference to nameprep would work: >> >>"... to include the Unicode repertoire with restrictions described in >>[NAMEPREP]." > >Although this is true, it feels like it is too early in the IDNA document >to say this. Having the problem statement contain no references makes it >much easier to read. "with some restrictions" tells the reader enough to >know what Simon wanted, which is that it isn't the entire repertoire. My Frenglish? "some restriction" sounds unprecise to me. What about "limited restrictions" which implies the author did his best to limit the size/number of restrictions (thefored well defined?)jfc --=======58CC2084=======-- From owner-idn@ops.ietf.org Tue Oct 15 20:07:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19574 for ; Tue, 15 Oct 2002 20:07:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181bTk-000KNu-00 for idn-data@psg.com; Tue, 15 Oct 2002 16:52:00 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 181bTg-000KNg-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 16:51:56 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 181bTf-0001Ox-00 for ; Tue, 15 Oct 2002 16:51:55 -0700 Date: Tue, 15 Oct 2002 23:51:54 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] length restrictions on IDN label Message-ID: <20021015235154.GB2520@nicemice.net> Reply-To: IETF idn working group References: <02e601c27334$24e55c60$ad00a8c0@JSENGTOSHIBA> <3DAA4434.5050707@postel.co.kr> <20021014044758.GC2930@nicemice.net> <3DAA5443.7000404@postel.co.kr> <20021014055250.GD2930@nicemice.net> <3DAA6455.3010302@postel.co.kr> <20021014075502.GE2930@nicemice.net> <3DAA7F93.2080100@postel.co.kr> <20021014222216.GB15892@nicemice.net> <1034662245.31499.27.camel@backup.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1034662245.31499.27.camel@backup.lsb.org> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee wrote: > My focus was on whether the "UTF-8 labels in ESMTP sessions" are > legitimate internationalized hostnames (labels) or not at the future > and at the present time, since IDNA section 6.1 allows utf8 encodings > of transmitted labels. Does this section seems to propose changes in > hostname rules ? Nothing in section 6.1 reduces the requirement of section 3 item 2: Whenever a domain name is put into an IDN-unaware domain name slot, it MUST contain only ASCII characters. At the present time, all domain name slots in ESMTP are IDN-unaware (because they predate IDNA). Therefore, all domain names put into those slots must contain only ASCII characters. Section 6.1 is not aimed primarily at this situation, but it does have implications for this situation. If ESMTP were to use EBCDIC or UTF-16 for some slots (which isn't very likely), then domain names being put into those slots would contain only ASCII characters (that is, characters from the ASCII repertoire) as required by section 3 item 2, but would need to be encoded using EBCDIC or UTF-16 rather than the ASCII encoding. (The name ASCII is old, from the days when people weren't so careful to distinguish between repertoires and encodings). If a future revision/extension of ESMTP defines some IDN-aware slots, then the implications of section 6.1 become more interesting. If those slots use, say, UTF-8, then IDNs containing non-ASCII characters could be put into those slots, and they would need to be encoded using UTF-8. > But label length restrictions are not added per application protocol > basis, rather they should be added at lower level like the DNS (and so > IDNA ) as has been done at RFC1035. How do you think about that? RFC 1035 defined the length restriction in terms of the form of the label that is used in DNS protocol messages. That form must be no more than 63 octets. In addition to the DNS protocol, RFC 1035 also defined the master file format. The domain names in master files are protocol elements, because the master file format is explicitly intended to be machine readable. Labels in master files can be up to 63*4 octets long. This fact is never mentioned in RFC 1035, it is left as an exercise for the reader. In a completely analogous fashion, IDNA defines the length restriction of internationalized labels in terms of the ASCII form. That form must contain no more than 63 code points. The length of labels in other forms is currently left as an exercise for the reader, though perhaps we will want to add a hint that there can never be more than 63 Unicode code points in an internationalized label. IDNA cannot specify the length restriction in terms of octets, because that depends on the encoding used, and IDNA does not favor any encoding over any other encoding. AMC From owner-idn@ops.ietf.org Tue Oct 15 20:16:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19655 for ; Tue, 15 Oct 2002 20:16:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181bjo-000Kt0-00 for idn-data@psg.com; Tue, 15 Oct 2002 17:08:36 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 181bjl-000Krb-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 17:08:33 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 181bjk-0001RX-00 for ; Tue, 15 Oct 2002 17:08:32 -0700 Date: Wed, 16 Oct 2002 00:08:32 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: IDNA problem statement Message-ID: <20021016000832.GC2520@nicemice.net> Reply-To: IETF idn working group References: <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> <5.1.0.14.0.20021015233350.02c39080@mail.jefsey.com> <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021015233350.02c39080@mail.jefsey.com> <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik Nordmark wrote: > > "... to include the Unicode repertoire with some restrictions." > > While I agree with the intent, I wonder if the text should be more > specific that just saying "some". This is just the introduction, so it's not expected to fill in all the details. I think the reader will naturally assume that the specific restrictions will be given later in the document. "JFC (Jefsey) Morfin" wrote: > "some restriction" sounds unprecise to me. Because it is. For the purposes of the problem statement, the essential fact is that the repertoire is expanded from a small one to a large one. Mentioning Unicode is helpful because many readers will immediately recall the two primary characteristics of Unicode (it's big, and it aims to include all characters from all other repertoires). But additional details regarding how much of Unicode is or is not allowed would just distract from the point of this section, which is to describe the problem being addressed. In fact, I'd even put "with some restrictions" in parentheses, to make it clearer that the restrictions are unimportant to understanding the problem statement. AMC From owner-idn@ops.ietf.org Tue Oct 15 21:23:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20470 for ; Tue, 15 Oct 2002 21:23:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181cjk-000Mxs-00 for idn-data@psg.com; Tue, 15 Oct 2002 18:12:36 -0700 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #2) id 181cjh-000MxL-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 18:12:34 -0700 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 15 Oct 2002 18:12:00 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Oct 2002 18:12:00 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 15 Oct 2002 18:11:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [idn] Re: IDNA problem statement Date: Tue, 15 Oct 2002 18:11:58 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F06C6421B@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: [idn] Re: IDNA problem statement Thread-Index: AcJ0gRMH6cVM2ukoRPK3ui7ClMEGBgALVphw From: "Michel Suignard" To: "John C Klensin" , =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= , "Erik Nordmark" Cc: "Simon Josefsson" , X-OriginalArrivalTime: 16 Oct 2002 01:11:59.0276 (UTC) FILETIME=[06D9B6C0:01C274B1] X-Spam-Status: No, hits=-5.1 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA20470 See my feedback below concerning 10646 and Unicode Michel Suignard > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com] > --On Tuesday, 15 October, 2002 18:37 +0200 Keld Jrn Simonsen > wrote: > > > On Tue, Oct 15, 2002 at 06:06:26PM +0200, Erik Nordmark wrote: > >> > I would still like it to be called the ISO 10646 repertoire. > >> > >> Doing that change to this added text would be very odd given that > >> that the rest of the document has no mention of ISO 10646. Thus I > >> think consistency is the overriding concern here. > > > > Is that not a major change from IETF policy? We should mention ISO > > standards when they are applicable. > > Keld, this is an old argument in the IDN WG, and I think ISO > basically decided to lose it a year or two ago. While, I, > too, prefer to reference ISO standards where possible, the > situation here is that the IDN effort needed both a character > and code point repertoire and a collection of norms about how > those code points were to be used, compared, etc. My > preference, and I think that of the IETF generally, would > have been to reference ISO Standards for all of this but, as > you know, the complementary "usage" standards did not follow > the code point ones. Even where TRs exist, ISO generally > doesn't like having its TRs referenced normatively. > > We approached ISO about the problem of the missing standards > at the JTC1 level and stressed that, if they couldn't respond > usefully and fairly quickly, we would have to rely on UTC. > We didn't get a response for a long time, and then, in my > opinion, were brushed off. And you are all-too-aware what > happened when we tried to work something with SC22... from my > perspective, not only did we not get active cooperation, we > were deliberately insulted by their "agreeing" to something > we had previously told them (formally and informally) we > would not accept. While this was going on, the Unicode folks > were actively working with the WG, inviting IETF > participation in their meetings and in liaisons with on their > Board, and trying to be responsive to our needs in their > ongoing work. I think they are entitled to recognition for > those efforts, including having their preferred name for the > CCS and associated materials used. And, if JTC1 wants to > isolate themselves from the Internet in this area, and to > hint that they are doing so because the IETF is just not > important enough to deal with on a peer basis, I don't see > any reason to respond by advertising the relevant ISO > Standard in more than a footnote. The ISO working group in charge of ISO 10646 (SC2/WG2) is working fairly harmoniously with the Unicode Consortium and in fact as time goes more and more normative references to Unicode based 'usage standards' have been added to ISO 10646. The 1st amendment to 10646-1 2000 references the Unicode bidi algorithm and the 2nd amendment (being balloted now) proposes to reference the Unicode normalization technical report. And many more informative references already exists. Instead of duplicating efforts, most WG2 experts have agreed long time ago to use the work already done by the Unicode consortium. Basically I don't see the situation as dire as portraited here. In this precise matter, at least one leg of ISO is working well with a consortium. And I would also favor keeping the Unicode references in the IDNA document, if not for other reason than to keep the IDNA document stable. And the combination of work done by the UTC and the SC2/WG2 is well serving the IETF community. > > Just my opinion, of course. But, if my analysis is correct > or rings true, the problem you are addressing needs to be > raised within JTC1, not in this working group or over these documents. > > john > > > From owner-idn@ops.ietf.org Tue Oct 15 21:59:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21166 for ; Tue, 15 Oct 2002 21:59:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181d71-000NPr-00 for idn-data@psg.com; Tue, 15 Oct 2002 18:36:39 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 181d6z-000NPJ-00 for idn@ops.ietf.org; Tue, 15 Oct 2002 18:36:38 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id g9G1aLFu003359 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Oct 2002 03:36:22 +0200 To: "JFC (Jefsey) Morfin" Cc: "'Erik Nordmark'" , idn@ops.ietf.org Subject: [idn] Re: IDNA problem statement References: < <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> <3CD14E451751BD42BA48AAA50B07BAD603370056@vsvapostal3.prod.netsol.com> <5.1.0.14.0.20021015233350.02c39080@mail.jefsey.com> X-Hashcash: 0:021016:jefsey@jefsey.com:84d206d884c7ad3b X-Hashcash: 0:021016:Erik.Nordmark@sun.com:b6de48bdb0949aae X-Hashcash: 0:021016:idn@ops.ietf.org:b9248c3f227856dc From: Simon Josefsson Date: Wed, 16 Oct 2002 03:36:19 +0200 In-Reply-To: <5.1.0.14.0.20021015233350.02c39080@mail.jefsey.com> ("JFC's message of "Tue, 15 Oct 2002 23:40:33 +0200") 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=-7.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk "JFC (Jefsey) Morfin" writes: > At 22:11 15/10/02, Paul Hoffman / IMC wrote: >>>> > "... to include the Unicode repertoire with some restrictions." >>>> >>>> While I agree with the intent, I wonder if the text should >>>> be more specific that just saying "some". >>>> But it is hard to do this without having a forward reference >>>> to either sections in the document, or referring to nameprep. >>>> >>>> Ideas? >>> >>>A reference to nameprep would work: >>> >>>"... to include the Unicode repertoire with restrictions described in >>>[NAMEPREP]." >> >> Although this is true, it feels like it is too early in the IDNA >> document to say this. Having the problem statement contain no >> references makes it much easier to read. "with some restrictions" >> tells the reader enough to know what Simon wanted, which is that it >> isn't the entire repertoire. > > My Frenglish? "some restriction" sounds unprecise to me. > What about "limited restrictions" which implies the author did his > best to limit the size/number of restrictions (thefored well > defined?)jfc Perhaps the text can be improved, not by clarifying how large the restriction is, but rather with the reason why there is a restriction. "... to include the Unicode repertoire restricted in a way that is intended to reduce ambiguities when strings are compared." I'm not entirely happy with the result... Btw, I don't like the phrases (in nameprep and stringprep) that says IDN related standards provided the "highest chance of getting content correct" when entering strings (what does that MEAN? Getting content correct? Maybe the RFC editor should implement the algorithm). It seems clear that it only reduces some limited and character-by- character specific concerns. The text is confusing after reading the following paragraph in your introduction, which I think describes the situation more accurately: ,---- | An example of an important issue that is not considered in | detail in IDNA is how to provide a high probability that a user who | is entering a domain name based on visual information (such as from a | business card or billboard) or aural information (such as from a | telephone or radio) would correctly enter the IDN. | This a complex issue relating to languages, input methods on | computers, and so on. Furthermore, the kind of matching and | searching necessary for a high probability of success would not fit | the role of the DNS and its exact matching function. `---- I don't dislike it strong enough to provide better text though... From owner-idn@ops.ietf.org Wed Oct 16 08:15:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26446 for ; Wed, 16 Oct 2002 08:15:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181mwZ-0007MK-00 for idn-data@psg.com; Wed, 16 Oct 2002 05:06:31 -0700 Received: from 213.237.47.228.adsl.vbr.worldonline.dk ([213.237.47.228] helo=rap.rap.dk) by psg.com with esmtp (Exim 3.36 #2) id 181mwX-0007M3-00 for idn@ops.ietf.org; Wed, 16 Oct 2002 05:06:29 -0700 Received: by rap.rap.dk (Postfix, from userid 500) id 6C96A4B46; Wed, 16 Oct 2002 14:06:03 +0200 (CEST) Date: Wed, 16 Oct 2002 14:06:03 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: John C Klensin Cc: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen , Erik Nordmark , Simon Josefsson , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA problem statement Message-ID: <20021016120603.GA10829@rap.rap.dk> References: <20021015144806.GB3556@rap.rap.dk> <20021015163710.GB4021@rap.rap.dk> <78865393.1034694611@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78865393.1034694611@localhost> User-Agent: Mutt/1.3.27i X-Spam-Status: No, hits=-14.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Oct 15, 2002 at 03:10:11PM -0400, John C Klensin wrote: > --On Tuesday, 15 October, 2002 18:37 +0200 Keld Jrn Simonsen > wrote: > > > On Tue, Oct 15, 2002 at 06:06:26PM +0200, Erik Nordmark wrote: > >> > I would still like it to be called the ISO 10646 repertoire. > >> > >> Doing that change to this added text would be very odd given > >> that that the rest of the document has no mention of ISO > >> 10646. Thus I think consistency is the overriding concern > >> here. > > > > Is that not a major change from IETF policy? We should mention > > ISO standards when they are applicable. > > Keld, this is an old argument in the IDN WG, and I think ISO > basically decided to lose it a year or two ago. While, I, too, > prefer to reference ISO standards where possible, the situation > here is that the IDN effort needed both a character and code > point repertoire and a collection of norms about how those code > points were to be used, compared, etc. My preference, and I > think that of the IETF generally, would have been to reference > ISO Standards for all of this but, as you know, the > complementary "usage" standards did not follow the code point > ones. Even where TRs exist, ISO generally doesn't like having > its TRs referenced normatively. > > We approached ISO about the problem of the missing standards at > the JTC1 level and stressed that, if they couldn't respond > usefully and fairly quickly, we would have to rely on UTC. We > didn't get a response for a long time, and then, in my opinion, > were brushed off. And you are all-too-aware what happened when > we tried to work something with SC22... from my perspective, not > only did we not get active cooperation, we were deliberately > insulted by their "agreeing" to something we had previously told > them (formally and informally) we would not accept. While this > was going on, the Unicode folks were actively working with the > WG, inviting IETF participation in their meetings and in > liaisons with on their Board, and trying to be responsive to our > needs in their ongoing work. I think they are entitled to > recognition for those efforts, including having their preferred > name for the CCS and associated materials used. And, if JTC1 > wants to isolate themselves from the Internet in this area, and > to hint that they are doing so because the IETF is just not > important enough to deal with on a peer basis, I don't see any > reason to respond by advertising the relevant ISO Standard in > more than a footnote. Could you give me a reference to the approach from IETF to JTC1? As the liaison officer from JTC1/SC2 with IETF I cannot remember such a request, so I would like to see it. The problem with SC22 is that Unicode/L2 has infiltrated it, and tries to sabotage the cooperation between ISO and IETF, by not having any cooperation being done, like delaying liaison or making it in a way that is unacceptable. And also by having ISO standards in the area voted down, delayed, or turned into TRs. And then working smoothly with IETF directly. Their policy sems to be efficient, and this is the behaviour that you are rewarding, IMHO. > Just my opinion, of course. But, if my analysis is correct or > rings true, the problem you are addressing needs to be raised > within JTC1, not in this working group or over these documents. > > john > From owner-idn@ops.ietf.org Wed Oct 16 08:48:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27536 for ; Wed, 16 Oct 2002 08:48:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181nQF-0007ux-00 for idn-data@psg.com; Wed, 16 Oct 2002 05:37:11 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #2) id 181nQD-0007uj-00 for idn@ops.ietf.org; Wed, 16 Oct 2002 05:37:09 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 181nQ4-0000zX-00; Wed, 16 Oct 2002 12:37:00 +0000 Date: Wed, 16 Oct 2002 08:36:59 -0400 From: John C Klensin To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= cc: Erik Nordmark , Simon Josefsson , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA problem statement Message-ID: <141681140.1034757419@localhost> In-Reply-To: <20021016120603.GA10829@rap.rap.dk> References: <20021015144806.GB3556@rap.rap.dk> <20021015163710.GB4021@rap.rap.dk> <78865393.1034694611@localhost> <20021016120603.GA10829@rap.rap.dk> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-8.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27536 --On Wednesday, 16 October, 2002 14:06 +0200 Keld Jrn Simonsen wrote: >> Keld, this is an old argument in the IDN WG, and I think ISO >> basically decided to lose it a year or two ago. While, I, >> too, prefer to reference ISO standards where possible, the >> situation here is that the IDN effort needed both a character >> and code point repertoire and a collection of norms about how >> those code points were to be used, compared, etc. My >> preference, and I think that of the IETF generally, would >> have been to reference ISO Standards for all of this but, as >> you know, the complementary "usage" standards did not follow >> the code point ones. Even where TRs exist, ISO generally >> doesn't like having its TRs referenced normatively. >> >> We approached ISO about the problem of the missing standards >> at the JTC1 level and stressed that, if they couldn't respond >> usefully and fairly quickly, we would have to rely on UTC. We >> didn't get a response for a long time, and then, in my >> opinion, were brushed off. And you are all-too-aware what >> happened when we tried to work something with SC22... from my >> perspective, not only did we not get active cooperation, we >> were deliberately insulted by their "agreeing" to something >> we had previously told them (formally and informally) we >> would not accept. While this was going on, the Unicode folks >> were actively working with the WG, inviting IETF >> participation in their meetings and in liaisons with on their >> Board, and trying to be responsive to our needs in their >> ongoing work. I think they are entitled to recognition for >> those efforts, including having their preferred name for the >> CCS and associated materials used. And, if JTC1 wants to >> isolate themselves from the Internet in this area, and to >> hint that they are doing so because the IETF is just not >> important enough to deal with on a peer basis, I don't see any >> reason to respond by advertising the relevant ISO Standard in >> more than a footnote. > > Could you give me a reference to the approach from IETF to > JTC1? As the liaison officer from JTC1/SC2 with IETF I cannot > remember such a request, so I would like to see it. As I said, this was not to SC2, but to JTC1 and occurred as a direct inquiry/request from me (as IAB Chair at the time) to Tom Frost (as JTC1 Chair at the time). Since Internationalization work was being done in several SCs of JTC1 at the time, part of the question was "where can we really get something done". And, since JTC1 has refused to consider a liaison with IETF at that level, there is no mechanism for causing a formal, documented, set of contacts. > The problem with SC22 is that Unicode/L2 has infiltrated it, > and tries to sabotage the cooperation between ISO and IETF, by > not having any cooperation being done, like delaying liaison > or making it in a way that is unacceptable. And also by having > ISO standards in the area voted down, delayed, or turned into > TRs. And then working smoothly with IETF directly. Their > policy sems to be efficient, and this is the behaviour that > you are rewarding, IMHO. I'll let someone else comment on most of this description. But it seems to me that you are describing a problem within JTC1 and that it is up to JTC1 to fix it if they, or ISO, care. If the P-members of SC22, or of JTC1, believe there is a problem that needs fixing, they clearly have the power to make other selections of conveners, to modify work items, or to give clear instructions to Secretariats about ballots. And, if I were to see the problem the way you do, I'd see this documentation decision on IETF's part as part of the justification for making some changes, on a "if we proceed this way, that happens, and ISO becomes ever more irrelevant" basis, rather than just as rewarding behavior which you find unattractive. john john From owner-idn@ops.ietf.org Thu Oct 17 02:32:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02215 for ; Thu, 17 Oct 2002 02:32:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182441-0007NT-00 for idn-data@psg.com; Wed, 16 Oct 2002 23:23:21 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #2) id 18243z-0007NH-00 for idn@ops.ietf.org; Wed, 16 Oct 2002 23:23:19 -0700 Received: (qmail 88903 invoked from network); 17 Oct 2002 06:23:17 -0000 Received: from 12-234-208-62.client.attbi.com (HELO c1340594a) (12.234.208.62) by relay1.pair.com with SMTP; 17 Oct 2002 06:23:17 -0000 X-pair-Authenticated: 12.234.208.62 Message-ID: <002b01c275a5$c7279970$8900a8c0@c1340594a> From: "Mark Davis" To: =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= , "John C Klensin" Cc: =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= , "Erik Nordmark" , "Simon Josefsson" , References: <20021015144806.GB3556@rap.rap.dk> <20021015163710.GB4021@rap.rap.dk> <78865393.1034694611@localhost> <20021016120603.GA10829@rap.rap.dk> Subject: Re: [idn] Re: IDNA problem statement Date: Wed, 16 Oct 2002 23:23:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-5.4 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > The problem with SC22 is that Unicode/L2 has infiltrated it, and tries to > sabotage the cooperation between ISO and IETF, by not having any This is misrepresenting the situation. Certainly SC22 has not been "infiltrated", nor has there been "sabotage". There are some people from on a particular working group, WG20, that are in support of Unicode, and there are others who are not. But completely independent of Unicode, the real problem is that most of the documents that were being proposed *to* the WG20 group (such as the internationalization API, or 14652) for standardization were -- how can I put this most charitably -- of extremely low quality. Look at the negative comments in http://std.dkuug.dk/JTC1/SC22/WG20/docs/n857-n3261.pdf for examples. TR 14652 ended up being a Type 1 TR: "when the required support cannot be obtained for the publication of an International Standard, despite repeated effort". The only reason, I believe, that it passed -- even as a type-1 TR (not a standard), even with huge sections marked as controversial -- was that a number of countries tend to simply vote without bothering to actually read the text. The proposed internationalization API was even worse: if a college student sent us that as a sample of his work we wouldn't even bother interviewing him. The one exception is ISO 14651. With a lot of hard work by people on the WG20 committee, both those who support Unicode and those who don't, together with the UTC, the collation standard has turned out well. But even there, at this point the work would be better transferred to SC2/WG2, which is where the linguistic expertise is in ISO. Mark The above are my own opinions, and do not represent those of any organization I am affiliated with. __________ http://www.macchiato.com ◄ “Eppur si muove” ► ----- Original Message ----- From: "Keld Jørn Simonsen" To: "John C Klensin" Cc: "Keld Jørn Simonsen" ; "Erik Nordmark" ; "Simon Josefsson" ; Sent: Wednesday, October 16, 2002 05:06 Subject: Re: [idn] Re: IDNA problem statement > On Tue, Oct 15, 2002 at 03:10:11PM -0400, John C Klensin wrote: > > --On Tuesday, 15 October, 2002 18:37 +0200 Keld Jørn Simonsen > > wrote: > > > > > On Tue, Oct 15, 2002 at 06:06:26PM +0200, Erik Nordmark wrote: > > >> > I would still like it to be called the ISO 10646 repertoire. > > >> > > >> Doing that change to this added text would be very odd given > > >> that that the rest of the document has no mention of ISO > > >> 10646. Thus I think consistency is the overriding concern > > >> here. > > > > > > Is that not a major change from IETF policy? We should mention > > > ISO standards when they are applicable. > > > > Keld, this is an old argument in the IDN WG, and I think ISO > > basically decided to lose it a year or two ago. While, I, too, > > prefer to reference ISO standards where possible, the situation > > here is that the IDN effort needed both a character and code > > point repertoire and a collection of norms about how those code > > points were to be used, compared, etc. My preference, and I > > think that of the IETF generally, would have been to reference > > ISO Standards for all of this but, as you know, the > > complementary "usage" standards did not follow the code point > > ones. Even where TRs exist, ISO generally doesn't like having > > its TRs referenced normatively. > > > > We approached ISO about the problem of the missing standards at > > the JTC1 level and stressed that, if they couldn't respond > > usefully and fairly quickly, we would have to rely on UTC. We > > didn't get a response for a long time, and then, in my opinion, > > were brushed off. And you are all-too-aware what happened when > > we tried to work something with SC22... from my perspective, not > > only did we not get active cooperation, we were deliberately > > insulted by their "agreeing" to something we had previously told > > them (formally and informally) we would not accept. While this > > was going on, the Unicode folks were actively working with the > > WG, inviting IETF participation in their meetings and in > > liaisons with on their Board, and trying to be responsive to our > > needs in their ongoing work. I think they are entitled to > > recognition for those efforts, including having their preferred > > name for the CCS and associated materials used. And, if JTC1 > > wants to isolate themselves from the Internet in this area, and > > to hint that they are doing so because the IETF is just not > > important enough to deal with on a peer basis, I don't see any > > reason to respond by advertising the relevant ISO Standard in > > more than a footnote. > > Could you give me a reference to the approach from IETF to JTC1? > As the liaison officer from JTC1/SC2 with IETF I cannot remember > such a request, so I would like to see it. > > The problem with SC22 is that Unicode/L2 has infiltrated it, and tries to > sabotage the cooperation between ISO and IETF, by not having any > cooperation being done, like delaying liaison or making it in a way that > is unacceptable. And also by having ISO standards in the area > voted down, delayed, or turned into TRs. And then working smoothly with IETF > directly. Their policy sems to be efficient, and this is the behaviour > that you are rewarding, IMHO. > > > Just my opinion, of course. But, if my analysis is correct or > > rings true, the problem you are addressing needs to be raised > > within JTC1, not in this working group or over these documents. > > > > john > > > From owner-idn@ops.ietf.org Thu Oct 17 17:49:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27074 for ; Thu, 17 Oct 2002 17:49:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182IIj-0009Hj-00 for idn-data@psg.com; Thu, 17 Oct 2002 14:35:29 -0700 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #2) id 182IIh-0009HX-00 for idn@ops.ietf.org; Thu, 17 Oct 2002 14:35:27 -0700 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 165949; Thu, 17 Oct 2002 16:33:16 -0500 Message-ID: <3DAF2D19.30307@ehsco.com> Date: Thu, 17 Oct 2002 16:35:21 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] IDNA problem statement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.0 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 10/15/2002 7:39 AM Erik Nordmark wrote: > 1.1 Problem Statement > > The IDNA specification solves the problem of extending the repertoire > of characters that can be used in domain names to include the Unicode > repertoire. This is broader than the actual solution. IDNA allows applications to make use of characters from the Unicode repertoire by providing a standardized encoding of i18n domain name which can be used to represent and interpret extended characters consistently. It does not extend the repertoire of characters which are usable in domain names, nor does it provide applications with access to these characters in their unencoded form. > IDNA does not extend the service offered by DNS to the applications. Correct > Instead, the applications (and, by implication, the users) continue to > see an exact-match lookup service. Either there is a single > exactly-matching name or there is no match. This model has served the > existing applications well, but it requires that users know the exact > spelling of the domain names that the users type into applications such > as web browsers and mail user agents. This is irrelevant. It's interesting to about five people here, but it a complete side-track to the functionality offered by IDNA. Suggest you drop this entirely. > The introduction of the larger > repertoire of characters potentially makes the set of misspellings > larger, especially given that in some cases the same appearance, for > example on a business card, might visually match several Unicode code > points or several sequences of code points. Move that to the security section, or to the 1.2 section below > IDNA allows the graceful introduction of IDNs not only by avoiding > upgrades to existing DNS infrastructure (servers, caches, stub > resolvers), Put it another way. IDNA doesn't "break" ANY node in the infrastructure, including DNS servers/resolvers/blah, but ALSO including protocols and their applications. You are limiting the discussion to certain elements of the infrastructure and casually omitting the other 99% of the infrastructure, implying that the 99% doesn't matter. You are talking about the 1% getting a free-ride like it is a big deal. Look, I have never understood the fascination with the 1% that doesn't have to pay. This continued focus on "we saved the 1%" is intellectually dishonest all the way around. Not only is it a miniscule portion of the infrastructure that actually USES domain names, but it completely ignores the fact that 99% DOES HAVE TO PAY. All I'm asking here is that you provide the full analysis on this point, rather than telling the 1% story again. If we are so embarrassed by the truth, then we should rethink it. If we are comfortable with the truth, then let's tell it. > but also by allowing some rudimentary use of IDNs in > applications by using the ASCII representation of the non-ASCII name > labels. Yeah, that's it > While such names are very user-unfriendly to read and type, and > hence are not suitable for user input, they allow (for instance) > replying to email and clicking on URLs even though the domain name > displayed is incomprehensible to the user. In order to allow > user-friendly input and output of the IDNs, the applications need to be > modified to conform to this specification. ^every application that wants to display them > IDNA uses the Unicode character repertoire which avoids the significant > delays that that would be inherent in waiting for a different and > specific character set be defined for IDN purposes by some other > standards developing organization. No justification is required here, IMO. > 1.2 Limitations of IDNA > > The IDNA protocol does not solve > all linguistic issues with users inputting names in different scripts. > Many important language-based and script-based mappings are not covered > in IDNA and need to be handled outside the protocol. For example, names > that are entered in a mix of traditional and simplified Chinese > characters will not be mapped to a single canonical name. Another > example is Scandinavian names that are entered with U+00F6 (LATIN SMALL > LETTER O WITH DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL > LETTER O WITH STROKE). > > An example of an important issue that is not considered in > detail in IDNA is how to provide a high probability that a user who is > entering a domain name based on visual information (such as from a > business card or billboard) or aural information (such as from a > telephone or radio) would correctly enter the IDN. This a complex issue > relating to languages, input methods on computers, and so on. > Furthermore, the kind of matching and searching necessary for a high > probability of success would not fit the role of the DNS and its exact > matching function. there are other hot topics which might be well-served here, specifically including the issues with local functions (clipboards, piping, etc), dangers from auto-conversion (message-id, searching), etc. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Oct 22 07:58:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12906 for ; Tue, 22 Oct 2002 07:58:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183xPy-000Dt9-00 for idn-data@psg.com; Tue, 22 Oct 2002 04:41:50 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 183xPv-000Dso-00; Tue, 22 Oct 2002 04:41:47 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11893; Tue, 22 Oct 2002 07:39:31 -0400 (EDT) Message-Id: <200210221139.HAA11893@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-01.txt Date: Tue, 22 Oct 2002 07:39:30 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 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, J. Klensin et al. Filename : draft-jseng-idn-admin-01.txt Pages : 20 Date : 2002-10-21 Achieving internationalized access to domain names raises many complex issues. These include 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-01.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-01.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-01.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-10-21143110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jseng-idn-admin-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-jseng-idn-admin-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143110.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Oct 22 08:01:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12994 for ; Tue, 22 Oct 2002 08:01:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183xQC-000DtU-00 for idn-data@psg.com; Tue, 22 Oct 2002 04:42:04 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 183xQA-000DtH-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 04:42:02 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11956; Tue, 22 Oct 2002 07:39:45 -0400 (EDT) Message-Id: <200210221139.HAA11956@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-klensin-idn-tld-00.txt Date: Tue, 22 Oct 2002 07:39:45 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 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 : National and Local Characters in DNS TLD Names Author(s) : J. Klensin Filename : draft-klensin-idn-tld-00.txt Pages : 7 Date : 2002-10-21 In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about 'multilingual' or 'internationalized A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klensin-idn-tld-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-klensin-idn-tld-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-klensin-idn-tld-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-21143137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-klensin-idn-tld-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-klensin-idn-tld-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143137.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Oct 22 14:05:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28567 for ; Tue, 22 Oct 2002 14:05:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1843G4-000NOk-00 for idn-data@psg.com; Tue, 22 Oct 2002 10:56:00 -0700 Received: from m3102.hostcentric.net ([216.157.79.140]) by psg.com with smtp (Exim 3.36 #2) id 1843G1-000NOJ-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 10:55:57 -0700 Received: (qmail 16608 invoked by alias); 22 Oct 2002 17:55:12 -0000 Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237) by 0 with SMTP; 22 Oct 2002 17:55:12 -0000 Received: (qmail 4100 invoked by alias); 22 Oct 2002 17:55:12 -0000 Received: from unknown (HELO DAVIS1) (32.97.110.142) by 0 with SMTP; 22 Oct 2002 17:55:12 -0000 Message-ID: <002b01c279f4$29660c50$74de2b09@DAVIS1> From: "Mark Davis" To: References: <200210221139.HAA11893@ietf.org> Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt Date: Tue, 22 Oct 2002 10:55:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-2.5 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Would there be any way to get the policy on the format of internet drafts to be amended to allow UTF-8? It is pretty painful trying to read documents when the actual characters cannot be used. Mark __________________________________ http://www.macchiato.com ► “Eppur si muove” ◄ ----- Original Message ----- From: To: Cc: ; ; Sent: Tuesday, October 22, 2002 04:39 Subject: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt > 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, J. Klensin et al. > Filename : draft-jseng-idn-admin-01.txt > Pages : 20 > Date : 2002-10-21 > > Achieving internationalized access to domain names raises many complex > issues. These include 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-01.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-01.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-01.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. > From owner-idn@ops.ietf.org Tue Oct 22 14:56:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00539 for ; Tue, 22 Oct 2002 14:56:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18448Z-000PNp-00 for idn-data@psg.com; Tue, 22 Oct 2002 11:52:19 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #2) id 18448X-000PNd-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 11:52:18 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 18448T-0009vf-00; Tue, 22 Oct 2002 18:52:13 +0000 Date: Tue, 22 Oct 2002 14:52:13 -0400 From: John C Klensin To: Mark Davis , idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt Message-ID: <7306792.1035298333@localhost> In-Reply-To: <002b01c279f4$29660c50$74de2b09@DAVIS1> References: <200210221139.HAA11893@ietf.org> <002b01c279f4$29660c50$74de2b09@DAVIS1> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 22 October, 2002 10:55 -0700 Mark Davis wrote: > Would there be any way to get the policy on the format of > internet drafts to be amended to allow UTF-8? It is pretty > painful trying to read documents when the actual characters > cannot be used. Mark, I understand that this draft was submitted in both ASCII and PDF. The PDF form contains the Chinese characters but, apparently, there is no way to get those posted as I-Ds (especially this close to an IETF and the cutoff dates), even though RFCs can be published that way. I trust the IESG will take this up at some appropriate time. James, in the interim, would there be some way to put the PDF up somewhere from which it could be retrieved by FTP or HTTP and to tell participants in this WG where to find it? thanks, john From owner-idn@ops.ietf.org Tue Oct 22 20:55:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09706 for ; Tue, 22 Oct 2002 20:55:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849en-000ODy-00 for idn-data@psg.com; Tue, 22 Oct 2002 17:45:57 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by psg.com with esmtp (Exim 3.36 #2) id 1849el-000ODW-00; Tue, 22 Oct 2002 17:45:55 -0700 Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id RAA25840; Tue, 22 Oct 2002 17:45:54 -0700 Date: Tue, 22 Oct 2002 17:21:56 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.61) Personal Organization: TribalWise X-Priority: 3 (Normal) Message-ID: <6332639222.20021022172156@tribalwise.com> To: owner-idn@ops.ietf.org, "Mark Davis" CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt In-Reply-To: <002b01c279f4$29660c50$74de2b09@DAVIS1> References: <200210221139.HAA11893@ietf.org> <002b01c279f4$29660c50$74de2b09@DAVIS1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.5 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NOSPAM_INC,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_THEBAT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Tuesday, October 22, 2002, 10:55:08 AM, you wrote: Mark> Would there be any way to get the policy on the format of internet drafts to Mark> be amended to allow UTF-8? It is pretty painful trying to read documents Mark> when the actual characters cannot be used. It has always been difficult to be limited to ascii data. And the problem is discussed every few years. What open standard, for representing non-ascii data, would you recommend? d/ -- Dave Crocker TribalWise From owner-idn@ops.ietf.org Tue Oct 22 21:26:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10910 for ; Tue, 22 Oct 2002 21:26:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184A4x-000Ppn-00 for idn-data@psg.com; Tue, 22 Oct 2002 18:12:59 -0700 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.36 #2) id 184A4v-000Pms-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 18:12:57 -0700 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id SAA04060 for ; Tue, 22 Oct 2002 18:12:27 -0700 (PDT) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id SAA29599 for ; Tue, 22 Oct 2002 18:12:26 -0700 (PDT) Received: from olympus-dublin.sybase.com (olympus-dum.sybase.com [10.22.97.110]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id SAA29595 for ; Tue, 22 Oct 2002 18:12:26 -0700 (PDT) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.6+Sun/8.10.2) with ESMTP id g9N1CPg03948 for ; Tue, 22 Oct 2002 18:12:25 -0700 (PDT) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.8.8+Sun/8.8.8) with SMTP id SAA28197 for ; Tue, 22 Oct 2002 18:12:25 -0700 (PDT) Message-Id: <200210230112.SAA28197@birdie.sybase.com> Date: Tue, 22 Oct 2002 18:12:25 -0700 (PDT) From: Kenneth Whistler Reply-To: Kenneth Whistler Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: bJLdqQxPuvVgvO9KRFozLQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id VAA10910 > Tuesday, October 22, 2002, 10:55:08 AM, you wrote: > Mark> Would there be any way to get the policy on the format of internet drafts to > Mark> be amended to allow UTF-8? It is pretty painful trying to read documents > Mark> when the actual characters cannot be used. > > It has always been difficult to be limited to ascii data. And the problem > is discussed every few years. > > What open standard, for representing non-ascii data, would you recommend? > I thought it was obvious that he was recommending UTF-8. Or if you prefer: RFC 2279 (or the follow-on of that that Franois Yergeau is working on) which is presumably what the other IETF recommendations about use of UTF-8 in protocols is based on... or ISO/IEC 10646-1:2000 and ISO/IEC 10646-2:2001 or The Unicode Standard, Version 3.2 --Ken From owner-idn@ops.ietf.org Tue Oct 22 21:47:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11592 for ; Tue, 22 Oct 2002 21:47:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184AX8-0001V8-00 for idn-data@psg.com; Tue, 22 Oct 2002 18:42:06 -0700 Received: from 132.0.asiainfra.com ([203.207.0.132] helo=mail.asiainfra.com) by psg.com with esmtp (Exim 3.36 #2) id 184AX6-0001TQ-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 18:42:04 -0700 Received: from gix (hyena.asiainfra.com [203.207.0.125]) by mail.asiainfra.com (8.11.6/8.11.6) with SMTP id g9N1fVe23746; Wed, 23 Oct 2002 09:41:32 +0800 From: "Kenny Huang" To: "John C Klensin" , "Mark Davis" , Subject: RE: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt Date: Wed, 23 Oct 2002 09:43:02 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <7306792.1035298333@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-7.6 required=5.0 tests=DEAR_SOMEBODY,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA11592 Dear All, I put the PDF on the website http://www.apan.net.tw/document.html FYI Kenny Huang huangk@alum.sinica.edu > James, in the interim, would there be some way to put the PDF up > somewhere from which it could be retrieved by FTP or HTTP and to > tell participants in this WG where to find it? > > thanks, > john > From owner-idn@ops.ietf.org Tue Oct 22 22:00:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11831 for ; Tue, 22 Oct 2002 22:00:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184AjB-0002En-00 for idn-data@psg.com; Tue, 22 Oct 2002 18:54:33 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 184Aj9-0002Dz-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 18:54:31 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05837 for ; Tue, 22 Oct 2002 19:54:29 -0600 (MDT) Received: from localhost (d-nwk02-143-189.EBay.Sun.COM [129.150.143.189]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9N1sRL24783 for ; Wed, 23 Oct 2002 03:54:27 +0200 (MEST) Date: Wed, 23 Oct 2002 03:51:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] IDNA problem statement To: idn@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk I've done so minor edits to this based on the discussion on the mailing list plus some other comments I've received. Erik 1.1 Problem Statement The IDNA specification solves the problem of extending the repertoire of characters that can be used in domain names to include the Unicode repertoire (with some restrictions). IDNA does not extend the service offered by DNS to the applications. Instead, the applications (and, by implication, the users) continue to see an exact-match lookup service. Either there is a single exactly-matching name or there is no match. This model has served the existing applications well, but it requires, with or without internationalized domain names, that users know the exact spelling of the domain names that the users type into applications such as web browsers and mail user agents. The introduction of the larger repertoire of characters potentially makes the set of misspellings larger, especially given that in some cases the same appearance, for example on a business card, might visually match several Unicode code points or several sequences of code points. IDNA allows the graceful introduction of IDNs not only by avoiding upgrades to existing infrastructure (such as DNS servers and mail transport agents), but also by allowing some rudimentary use of IDNs in applications by using the ASCII representation of the non-ASCII name labels. While such names are very user-unfriendly to read and type, and hence are not suitable for user input, they allow (for instance) replying to email and clicking on URLs even though the domain name displayed is incomprehensible to the user. In order to allow user-friendly input and output of the IDNs, the applications need to be modified to conform to this specification. IDNA uses the Unicode character repertoire, which avoids the significant delays that would be inherent in waiting for a different and specific character set be defined for IDN purposes by some other standards developing organization. 1.2 Limitations of IDNA The IDNA protocol does not solve all linguistic issues with users inputting names in different scripts. Many important language-based and script-based mappings are not covered in IDNA and need to be handled outside the protocol. For example, names that are entered in a mix of traditional and simplified Chinese characters will not be mapped to a single canonical name. Another example is Scandinavian names that are entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE). An example of an important issue that is not considered in detail in IDNA is how to provide a high probability that a user who is entering a domain name based on visual information (such as from a business card or billboard) or aural information (such as from a telephone or radio) would correctly enter the IDN. Similar issues issues exist for ASCII domain names, for example the possible visual confusion between the letter 'O' and the digit zero, but the introduction of the larger repertoire of characters creates more opportunities of similar looking and similar sounding names. Note that this is a complex issue relating to languages, input methods on computers, and so on. Furthermore, the kind of matching and searching necessary for a high probability of success would not fit the role of the DNS and its exact matching function. --- From owner-idn@ops.ietf.org Tue Oct 22 22:07:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12038 for ; Tue, 22 Oct 2002 22:07:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184AqP-0002h2-00 for idn-data@psg.com; Tue, 22 Oct 2002 19:02:01 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 184AqN-0002gp-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 19:01:59 -0700 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9N21sW05835; Tue, 22 Oct 2002 19:01:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200210230112.SAA28197@birdie.sybase.com> References: <200210230112.SAA28197@birdie.sybase.com> 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: Tue, 22 Oct 2002 19:02:01 -0700 To: Kenneth Whistler , idn@ops.ietf.org, "Mark Davis" From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.7 required=5.0 tests=HABEAS_SWE,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Wait, wait! This is the *wrong place* for this debate. The IETF has fixed guidelines for submitting Internet Drafts. We cannot change those guidelines in the IDN WG. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Oct 22 22:33:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12888 for ; Tue, 22 Oct 2002 22:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184BBA-00043p-00 for idn-data@psg.com; Tue, 22 Oct 2002 19:23:28 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 184BB7-00043W-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 19:23:25 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20400 for ; Tue, 22 Oct 2002 20:23:24 -0600 (MDT) Received: from localhost (d-nwk02-143-189.EBay.Sun.COM [129.150.143.189]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9N2NML26462 for ; Wed, 23 Oct 2002 04:23:22 +0200 (MEST) Date: Wed, 23 Oct 2002 04:20:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] Last minute editorial clarifications on IDNA To: idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk The discussion about the IDNA problem statement etc on the list plus some 11:th hour review comments about technical clarity has brough forth this list of editorial clarifications with some additions to the security considerations section. If anybody thinks these changes are more then editorial changes then please let me know. Authors, can we apply these to the IDNA specification? Erik 1. In section 2 the word "integral" is used. The use of "integral" might raise the question "integral of what". Please change it to "integer". 2. In section 2 make it clear that the definition of Internationalized Label is more clear about what "can be applied" since it doesn't say anything explicit about the UseSTD13ASCIIRules. An "internationalized label" is a label to which the ToASCII operation (see section 4) can be applied without failing. This implies that every Add "(with the UseSTD13ASCIIRules flag unset)" after "without failing". 3. In section 2 add words to try to make it clearer that all ASCII names are IDN by adding the parenthesis: This implies that every ASCII domain name is an IDN (which implies that it is possible for a name to be an IDN without it containing any non-ASCII characters). 4. In section 4 make it more clear when UseSTD13ASCIIRules should be set by adding the lines starting with '+': For each label, decide whether or not to enforce the restrictions on ASCII characters in host names [STD3]. + (Applications already faced this choice before the introduction of + IDNA, and can continue to make the decision the same way they always + have; IDNA makes no new recommendations regarding this choice.) If the restrictions are to be enforced, set the flag called "UseSTD3ASCIIRules" for that label. 5. In section 4 before the start of section 4.1 add text making clear that the protocol only specifies the externally visible behavior and not e.g. that ToASCII and ToUnicode be actual APIs: This description of the protocol uses specific procedure names and names of flags, and so on, in order to facilitate the specification of the protocol. These names as well as the actual steps of the procedures are not required of an implementation. In fact, any implementation which has the same external behavior as specified in this document conforms to this specification. 6. Section 4, step (4) can be interpreted to ban the display of an ACE which is inconsistent with section 3.1. The fact that it isn't inconsistent could be made more clear by restating step (4) as: Process each label with either the ToASCII or the ToUnicode operation as appropriate. Typically, you use the ToASCII operation if you are about to put the name into an IDN-unaware slot, and you use the ToUnicode operation if you are displaying the name to a user; section 3.1 gives greater detail on the applicable requirements. 7. In section 4.1 there is a use of "needs to have" which might be confusing since it isn't clear whether it is a requirement or something else. The actual requirement is in the preceeding sentence. Thus it makes sense rephrasing the last setence in this paragraph: > It is important to note that the ToASCII operation can fail. ToASCII > fails if any step of it fails. If any step of the ToASCII operation > fails on any label in a domain name, that domain name MUST NOT be used > as an internationalized domain name. The application needs to have some > method of dealing with this failure. to be: The method for deadling with this failure is application-specific. 8. In the fifth paragraph of 6.2, the phrase "other formats than ASCII". ASCII is not a format. Guesses as to what this might mean open up loopholes in the specification. I suggest will be able to accept domain names in other formats than ASCII, and s/formats/charsets/ 9. Add this in an approprite place in the security considerations section: The introduction of IDNA means that any existing labels that start with the ACE prefix and would be altered by ToUnicode will automatically be ACE labels, and will be considered equivalent to non-ASCII labels, whether or not that was the intent of the zone adminstrator or registrant. 10. In section 4.2 add a statement about the length of the ToUnicode output after the second paragraph. This statement is probably helpful for implementors trying to avoid buffer overflow problems. The ToUnicode output never contains more code points than its input. Note that the number of octets needed to represent a sequence of code points depends on the particular character encoding used. 11. In the security considerations section point out that the that permission to impose registration restrictions of section 2 might be useful in some cases to minimize homographs. After: To help prevent confusion between characters that are visually similar, it is suggested that implementations provide visual indications where a domain name contains multiple scripts. Such mechanisms can also be used to show when a name contains a mixture of simplified and traditional Chinese characters, or to distinguish zero and one from O and l. ADD: DNS zone adminstrators may impose restrictions (subject to the limitations in section 2) that try to minimize homographs. --- From owner-idn@ops.ietf.org Tue Oct 22 23:15:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13689 for ; Tue, 22 Oct 2002 23:15:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Btv-0006tc-00 for idn-data@psg.com; Tue, 22 Oct 2002 20:09:43 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 184Btt-0006qW-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 20:09:41 -0700 Received: (qmail 57367 invoked from network); 23 Oct 2002 03:10:30 -0000 Received: from bb-203-125-93-5.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.93.5) by sentosa.post1.com with SMTP; 23 Oct 2002 03:10:30 -0000 Message-ID: <02ea01c27a41$82e12010$0600a8c0@JSENGTOSHIBA> From: "James Seng" To: "John C Klensin" , "Mark Davis" , References: <200210221139.HAA11893@ietf.org> <002b01c279f4$29660c50$74de2b09@DAVIS1> <7306792.1035298333@localhost> Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt Date: Wed, 23 Oct 2002 11:08:49 +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=-4.7 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I did send both UTF-8 & PDF version to internet-draft@ietf.org. After asking me to remove all the UTF-8 from the txt version, only the txt was published...I don't know what happened to the PDF. Anyway, Kenny has put up the PDF at http://www.apan.net.tw/ietf/draft-jseng-idn-admin-01.pdf -James Seng > I understand that this draft was submitted in both ASCII and > PDF. The PDF form contains the Chinese characters but, > apparently, there is no way to get those posted as I-Ds > (especially this close to an IETF and the cutoff dates), even > though RFCs can be published that way. > > I trust the IESG will take this up at some appropriate time. > > James, in the interim, would there be some way to put the PDF up > somewhere from which it could be retrieved by FTP or HTTP and to > tell participants in this WG where to find it? > > thanks, > john > > > From owner-idn@ops.ietf.org Wed Oct 23 00:27:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14955 for ; Wed, 23 Oct 2002 00:27:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184CxJ-000Asf-00 for idn-data@psg.com; Tue, 22 Oct 2002 21:17:17 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #2) id 184CxH-000AsT-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 21:17:15 -0700 Received: (qmail 70446 invoked from network); 23 Oct 2002 04:17:13 -0000 Received: from 12-234-208-62.client.attbi.com (HELO c1340594a) (12.234.208.62) by relay1.pair.com with SMTP; 23 Oct 2002 04:17:13 -0000 X-pair-Authenticated: 12.234.208.62 Message-ID: <007101c27a4b$2b8a8770$8900a8c0@c1340594a> From: "Mark Davis" To: "Kenneth Whistler" , , "Mark Davis" , "Paul Hoffman / IMC" References: <200210230112.SAA28197@birdie.sybase.com> Subject: UTF-8 in Internet Drafts (was Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt) Date: Tue, 22 Oct 2002 21:17:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.7 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I didn't say the *IDN WG* itself could change that. What I said was "Would there be any way to get the policy on the format of internet drafts to be amended to allow UTF-8? It is pretty painful trying to read documents when the actual characters cannot be used." I have no idea what the process that the Powers That Be have for deciding the formats for internet drafts. I simply hope that that policy gets changed, since it has gotten to the point that anyone who wants to can read and write UTF-8 documents; various tools to do so are free and easily available. Mark __________ http://www.macchiato.com ◄ “Eppur si muove” ► ----- Original Message ----- From: "Paul Hoffman / IMC" To: "Kenneth Whistler" ; ; "Mark Davis" Sent: Tuesday, October 22, 2002 19:02 Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt > Wait, wait! This is the *wrong place* for this debate. > > The IETF has fixed guidelines for submitting Internet Drafts. We > cannot change those guidelines in the IDN WG. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Wed Oct 23 00:35:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15204 for ; Wed, 23 Oct 2002 00:35:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184DAB-000Bin-00 for idn-data@psg.com; Tue, 22 Oct 2002 21:30:35 -0700 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.36 #2) id 184DAA-000Bi7-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 21:30:34 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.67.53]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id H4F36W0B.204; Wed, 23 Oct 2002 00:30:32 -0400 Message-ID: <000e01c27a4c$e175eba0$35434244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Erik Nordmark" References: Subject: Re: [idn] IDNA problem statement Date: Tue, 22 Oct 2002 21:30:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-3.9 required=5.0 tests=EMAIL_ATTRIBUTION,INVALID_MSGID,QUOTED_EMAIL_TEXT, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > IDNA uses the Unicode character repertoire, which avoids the > significant delays that would be inherent in waiting for a different > and specific character set be defined for IDN purposes by some other > standards developing organization. I still don't see the point of this passage. It sounds as though some other standards organization would be better equipped to develop a character set than SC 2/WG 1 or UTC, but we're going with Unicode anyway, just for the sake of expediency. Is that the intent? If not, what purpose does the "which" clause serve? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Wed Oct 23 01:03:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15448 for ; Wed, 23 Oct 2002 01:03:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184DYu-000DFf-00 for idn-data@psg.com; Tue, 22 Oct 2002 21:56:08 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #2) id 184DYt-000DFT-00 for idn@ops.ietf.org; Tue, 22 Oct 2002 21:56:07 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.67.53]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id H4F4D70D.705; Wed, 23 Oct 2002 00:55:55 -0400 Message-ID: <002901c27a50$6d311220$35434244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Erik Nordmark" References: <000e01c27a4c$e175eba0$35434244@anhmca.adelphia.net> Subject: Re: [idn] IDNA problem statement Date: Tue, 22 Oct 2002 21:55:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-3.1 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Oops: > I still don't see the point of this passage. It sounds as though some > other standards organization would be better equipped to develop a > character set than SC 2/WG 1 or UTC, but we're going with Unicode > anyway, just for the sake of expediency. Is that the intent? If not, > what purpose does the "which" clause serve? SC 2/WG 2 -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Wed Oct 23 17:49:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06467 for ; Wed, 23 Oct 2002 17:49:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184TFB-000Dpb-00 for idn-data@psg.com; Wed, 23 Oct 2002 14:40:49 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 184TF9-000Dp5-00 for idn@ops.ietf.org; Wed, 23 Oct 2002 14:40:48 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02037; Wed, 23 Oct 2002 15:40:46 -0600 (MDT) Received: from localhost (d-mpk17-88-244.Eng.Sun.COM [129.146.88.244]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9NLehL27362; Wed, 23 Oct 2002 23:40:44 +0200 (MEST) Date: Wed, 23 Oct 2002 23:37:53 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] IDNA problem statement To: Doug Ewell Cc: idn@ops.ietf.org, Erik Nordmark In-Reply-To: "Your message with ID" <000e01c27a4c$e175eba0$35434244@anhmca.adelphia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > Erik Nordmark wrote: > > > IDNA uses the Unicode character repertoire, which avoids the > > significant delays that would be inherent in waiting for a different > > and specific character set be defined for IDN purposes by some other > > standards developing organization. > > I still don't see the point of this passage. It sounds as though some > other standards organization would be better equipped to develop a > character set than SC 2/WG 1 or UTC, but we're going with Unicode > anyway, just for the sake of expediency. Is that the intent? If not, > what purpose does the "which" clause serve? I guess it could have been phrased better. The intent of the paragraph is to say that the even though the WG has discussed that Unicode might not be ideal, the (rough) consensus in the WG is to not prod some body outside the IETF (be it UTC or ISO or somebody else) to develop something potentially better than Unicode and wait for the result. Thus in terms of a problem statement, this is a constraint (quite resonable one at that :-) that the WG placed on itself. Erik From owner-idn@ops.ietf.org Wed Oct 23 21:08:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09458 for ; Wed, 23 Oct 2002 21:08:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184WMa-00058O-00 for idn-data@psg.com; Wed, 23 Oct 2002 18:00:40 -0700 Received: from m3102.hostcentric.net ([216.157.79.140]) by psg.com with smtp (Exim 3.36 #2) id 184WMY-00058C-00 for idn@ops.ietf.org; Wed, 23 Oct 2002 18:00:38 -0700 Received: (qmail 8962 invoked by alias); 24 Oct 2002 01:00:37 -0000 Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237) by 0 with SMTP; 24 Oct 2002 01:00:37 -0000 Received: (qmail 26887 invoked by alias); 24 Oct 2002 01:00:36 -0000 Received: from unknown (HELO DAVIS1) (207.46.124.24) by 0 with SMTP; 24 Oct 2002 01:00:36 -0000 Message-ID: <003d01c27af8$c113e5e0$b0d1399d@DAVIS1> From: "Mark Davis" To: "Erik Nordmark" , "Doug Ewell" Cc: , "Erik Nordmark" References: Subject: Re: [idn] IDNA problem statement Date: Wed, 23 Oct 2002 18:00:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.7 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Yes, I find the original paragraph to be very odd. It's a bit like having a paragraph: "The IDNA specification is written in the English language, which avoids the significant delays that would be inherent in waiting for a different and specific human language to be developed for IDN purposes by some other standards developing organization." I think the paragraph best omitted, but if you really need something, perhaps wording like: IDNA uses the Unicode character repertoire, which is the universal character encoding jointly developed by the Unicode Consortium and ISO/IEC SC2, and which is widely deployed on computer systems. Mark __________________________________ http://www.macchiato.com ► “Eppur si muove” ◄ ----- Original Message ----- From: "Erik Nordmark" To: "Doug Ewell" Cc: ; "Erik Nordmark" Sent: Wednesday, October 23, 2002 14:37 Subject: Re: [idn] IDNA problem statement > > Erik Nordmark wrote: > > > > > IDNA uses the Unicode character repertoire, which avoids the > > > significant delays that would be inherent in waiting for a different > > > and specific character set be defined for IDN purposes by some other > > > standards developing organization. > > > > I still don't see the point of this passage. It sounds as though some > > other standards organization would be better equipped to develop a > > character set than SC 2/WG 1 or UTC, but we're going with Unicode > > anyway, just for the sake of expediency. Is that the intent? If not, > > what purpose does the "which" clause serve? > > I guess it could have been phrased better. > The intent of the paragraph is to say that the even though the WG has > discussed that Unicode might not be ideal, the (rough) consensus in the WG > is to not prod some body outside the IETF (be it UTC or ISO or somebody else) > to develop something potentially better than Unicode and wait for the result. > > Thus in terms of a problem statement, this is a constraint (quite resonable > one at that :-) that the WG placed on itself. > > Erik > > > From owner-idn@ops.ietf.org Thu Oct 24 05:04:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29805 for ; Thu, 24 Oct 2002 05:04:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184dl7-000CfD-00 for idn-data@psg.com; Thu, 24 Oct 2002 01:54:29 -0700 Received: from qmail.netpia.com ([210.103.175.234] helo=netpia.com) by psg.com with smtp (Exim 3.36 #2) id 184dkP-000Cbw-00 for idn@ops.ietf.org; Thu, 24 Oct 2002 01:53:45 -0700 Received: (qmail 2178 invoked from network); 24 Oct 2002 08:53:29 -0000 Received: from unknown (HELO netpia.com) (220.76.134.183) by 0 with SMTP; 24 Oct 2002 08:53:29 -0000 Message-ID: <3DB7B508.2040106@netpia.com> Date: Thu, 24 Oct 2002 17:53:28 +0900 From: =?EUC-KR?B?IsDMvcLIo0Cz3cfHvsYi?= Organization: Netpia 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,en MIME-Version: 1.0 To: John C Klensin , idn mailing list Subject: [idn] About draft-idn-klensin-idn-tld-00.txt Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=NOSPAM_INC,SIGNATURE_LONG_SPARSE,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hello, This is SeungHo Lee from netpia.com, Korea. I have just finished reading your new I-D about idn-tld and there are some parts I want to know more specifically about this draft and your thoughts. I hope you could have some time to answer this questions. 1. Could you give me one simple example of local table for local translation you mentioned? Because I'm not sure 'to what' the local launguage is translated and what does the "translation" exactly means. Does the translation mean "encoding" translation (to ASCII-compatible)? Is is right that if embodied as you suggested in this draft there is no need to add new root servers? 2. You wrote in 1.1 -The effort to do this rapidly became known as "multilingual domain -names", although that is a misnomer, since the DNS deals only with -characters and identifier strings, and not, except by accident, what -people usually think of as "names". Like [DNSROLE] I could see you don't think DNS is not for human, but for machine. Namely, DNS is basically an identifier for machine, not for human... Am I right? 3. But there are a few opinions that domain names should reflect real entities and if they can't, there should be addresses(identifiers) for human in the Internet... How do you think about these opinions? 4. And If you think domain names are not for human, I guess IDN is also not for human because it is just another form of current domain names. (It'll have the same hierarchical structure..) Am I right? 5. I think currentyl there are two problems about DNS. One is the linguistic problem - IDN parts. And Another one is about domain names' not representing real world entities... I think you think that the first problem is to be solved through IDN ... (IDNA + this draft??) And the second one is to be solved by DNS-SEARCH you suggested before... Am I right? :) Thank you for reading... -- ͳּҿ eּҸ 츮 ѱ۷! ̽ȣ (Seungho Lee) / (R&D) ȭ : 02-2165-3054 ѽ : 02-671-5613 e : ̽ȣ@Ǿ / shlee@netpia.com : 8 35-1 ȭ 2 (:150-038) ѱͳּ : Ǿ ͳּ : http://www.netpia.com From owner-idn@ops.ietf.org Thu Oct 24 05:35:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00339 for ; Thu, 24 Oct 2002 05:35:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184dwd-000DM4-00 for idn-data@psg.com; Thu, 24 Oct 2002 02:06:23 -0700 Received: from qmail.netpia.com ([210.103.175.234] helo=netpia.com) by psg.com with smtp (Exim 3.36 #2) id 184dwa-000DLo-00 for idn@ops.ietf.org; Thu, 24 Oct 2002 02:06:20 -0700 Received: (qmail 3285 invoked from network); 24 Oct 2002 09:06:07 -0000 Received: from unknown (HELO netpia.com) (220.76.134.183) by 0 with SMTP; 24 Oct 2002 09:06:07 -0000 Message-ID: <3DB7B7FE.3070505@netpia.com> Date: Thu, 24 Oct 2002 18:06:06 +0900 From: =?windows-1252?Q?=22=3F=3F=3F=40=3F=3F=3F=22?= Organization: Netpia 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,en MIME-Version: 1.0 To: John C Klensin , idn mailing list Subject: [idn] About draft-idn-klensin-tld-00.txt Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=NOSPAM_INC,SIGNATURE_LONG_SPARSE,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, This is SeungHo Lee from netpia.com, Korea. I have just finished reading your new I-D about idn-tld and there are some parts I want to know more specifically about this draft and your thoughts. I hope you could have some time to answer this questions. :) 1. Could you give me one simple example of local table for local translation you mentioned? Because I'm not sure 'to what' the local launguage is translated and what does the "translation" exactly means. Does the translation mean "encoding" translation (to ASCII-compatible)? Is is right that if embodied as you suggested in this draft there is no need to add new root servers? 2. You wrote in 1.1 -The effort to do this rapidly became known as "multilingual domain -names", although that is a misnomer, since the DNS deals only with -characters and identifier strings, and not, except by accident, what -people usually think of as "names". Like [DNSROLE] I could see you don't think DNS is not for human, but for machine. Namely, DNS is basically an identifier for machine, not for human... Am I right? 3. But there are a few opinions that domain names should reflect real entities and if they can't, there should be addresses(identifiers) for human in the Internet... How do you think about these opinions? 4. And If you think domain names are not for human, I guess IDN is also not for human because it is just another form of current domain names. (It'll have the same hierarchical structure..) Am I right? 5. I think currentyl there are two problems about DNS. One is the linguistic problem - IDN parts. And Another one is about domain names' not representing real world entities... I think you think that the first problem is to be solved through IDN ... (IDNA + this draft??) And the second one is to be solved by DNS-SEARCH you suggested before... Am I right? Thank you for reading... -- ????????????????????????? ?????? e????? ?? ???! ????????????????????????? ??? (Seungho Lee) / ??? (R&D) ?? ? : 02-2165-3054 ??? : 02-671-5613 ?e?? : ???@??? / shlee@netpia.com ?? ? : ??? ???? ???? 8? 35-1 ??? ??? ?2?? (?:150-038) ????????????????????????? ? ??????? : ??? ? ??????? : http://www.netpia.com From owner-idn@ops.ietf.org Thu Oct 24 06:20:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01188 for ; Thu, 24 Oct 2002 06:20:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184es6-000GlA-00 for idn-data@psg.com; Thu, 24 Oct 2002 03:05:46 -0700 Received: from qmail.netpia.com ([210.103.175.234] helo=netpia.com) by psg.com with smtp (Exim 3.36 #2) id 184es1-000Gky-00 for idn@ops.ietf.org; Thu, 24 Oct 2002 03:05:42 -0700 Received: (qmail 7817 invoked from network); 24 Oct 2002 10:05:38 -0000 Received: from unknown (HELO netpia.com) (220.76.134.183) by 0 with SMTP; 24 Oct 2002 10:05:38 -0000 Message-ID: <3DB7C5F1.30709@netpia.com> Date: Thu, 24 Oct 2002 19:05:37 +0900 From: =?windows-1252?Q?=22=3F=3F=3F=40=3F=3F=3F=22?= Organization: Netpia 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,en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] I am sorry for including Korean Letters in the previous mail... Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.2 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To mailing list participants It was my first mail to this kind of maliling list, so, I think I made a mistake of including Korean letters in the mail... Last part of mail was my signature... forgot to remove it... And the sender part... it was also my usual setting when I send mails to Korean people... I'm really sorry I didn't take enough attention to check my settings ... I'll be more careful next time... I hope you didn't think it rude... Thank you... SH Lee From owner-idn@ops.ietf.org Thu Oct 24 07:44:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02689 for ; Thu, 24 Oct 2002 07:44:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184gJY-000MAS-00 for idn-data@psg.com; Thu, 24 Oct 2002 04:38:12 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 184gJV-000MA5-00 for idn@ops.ietf.org; Thu, 24 Oct 2002 04:38:09 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02420; Thu, 24 Oct 2002 07:35:49 -0400 (EDT) Message-Id: <200210241135.HAA02420@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-idna-14.txt Date: Thu, 24 Oct 2002 07:35:49 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 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. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Domain Names In Applications (IDNA) Author(s) : P. Faltstrom, P. Hoffman, A. Costello Filename : draft-ietf-idn-idna-14.txt Pages : 0 Date : 2002-10-23 Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called IDNA for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-idna-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-idna-14.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-10-23150056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-23150056.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu Oct 24 11:05:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10857 for ; Thu, 24 Oct 2002 11:05:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184jFb-0008WW-00 for idn-data@psg.com; Thu, 24 Oct 2002 07:46:19 -0700 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #2) id 184jFX-0008ST-00 for idn@ops.ietf.org; Thu, 24 Oct 2002 07:46:15 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 184jEv-0001CA-00; Thu, 24 Oct 2002 14:45:37 +0000 Date: Thu, 24 Oct 2002 10:45:36 -0400 From: John C Klensin To: shlee@netpia.com cc: idn mailing list Subject: [idn] Re: About draft-idn-klensin-tld-00.txt Message-ID: <165334343.1035456336@localhost> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 24 October, 2002 18:06 +0900 "=?windows-1252?Q?=22=3F=3F=3F=40=3F=3F=3F=22?=" wrote: > Hello, > > This is SeungHo Lee from netpia.com, Korea. > > I have just finished reading your new I-D about idn-tld > and there are some parts I want to know more specifically > about this draft and your thoughts. First of all, this draft is definitely _not_ an IDN WG work item or topic. I'm not quite sure why the I-D administrator posted it to the WG's list, although I think it is reasonable that WG members be aware of it. It is strictly a client-side suggestion, with significantly fewer "on the wire" or server implications than IDNA and so is probably not even an appropriate subject for formal IETF work. It is not an IRNSS topic either, although it is generally concerned with Internationalization and the i18n/l10n boundary. So, if people want to discuss it, please take it to the intloc list if you think that would be useful or just send me private mail, to which I will try to respond if it is technical in nature, rather than argumentative. Please do not copy the IDN list on any response to this note unless the co-Chairs make some suggestion to the contrary. > I hope you could have some time to answer this questions. :) > > 1. > Could you give me one simple example of local table for local > translation you mentioned? Because I'm not sure 'to what' the > local launguage is translated and what does the "translation" > exactly means. This applies only to TLD names. So the target for translation would be a TLD name. I would expect that a local translation table for use in Korea by speakers of the Korean language would contain Korean names or mnemonics for each of the TLDs (or each of the TLDs that were considered to be of interest), mapping onto the public identifiers (ISO3166-1 codes or other top-level DNS labels) for those TLDs. I would expect that, in particular, it would contain the name for South Korea as it is normally written and used in your country, mapping onto .KR. Similarly, I would expect a table for use in, say, Spain for use by Spanish-speakers, to contain names or mnemonics based on the Spanish language. So, a Korean table would typically contain the names of the Spanish and Korean TLDs, and the generic TLDs, in Korean, while a table for Spain would contain mappings (translations) from Spanish for each of those domains. And so forth, for every language or language variant whose users thought it was worth the trouble. > Does the translation mean "encoding" translation (to > ASCII-compatible)? Is is right that if embodied as you > suggested in this draft there is no need to add new root > servers? No. The term "translation" is used literally and in its normal sense. The Korean user would see the TLD name (label) as a Korean name, in Korean characters, but the application would put only the Roman-character-based global names of those TLDs, coded as usual in ASCII, on the wire or into DNS interfaces. > 2. > You wrote in 1.1 > -The effort to do this rapidly became known as "multilingual > domain -names", although that is a misnomer, since the DNS > deals only with -characters and identifier strings, and not, > except by accident, what -people usually think of as "names". > > Like [DNSROLE] I could see you don't think DNS is not for > human, but for machine. Namely, DNS is basically an identifier > for machine, not for human... Am I right? Yes, I still believe that. But it has little to do with this document. If the DNS is to be used as a naming environment, we must figure out how to internationalize it. In accepting Stringprep, the WG (and the IETF) have essentially concluded that a significant amount of that work is best done client-side, rather than sending, e.g., Unicode characters to a DNS server and having it do all comparisons and other mappings. But that decision, in turn, makes it appropriate to ask the question of what things can be better done by localization, rather than by uniform global solutions. The only "machines, not humans" element of this is that the strings provided by, or presented to, the users are not the strings that go on the wire. But IDNA already takes us to that point, so it is nothing new. > 3. > But there are a few opinions that domain names should reflect > real entities and if they can't, there should be > addresses(identifiers) for human in the Internet... How do you > think about these opinions? It depends somewhat on what, exactly, is meant by "real entities". My personal belief is that human-accessible naming should be provided through some service with directory capabilities including non-exact lookup, e.g., that outlined in draft-klensin-dns-search-04.txt. But, if people are going to insist on trying to make the DNS accomodate human-friendly, internationalized, naming, then I believe that we must find ways to do that which are consistent with the way the DNS works and is operated in practice. Creation of additional ccTLDs for each name by which a country is called (officially or otherwise) seems to me to be unwise and largely inconsistent with the structure of the DNS. So I wanted to point out that there is a plausible alternative, one that provides local naming for TLDs while avoiding the need for many additional TLDs with largely overlapping content. > 4. > And If you think domain names are not for human, I guess IDN > is also not for human because it is just another form of > current domain names. (It'll have the same hierarchical > structure..) Am I right? If you are trying to start an argument, this is not the place. Let me only say that I consider the use of the DNS for user-friendly names, and, especially, for "searching by name-guessing" to be inappropriate and that the monohierarchical structure is only part of the problem. I believe it is inappropriate for LDH-style names and inappropriate for internationalized ones -- slightly more so for the latter because the large character repertoire creates additional "opportunities" for mischief and confusion. At the same time, I recognize that people want to encode non-ASCII names into the DNS, if only to make host and resource identifers more conveniently remembered. I believe we should do that well, correctly, and safely. > 5. > I think currentyl there are two problems about DNS. > One is the linguistic problem - IDN parts. > And Another one is about domain names' not representing real > world entities... > > I think you think that the first problem is to be solved > through IDN ... (IDNA + this draft??) And the second one is to > be solved by DNS-SEARCH you suggested before... Am I right? I am not sure that I would draw the distinction quite that way, but that may be just a difference in the language we are using. I do not believe that IDN is a complete solution to internationalization, even internationalization constrained to work within the DNS. I believe that, to be practical and to avoid large amounts of confusion, IDNA is only part of the "solution". Other parts might include some localization suggestions like this one and, probably more important, per-zone or per-registry restrictions on what can actually be stored in a zone. The latter might possibly include some homogeneity rules for scripts that will be commonly used in that domain and/or use of Mark's suggestions about detection and reporting of mixed-script labels. regards, john From owner-idn@ops.ietf.org Thu Oct 24 15:15:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20299 for ; Thu, 24 Oct 2002 15:15:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184n7C-0000q4-00 for idn-data@psg.com; Thu, 24 Oct 2002 11:53:54 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 184n7A-0000ps-00 for idn@ops.ietf.org; Thu, 24 Oct 2002 11:53:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19499; Thu, 24 Oct 2002 14:51:18 -0400 (EDT) Message-Id: <200210241851.OAA19499@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , idn@ops.ietf.org From: The IESG Subject: [idn] Protocol Action: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Date: Thu, 24 Oct 2002 14:51:18 -0400 X-Spam-Status: No, hits=-0.2 required=5.0 tests=SPAM_PHRASE_00_01,TO_MALFORMED version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o Internationalizing Domain Names In Applications (IDNA) as a Proposed Standard. o Nameprep: A Stringprep Profile for Internationalized Domain Names o Punycode: An encoding of Unocode for use with IDNA These documents are the product of the Internationalized Domain Name Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This set documents provide the pieces of the IDNA architecture. They consist of the IDNA document itself, a stringprep profile for domain name labels (nameprep), and an encoding of Unicode strings into letter-digit-hyphen ASCII strings (punycode). These documents provide a mechanism to introduce Internationalized Domain Names without requiring any changes in the DNS itself; the IDN labels which contain non-ASCII characters are represented in the DNS using the ASCII compatible encoding (ACE) called Punycode. This representation can also be used when domain names are carried in IDN-unaware application protocols. Applications use the convertion routines specified in the IDNA document for coverting in both directions between the Unicode version of IDNs and the ACE versions of the IDNs. Working Group Summary The working group resolved some major comments in response to the IETF last call (plus minor and editorial comments). The major comments where - change from using Unicode 3.1 to 3.2 - added restrictions for bidirectional characters - making the applicability of IDNA more clear by adding an applicability section to the IDNA document. There was WG rough concensus to advance these document. Protocol Quality This document has been reviewed for the IESG by Erik Nordmark. From owner-idn@ops.ietf.org Wed Oct 30 05:16:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07043 for ; Wed, 30 Oct 2002 05:16:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186pc8-000HUE-00 for idn-data@psg.com; Wed, 30 Oct 2002 01:58:16 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 186pc2-000HSZ-00 for idn@ops.ietf.org; Wed, 30 Oct 2002 01:58:11 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 04F9B2E8; Wed, 30 Oct 2002 18:58:04 +0900 (JST) Message-Id: <4.2.0.58.J.20020924231836.04f05418@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 30 Oct 2002 18:34:02 +0900 To: Erik Nordmark From: Martin Duerst Subject: [idn] Re: idn-uri document Cc: idn@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Erik, Sorry to be late with my answer. I started writing it when I got your mail, but it somehow got lost. At 19:09 02/09/13 +0200, Erik Nordmark wrote: >Martin, > >I just read draft-ietf-idn-iri-01 and I have some comments and >questions. Thanks for your interest! >I don't know if the best place to discuss this is the IDN list, or >if there is some other list looking at URI/IRI stuff. For URIs, there is the old (IETF WG) uri list, now hosted at W3C: uri@w3.org. That would be appropriate because the draft is currently written as an update to the URI spec. Roy Fielding is working on a new edition of RFC 2396, mostly bug fixing. The W3C Internationalization WG is looking after the IRI draft. See e.g. http://www.w3.org/International/iri-edit/. So they could take it on. Public discussion would be on www-international@w3.org. The IDN WG is of course the third alternative, that's where it's currently, although it hasn't really been discussed a lot. >On page 4 it says "will always be rejected by resolvers". >I don't know if this is intended to be a statement about the current >implementations of resolvers, or a statement about something we should >recommend or require resolvers to do. I added an explanatory sentente 'because no such domains will be registered'. So it is about current (and hopefully future) operations, not about dns server implementations or resolver implementations. >I do think there currently are resolvers which happily pass whatever >string of octets into DNS packets and send them off. Ah, I see, of course the resolvers pass things through and then pass the negative result back, so they don't actually reject it. So now the sentence reads: However, such syntax should never be used, and will never be resolved because no such domains will be registered. >And I'm far from certain it would be a good idea recommend or mandate >that resolvers do additional checks. The IDNA model is that the clients >do nameprep and that the DNS servers just to a (ASCII case insensitive) >exact match. Agreed, sorry about the confusion. >The defined syntax rules for declare certain ASCII domain names illegal >(such as *.example.org). Where is the check for illedgal names assumed to >be performed? For IDNA it probably makes sense to only apply this types >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name >registrations and not do such checks in the clients. This is an IDNA question, not a idn-uri question. As far as I remember, the idea was to have the checks done on the clients, too (with some leeway for unassigned characters to stay forward-compatible with new character assignements). The reason for this was to create pressure on registries to follow the rules. > The work of the IDN WG includes some procedures for name preparation > [Nameprep]. Before encoding an internationalized domain name in an > URI, this preparation step SHOULD be applied. However, the URI > resolver MUST also apply any steps required as part of domain name > resolution by [IDNA]. > >The above statement says that for all domain names (note that the term >"IDN" is defined to include the existing ASCII domain names) >one should apply nameprep. This might be fine but it makes sense >stating this explicitly. The ToASCII in IDNA does not apply nameprep >to all-ASCII labels. The idea was simply to say: We RECOMMEND that you apply the IDNA rules already when you create an URI. What these rules are is up to IDNA. If IDNA says that their preparation of ascii-only labels is the identity operation, then we recommend that you apply that (i.e. do nothing), and not something else. If you see a way to make this clearer, please tell me. >Always applying nameprep will have the effect >of downcasing the ASCII characters in all ASCII labels, which IDNA does not >do. And of course we don't want to do either. >Which are the "any steps required as part of domain name resolution" >above? I can't figure out to what it might refer. That's the nameprep and related checking that the client has to do when it resolves a domain name. In IDNA terms, 'client' would be easy to understand. But using the word 'client' in an URI context doesn't work, so I tried to word around it. Any improved wording appreciated. >Finally, is the intent that nameprep always be applied before characters >are encoded in UTF-8? Then it makes sense stating that in the first real >paragraph on page 4. No. In the context e.g. of IRIs, the conversion from an IRI to an URI would not do nameprep. Regards, Martin. From owner-idn@ops.ietf.org Thu Oct 31 07:25:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15925 for ; Thu, 31 Oct 2002 07:25:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187EFa-000Oko-00 for idn-data@psg.com; Thu, 31 Oct 2002 04:16:38 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 187EFY-000OkW-00 for idn@ops.ietf.org; Thu, 31 Oct 2002 04:16:36 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id F297F778; Thu, 31 Oct 2002 21:16:31 +0900 (JST) Message-Id: <4.2.0.58.J.20021031150537.027bc058@localhost> X-Sender: duerst@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 31 Oct 2002 15:07:28 +0900 To: Paul Hoffman / IMC , Kenneth Whistler , idn@ops.ietf.org, "Mark Davis" From: Martin Duerst Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt In-Reply-To: References: <200210230112.SAA28197@birdie.sybase.com> <200210230112.SAA28197@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.2 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Paul, Can you (or somebody else) tell us where the right place is? Also, it seems that this WG has a much clearer need than many/ most WGs on this issue, and so it may be helpful to document that need clearly enough as a need of the WG, rather than as an idea of some individuals. Regards, Martin. At 19:02 02/10/22 -0700, Paul Hoffman / IMC wrote: >Wait, wait! This is the *wrong place* for this debate. > >The IETF has fixed guidelines for submitting Internet Drafts. We cannot >change those guidelines in the IDN WG. > >--Paul Hoffman, Director >--Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Oct 31 07:26:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16148 for ; Thu, 31 Oct 2002 07:26:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187EFY-000OkZ-00 for idn-data@psg.com; Thu, 31 Oct 2002 04:16:36 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 187EFV-000OkM-00 for idn@ops.ietf.org; Thu, 31 Oct 2002 04:16:34 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 3F4A5186D; Thu, 31 Oct 2002 21:16:26 +0900 (JST) Message-Id: <4.2.0.58.J.20021031145608.0497be88@localhost> X-Sender: duerst@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 31 Oct 2002 15:04:58 +0900 To: "Mark Davis" , "Kenneth Whistler" , , "Mark Davis" , "Paul Hoffman / IMC" From: Martin Duerst Subject: Re: UTF-8 in Internet Drafts (was Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt) In-Reply-To: <007101c27a4b$2b8a8770$8900a8c0@c1340594a> References: <200210230112.SAA28197@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.7 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have to fully agree with Mark. Getting the policy changed would be great. For James' document, the us-ascii version is just a bunch of numbers. No help to those who don't know Chinese characters, and no help to those who do. Just a waste of bits and paper, even if the topic may be important and interesting. I also was asked to put a lot of examples into draft-duerst-iri. Very tough indeed, because these would have to be non-ASCII examples. I think as a first step, the IETF should start to accept drafts in parallel in US-ASCII and UTF-8 (the later with an extension of .tx8 or so). I'm very sure both Mark and me would be ready to help the IETF and the secretariat to get there. I also had some discussions with Marshal Rose in Yokohama to extend the XML2RFC format a bit so that 'the right thing' would happen for both versions. We didn't get very far yet, but should pick it up again. Regards, Martin. At 21:17 02/10/22 -0700, Mark Davis wrote: >I didn't say the *IDN WG* itself could change that. What I said was >"Would there be any way to get the policy on the format of internet >drafts to be amended to allow UTF-8? It is pretty painful trying to >read documents when the actual characters cannot be used." > >I have no idea what the process that the Powers That Be have for >deciding the formats for internet drafts. I simply hope that that >policy gets changed, since it has gotten to the point that anyone who >wants to can read and write UTF-8 documents; various tools to do so >are free and easily available. > >Mark >__________ >http://www.macchiato.com >$Bcw("(B $Bc`W&(Bppur si muove$Bc`Ycv%3(B > >----- Original Message ----- >From: "Paul Hoffman / IMC" >To: "Kenneth Whistler" ; ; "Mark >Davis" >Sent: Tuesday, October 22, 2002 19:02 >Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt > > > > Wait, wait! This is the *wrong place* for this debate. > > > > The IETF has fixed guidelines for submitting Internet Drafts. We > > cannot change those guidelines in the IDN WG. > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > > From owner-idn@ops.ietf.org Thu Oct 31 08:19:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17896 for ; Thu, 31 Oct 2002 08:19:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187F4y-0001WL-00 for idn-data@psg.com; Thu, 31 Oct 2002 05:09:44 -0800 Received: from crow.verisign.com ([216.168.237.103]) by psg.com with esmtp (Exim 3.36 #2) id 187F4w-0001W5-00 for idn@ops.ietf.org; Thu, 31 Oct 2002 05:09:42 -0800 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA08232 for ; Thu, 31 Oct 2002 08:09:41 -0500 (EST) Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 08:09:41 -0500 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD603370141@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: idn@ops.ietf.org Subject: RE: UTF-8 in Internet Drafts (was Re: [idn] I-D ACTION:draft-jsen g-idn-admin-01.txt) Date: Thu, 31 Oct 2002 08:09:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Spam-Status: No, hits=-4.7 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > I have to fully agree with Mark. Getting the policy changed would > be great. For James' document, the us-ascii version is just a bunch > of numbers. No help to those who > don't know Chinese characters, and no help to those who do. Just > a waste of bits and paper, even if the topic may be > important and interesting. I-Ds can be submitted in PostScript format if that helps, though a text version (that can be different due to issues with figures and non-ASCII characters) is still required to have both published. -Scott- From owner-idn@ops.ietf.org Thu Oct 31 11:27:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29255 for ; Thu, 31 Oct 2002 11:27:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187Hyy-000CdF-00 for idn-data@psg.com; Thu, 31 Oct 2002 08:15:44 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 187Hyu-000Ccp-00 for idn@ops.ietf.org; Thu, 31 Oct 2002 08:15:40 -0800 Received: from [165.227.249.21] (165-227-249-21.client.dsl.net [165.227.249.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VGFbW22688 for ; Thu, 31 Oct 2002 08:15:37 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4.2.0.58.J.20021031150537.027bc058@localhost> References: <200210230112.SAA28197@birdie.sybase.com> <200210230112.SAA28197@birdie.sybase.com> <4.2.0.58.J.20021031150537.027bc058@localhost> 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: Thu, 31 Oct 2002 08:15:14 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-jseng-idn-admin-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.6 required=5.0 tests=HABEAS_SWE,IN_REP_TO,REFERENCES,SPAM_PHRASE_05_08 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:07 PM +0900 10/31/02, Martin Duerst wrote: >Can you (or somebody else) tell us where the right place is? The right place should be ietf@ietf.org. I say "should" because that is the proper forum, not because I am suggesting that you take this debate there. It has been discussed repeatedly there, with no resolution. You could bring it there, of course; if you do, it would be polite if you read the archives first. Note that being polite is at all a proven requirement for the IETF discussion list... >Also, it seems that this WG has a much clearer need than many/ >most WGs on this issue, It is, as far as I can tell, the *only* WG that has any need. The other value of UTF-8 Internet Drafts is that document authors can spell their names correctly. (For those not following closely, Martin actually does not have a "ue" in his last name, and Patrik actually does not have either an "a" or an "o" in his last name.) > and so it may be helpful to document >that need clearly enough as a need of the WG, rather than as >an idea of some individuals. Well, you have to define "need". It might be difficult to do U+xxxx-to-visual mapping for the draft in question, but is that really a "need"? It is rude for you and Patrik and many others to have to misspell your name in the documents you write, but is that really a "need"? Needs and desires are quite different things. My suggestion is that you simply write up a carefully-scoped Internet Draft on the topic and submit it. Be sure to have a mailing list for the draft, and be sure to invite at least a few ADs to the list early on. Starting a "discussion" on the IETF mailing list is 99.9% assured to go nowhere without an Internet Draft behind it. With an Internet Draft, you have a greater chance of success. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Oct 31 16:16:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15471 for ; Thu, 31 Oct 2002 16:16:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187MWo-0005hQ-00 for idn-data@psg.com; Thu, 31 Oct 2002 13:06:58 -0800 Received: from [61.169.175.1] (helo=KLENSIN-VAIO) by psg.com with esmtp (Exim 3.36 #2) id 187MWl-0005hA-00; Thu, 31 Oct 2002 13:06:56 -0800 Date: Thu, 31 Oct 2002 16:06:52 -0500 From: John C Klensin To: "Hollenbeck, Scott" , idn@ops.ietf.org Subject: RE: UTF-8 in Internet Drafts (was Re: [idn] I-D ACTION:draft-jsen g-idn-admin-01.txt) Message-ID: <22338404.1036080412@localhost> In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD603370141@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD603370141@vsvaposta l3.prod.netsol.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 31 October, 2002 08:09 -0500 "Hollenbeck, Scott" wrote: >> I have to fully agree with Mark. Getting the policy changed >> would be great. For James' document, the us-ascii version >> is just a bunch of numbers. No help to those who >> don't know Chinese characters, and no help to those who do. >> Just a waste of bits and paper, even if the topic may be >> important and interesting. > > I-Ds can be submitted in PostScript format if that helps, > though a text version (that can be different due to issues > with figures and non-ASCII characters) is still required to > have both published. Assuming, obviously incorrectly, that the same "simultaneous posting in text and PS or PDF" principle applied to I-Ds as well as RFCs, this one was sent to the I-D administrator in text and pdf formats. The latter was discarded. If we would like a PDF alternative, I think that is a small matter of the IESG expanding the rules. On the other hand, "post in UTF-8 as an _alternative_ to text strikes me as a bad idea: realistically, few of us have UTF-8 capable display systems that can display any Unicode character. Citing Paul's examples, I can personally see Patrik's or Martin's names displayed correctly, but the Chinese characters in "draft-jseng-idn-admin..." turn into either black blotches (losing information) or back into the Unicode code points (which are present already). James and the rest of the JET team have been discussing (at my request) ways to present the characters in ASCII text that would make the document more comprehensible than the code points alone for those reading the document in ASCII text. A URL for the PDF has been posted, and the next version will presumably be submitted in Postscript as well (and will probably contain a pointer to the PDF version). But, speaking for myself, I would far prefer clarity and unambiguousness in an I-D to a religious principle. At this stage, "permit I-Ds to be submitted in UTF-8" is, for too large a percentage of the community, too close to a religious principle at the expense of clarity. And, while this document was copied to the IDN list for information, neither the document nor its format are task items for this WG. john From owner-idn@ops.ietf.org Thu Oct 31 17:48:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18902 for ; Thu, 31 Oct 2002 17:48:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187O2X-000Clc-00 for idn-data@psg.com; Thu, 31 Oct 2002 14:43:49 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 187O2V-000ClO-00 for idn@ops.ietf.org; Thu, 31 Oct 2002 14:43:47 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04956; Thu, 31 Oct 2002 15:43:45 -0700 (MST) Received: from localhost (vpn-129-156-96-82.EMEA.Sun.COM [129.156.96.82]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g9VMhhL15751; Thu, 31 Oct 2002 23:43:43 +0100 (MET) Date: Thu, 31 Oct 2002 23:40:46 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: idn-uri document To: Martin Duerst Cc: Erik Nordmark , idn@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > Ah, I see, of course the resolvers pass things through and then > pass the negative result back, so they don't actually reject it. > So now the sentence reads: > > However, such syntax should never be used, and will never be > resolved because no such domains will be registered. ok > >The defined syntax rules for declare certain ASCII domain names illegal > >(such as *.example.org). Where is the check for illedgal names assumed to > >be performed? For IDNA it probably makes sense to only apply this types > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name > >registrations and not do such checks in the clients. > > This is an IDNA question, not a idn-uri question. As far as I remember, > the idea was to have the checks done on the clients, too (with some > leeway for unassigned characters to stay forward-compatible with > new character assignements). The reason for this was to create > pressure on registries to follow the rules. My point is that the idn-uri document is more restrictive in its syntax than the IDNA document. I don't know if this is a good idea or a bad idea, and we need to understand which type of idea it is. > > >The above statement says that for all domain names (note that the term > >"IDN" is defined to include the existing ASCII domain names) > >one should apply nameprep. This might be fine but it makes sense > >stating this explicitly. The ToASCII in IDNA does not apply nameprep > >to all-ASCII labels. > > The idea was simply to say: We RECOMMEND that you apply the IDNA rules > already when you create an URI. What these rules are is up to IDNA. > If IDNA says that their preparation of ascii-only labels is the > identity operation, then we recommend that you apply that (i.e. do > nothing), and not something else. If you see a way to make this clearer, > please tell me. It is the identity operation for ASCII-only labels (plus some checks that will reject certain labels). If you want to do that part, but not apply the Punycode step then I think you need to explicitly state that one should apply ToASCII without the punycode step (and other steps that don't make sense if there are any). > >Which are the "any steps required as part of domain name resolution" > >above? I can't figure out to what it might refer. > > That's the nameprep and related checking that the client has to > do when it resolves a domain name. In IDNA terms, 'client' would > be easy to understand. But using the word 'client' in an URI context > doesn't work, so I tried to word around it. Any improved wording > appreciated. In that case I think refering to ToASCII would be best. > >Finally, is the intent that nameprep always be applied before characters > >are encoded in UTF-8? Then it makes sense stating that in the first real > >paragraph on page 4. > > No. In the context e.g. of IRIs, the conversion from an IRI to an URI > would not do nameprep. OK. Then it makes sense stating that explicitly somewhere. Erik