From owner-idn@ops.ietf.org Sat Jun 1 01:15:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12735 for ; Sat, 1 Jun 2002 01:15:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17E0sZ-00005f-00 for idn-data@psg.com; Fri, 31 May 2002 21:52:39 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17E0sY-00005I-00 for idn@ops.ietf.org; Fri, 31 May 2002 21:52:38 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17E0sX-0000oD-00 for ; Fri, 31 May 2002 21:52:37 -0700 Date: Sat, 1 Jun 2002 04:52:37 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020601045237.GB2664@nicemice.net> Reply-To: IETF idn working group References: <3CF714F5.B58C2096@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF714F5.B58C2096@trab.se> User-Agent: Mutt/1.3.28i Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Oscarsson wrote: > Why is it that IETF can change the definition on for example what > characters are allowed in host names without an identifer of some > kind, That's not what we're doing. In data intended for machine consumption (protocol messages, function arguments, machine-readable file formats, etc) we are insisting that domain names continue to be ASCII-only; non-ASCII domain names may appear only where they are explicitly invited by new protocols/interfaces/formats (or new versions of old ones). In data intended for human consumption (like email message bodies and user interfaces) we (IDNA) are being more lax, and encouraging domain names to use the same charset that is used for all text in that context. The rationale is that compared to machines, humans are better able to cope with change, and much less tolerant of unintelligible garbage. (There is a case to be made against this laxity, and Eric has made it.) > For example, the URI definition have changed making those applications > following the original specification reject what later revisions see > as valid URIs. That's fine. If the only difference between the old standard and the new standard is that old software rejects things that new software accepts, that's the best you can hope for. What's bad is if old software and new software both accept the same things, but behave differently. That's the situation we're afraid of with 8-bit domain names in DNS. Existing DNS servers already accept 8-bit names in queries. If we were to declare that such queries must now be handled differently, we'd create interoperability problems. AMC From owner-idn@ops.ietf.org Sun Jun 2 04:26:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12010 for ; Sun, 2 Jun 2002 04:26:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EQS1-0000Cp-00 for idn-data@psg.com; Sun, 02 Jun 2002 01:10:57 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17EQRu-0000CA-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 01:10:50 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g528AmP27581 for ; Sun, 2 Jun 2002 10:10:48 +0200 (METDST) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g528AlT27577 for ; Sun, 2 Jun 2002 10:10:47 +0200 (METDST) Message-ID: <3CF9D327.99DDC5D8@trab.se> Date: Sun, 02 Jun 2002 10:11:19 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: >That's not what we're doing. In data intended for machine consumption >(protocol messages, function arguments, machine-readable file formats, >etc) we are insisting that domain names continue to be ASCII-only; >non-ASCII domain names may appear only where they are explicitly invited >by new protocols/interfaces/formats (or new versions of old ones). > >What's bad is if old software and new software both accept the same >things, but behave differently. That's the situation we're afraid of >with 8-bit domain names in DNS. Existing DNS servers already accept >8-bit names in queries. If we were to declare that such queries must >now be handled differently, we'd create interoperability problems. But domain names in use today are not ASCII-only. I know at least two DNS servers serving names using UTF-8 (Microsofts and .NU-bind). IDNA will change how things are handle. Applications that before sent UTF-8 will now send ACE-names breaking what worked before. This creates interoperability problems. It will force changes in DNS servers, despite IDNA saying that no changes are needed in DNS servers. The .Nu-bind and Microsoft servers will have to be changed so they can both recognise the old native UTF-8 names and the new ACE-names, for the same name. So you see, IDNA will break the current handling of non-ASCII names in DNS. As things will break, why not standardise the usage of non-ASCII in domain names. This would result in some servers breaking, but will give better stability for the future. Dan From owner-idn@ops.ietf.org Sun Jun 2 05:08:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12220 for ; Sun, 2 Jun 2002 05:08:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ERBV-0001wZ-00 for idn-data@psg.com; Sun, 02 Jun 2002 01:57:57 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17ERBS-0001wI-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 01:57:54 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g528vqR12765 for ; Sun, 2 Jun 2002 10:57:52 +0200 (METDST) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g528vls12750; Sun, 2 Jun 2002 10:57:51 +0200 (METDST) Message-ID: <3CF9DE37.1A360FF9@trab.se> Date: Sun, 02 Jun 2002 10:58:31 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: klensin@jck.com, idn@ops.ietf.org Subject: [idn] Using a new class for IDN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin published the idea to use a new class in DNS for IDN. As I now feel that there is no way to stop IDNA, I have looked on how to introduce native handling of non-ASCII in DNS in a easy way. While it can be done by EDNS and a new label type, I think a cleaner, and probably easier to implement, way is to use a new class. Using a new class you get: - a simple flag telling the DNS server that all text data (both labels and other) are in a well defined encoding of UCS. - clients get a error response if server do not support new class. Telling the client to retry using old IN class. - Basic support in DNS can be added by just defining all records in IN and new class. When in IN, use ACE encoded labels. When in new class, use UCS. A more efficient implementation can be added later. - A clean break from the old DNS world. - Compared to IDNA you get the same native encoding of characters everywhere (all labels get internationalised, and text fields like those in HINFO and TXT gets well defined) and case can be preserved in responses. I could write a draft for this, if some of you would support it. IDNA as it is today, does complicate the above way in at least two ways: - The count of characters that can fit into 63 octets differ when using ACE-names and native UCS-names. The above solution is very simple if we can require all names to fit in 63 octets. Then no new label types are needed and the DNS server use exactly the same records in both classes, only encoding in labels differ. - IDNA does not define that the same ACE/string preparation should be used in all labels. To make things easier for the future, IDNA should require that the IDN in the ToUnicode form must not be longer than 63 octets. That is, both the ACE-form and the UCS form must fit in 63 octets. Do we plan for a future with a fully internationalised DNS now? Or maybe we do not need one? Regards, Dan From owner-idn@ops.ietf.org Sun Jun 2 05:10:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12236 for ; Sun, 2 Jun 2002 05:10:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ERFk-00026K-00 for idn-data@psg.com; Sun, 02 Jun 2002 02:02:20 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17ERFX-00025w-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 02:02:07 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17ERFW-00055w-00 for ; Sun, 02 Jun 2002 02:02:06 -0700 Date: Sun, 2 Jun 2002 09:02:06 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020602090206.GA19405@nicemice.net> Reply-To: IETF idn working group References: <3CF9D327.99DDC5D8@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF9D327.99DDC5D8@trab.se> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Oscarsson wrote: > IDNA will change how things are handle. Applications that before sent > UTF-8 will now send ACE-names breaking what worked before. Applications that started using proprietary IDN techniques before anything was standardized knew the risk they were taking. > The .Nu-bind and Microsoft servers will have to be changed so they can > both recognise the old native UTF-8 names and the new ACE-names, for > the same name. You don't need to change the servers, you merely need to add the ACE forms to the zone files. One could write a perl script to do that. > As things will break, why not standardise the usage of non-ASCII in > domain names. I have no problem with that, but as long as you're willing to break things, why not segregate the non-ASCII requests using EDNS or a new class, so that things break in a predictable fashion rather than getting randomly misinterpreted? AMC From owner-idn@ops.ietf.org Sun Jun 2 08:54:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14011 for ; Sun, 2 Jun 2002 08:54:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EUj0-000Ani-00 for idn-data@psg.com; Sun, 02 Jun 2002 05:44:46 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17EUiu-000AnC-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 05:44:41 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g52CidWa000314 for ; Sun, 2 Jun 2002 14:44:39 +0200 To: idn@ops.ietf.org Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> In-Reply-To: <25020324.1022763672@localhost> (Patrik =?iso-8859-1?q?F=E4ltstr=F6m's?= message of "Thu, 30 May 2002 13:01:12 +0200") From: simon+idn@josefsson.org Date: Sun, 02 Jun 2002 14:44:40 +0200 Message-ID: Lines: 50 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [Resending with different From: address.] Patrik Fältström writes: > --On 2002-05-30 12.16 +0200 Simon Josefsson wrote: > >> This is interesting -- has the Unicode consortium promised to always >> update the CK normalization tables in a forward compatible way? > > Yes. The reference for that statement seem to be (correct me if I'm wrong) http://www.unicode.org/unicode/standard/policies.html: ,---- | Normalization. Once a character is encoded, its canonical combining | class and decomposition mapping will not be changed in a way that will | destabilize normalization. `---- Which looks good. However, reading on: ,---- | The decomposition mapping may only be changed at all in the following | _exceptional_ set of circumstances: | | + when there is a clear and evident mistake identified in the Unicode | Character Database (such as a typographic mistake), and | | + when that error constitutes a clear violation of the identity | stability policy (#4), and | | + when the correction of such an error does not violate constraints (a)-(d) `---- So it appears as if the statement isn't strictly true? A further security consideration of IDNA could be that whenever such modifications is done in the Unicode standards, they may be exploited and it should be an operational consideration to never register domains, issues PKIX certifices for domains, create Kerberos realms, create PGP keys, etc, for IDNs that contains characters that have their decomposition mapping changed by the Unicode consortium. It seems as if a modification of this kind occured between Unicode 3.0 and 3.1: http://www.unicode.org/versions/corrigendum2.html. The conclusion here is that this isn't a practical problem -- only one character changed normalization between 3.0 and 3.1 and none between 3.1 and 3.2 AFAIK. I am more worried about the transcoding problem. From owner-idn@ops.ietf.org Sun Jun 2 09:01:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14108 for ; Sun, 2 Jun 2002 09:01:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EUgd-000Aht-00 for idn-data@psg.com; Sun, 02 Jun 2002 05:42:19 -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 17EUgZ-000Ahe-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 05:42:15 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g52CgBWa000302 for ; Sun, 2 Jun 2002 14:42:13 +0200 To: idn@ops.ietf.org Subject: [idn] Stringprep editorial comment From: simon+idn@josefsson.org Date: Mon, 27 May 2002 22:14:56 +0200 Message-ID: Lines: 66 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.1 required=5.0 tests=NO_REAL_NAME,UNIFIED_PATCH,DATE_IN_FUTURE version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk [Resending with different From: address.] It would have saved me some confusion if it was stated early that stringprep only takes Unicode is input to the processing. Right now it says "text strings" up until it starts to discuss the output of the process, where it begins to talk about Unicode. One could get the impression that stringprep is a framework for preparing all kind of text strings into canonicalized Unicode strings, where it is in fact only about preparing Unicode text strings. Sentences like the following support that view (from Introduction): "these profiles will allow users to enter internationalized text strings in applications and have the highest chance of getting the content of the strings correct." That sentence doesn't reflect what will happen in typical internationalized systems (like, on _my_ machine) -- many systems enter internationalized text strings in charsets other than Unicode, and must convert it into Unicode before stringprep is useful. My $.2 solution: --- draft-hoffman-stringprep-03.txt.orig Mon May 27 21:38:42 2002 +++ draft-hoffman-stringprep-03.txt Mon May 27 22:08:02 2002 @@ -25,7 +25,7 @@ Abstract -This document describes a framework for preparing text strings in order +This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company @@ -92,7 +92,7 @@ behaviors that make it difficult to compare text in a consistent fashion. -This document specifies a framework of text processing rules. Other +This document specifies a framework of text processing rules for text in Unicode format. Other protocols can create profiles of these rules; these profiles will allow users to enter internationalized text strings in applications and have the highest chance of getting the content of the strings correct. @@ -100,6 +100,13 @@ they think is the same string into two different input mechanisms, the strings should match on a character-by-character basis. +This framework does not describe how data is translated from other +characters into Unicode characters. Systems that uses non-Unicode +input methods must use a consistent way to transcode data into Unicode +before using this framework. In such systems, the transcoding +algorithm is a critical part of enabling secure and "correct" +operation of internationalized text strings. + In addition to helping string matching, profiles of stringprep can also exclude characters that should not normally appear in text that is used in the protocol. The profile can prevent such characters by changing the @@ -753,7 +760,10 @@ Because it is impossible to map similar-looking characters without a great deal of context such as knowing the fonts used, stringprep does nothing to map similar-looking characters together nor -to prohibit some characters because they look like others. +to prohibit some characters because they look like others. Nor does it +do anything to assure that any algorithms translating characters +from non-Unicode into Unicode produce the same output in all +implementations. 9. IANA Considerations From owner-idn@ops.ietf.org Sun Jun 2 09:01:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14123 for ; Sun, 2 Jun 2002 09:01:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EUkC-000AtD-00 for idn-data@psg.com; Sun, 02 Jun 2002 05:46: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 17EUk6-000Aso-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 05:45:54 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.3/8.12.3) with ESMTP id g52CjqWa000326 for ; Sun, 2 Jun 2002 14:45:53 +0200 To: idn@ops.ietf.org Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings From: simon+idn@josefsson.org References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost> <001e01c207ee$64eb5370$2b19fea9@temp> <26138688.1022782312@localhost> In-Reply-To: <26138688.1022782312@localhost> (Patrik =?iso-8859-1?q?F=E4ltstr=F6m's?= message of "Thu, 30 May 2002 18:11:52 +0200") Date: Sun, 02 Jun 2002 14:45:53 +0200 Message-ID: Lines: 44 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [Resending with different From: address.] Patrik Fältström writes: > --On 2002-05-31 00.26 +0900 Soobok Lee wrote: > >> This issues were raised at the time of IDN WG last call, 3 months ago. > > And my answer was exactly the same then as now. We can not do better. If > Unicode is updated, you will either get inconsistency with the parties > using the new version of Unicode (if IDN is not upgraded) or inconsistency > with old registered names (if IDN is upgraded). > > The point is that the current scheme (a) trust Unicode when they say that > changes will be backward compatble and (b) IF they do an incompatible > change, we can at that point in time make the desicion -- we don't have to > decide now what path we take. Yes. I think it could be useful to have this discussion in the specifications, so it is stored in the collective memory. I am not sure everyone will remember or understand all subtle problems that will follow from changes in normalization mapping tables in a few years (I know I won't). Is the following reasonable? ,---- | If or when this specification is updated to use a more recent Unicode | normalization table, the new normalization table must be compared with | the old to spot backwards incompatible changes. If there are such | changes, they must be handled somehow, or there will be security as | well as operational implications. Methods to handle the conflicts | could include keeping the old normalization, or taking care of the | conflicting characters by operational means, or some other method. | | Implementations must never use more recent normalization tables than | the one referenced from this document, even though more recent | tables may be provided by operating systems. If an application is | unsure of which version of the normalization tables are in the | operating system, the application should include the normalization | tables itself. Using normalization tables other than the one | referenced from this specification may have security and operational | implications. `---- The transcoding problem is still open, it seems. From owner-idn@ops.ietf.org Sun Jun 2 11:02:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15521 for ; Sun, 2 Jun 2002 11:02:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EWfh-000G6N-00 for idn-data@psg.com; Sun, 02 Jun 2002 07:49:29 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17EWfe-000G69-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 07:49:26 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g52EmfHJ014538; Sun, 2 Jun 2002 16:48:41 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 2 Jun 2002 16:49:19 +0200 Received: from [10.0.1.45] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 2 Jun 2002 16:49:17 +0200 Date: Sun, 02 Jun 2002 16:04:23 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: simon+idn@josefsson.org, idn@ops.ietf.org Subject: Re: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings Message-ID: <35531132.1023033863@localhost> In-Reply-To: References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> <25523494.1022772058@localhost><001e01c207ee$64eb5370$2b19fea9@temp> <26138688.1022782312@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 02 Jun 2002 14:49:18.0933 (UTC) FILETIME=[AC958850:01C20A44] X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-06-02 14.45 +0200 simon+idn@josefsson.org wrote: > Is the following reasonable? I think so personally, but, the way a last call works (and the way I want to have it working as one of the editors of the documents) is that we during the last call period collect issues like this one, and _then_ we editors summarize and together with AD and wg chair rise a list with issues. I.e. the whole last call period is a "collection of issues" period. If we start updating the documents now, then comments will be based on multiple versions of the document -- which doesn't make things easier. So, I have added this issue to my list of things. paf From owner-idn@ops.ietf.org Sun Jun 2 11:11:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15686 for ; Sun, 2 Jun 2002 11:11:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EWfS-000G61-00 for idn-data@psg.com; Sun, 02 Jun 2002 07:49:14 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17EWfO-000G5n-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 07:49:10 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g52EmKbA014516; Sun, 2 Jun 2002 16:48:20 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 2 Jun 2002 16:48:58 +0200 Received: from [10.0.1.45] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 2 Jun 2002 16:48:55 +0200 Date: Sun, 02 Jun 2002 16:01:59 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: simon+idn@josefsson.org, idn@ops.ietf.org Subject: Re: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings Message-ID: <35522453.1023033719@localhost> In-Reply-To: References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 02 Jun 2002 14:48:57.0762 (UTC) FILETIME=[9FF71820:01C20A44] X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-06-02 14.44 +0200 simon+idn@josefsson.org wrote: > So it appears as if the statement isn't strictly true? This is also true. I am discussing the issue about 3.1 versus 3.2 with officers of the Unicode Consortium as we speak. I have requested some conclusion no later than friday this coming week, which I will report back to this wg (if not they send it to the mailing list directly). paf From owner-idn@ops.ietf.org Sun Jun 2 11:41:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16005 for ; Sun, 2 Jun 2002 11:41:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EXIe-000HmY-00 for idn-data@psg.com; Sun, 02 Jun 2002 08:29:44 -0700 Received: from smtprelay1.dc3.adelphia.net ([24.50.78.4]) by psg.com with esmtp (Exim 3.36 #1) id 17EXIY-000Hlr-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 08:29:38 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay1.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GX34DC00.60H; Sun, 2 Jun 2002 11:29:36 -0400 Message-ID: <001a01c20a4a$10973d80$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: , Cc: "Unicode Mailing List" References: <200205300842.g4U8gl209938@odin.France.Sun.COM> <25020324.1022763672@localhost> Subject: [idn] Re: Last Call: Preparation of Internationalized Strings Date: Sun, 2 Jun 2002 08:27:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Simon, There have been two corrections to normalization since Unicode 3.0. One involved a Chinese (Han) compatibility character that was mapped to the wrong "normal" character by error. The other involved a Yiddish (Hebrew) compatibility character that should have had a compatibility mapping, but did not, also by error. Both corrections were made to characters that are supposedly "very rare" in actual use, so that the real-world impact would be minimal. Neither one has anything to do with transcoding tables. I know you are very concerned that Unicode has "broken its promise" by making changes to the normalization tables after claiming they would not do so. I think if the corrections had not been made, there would have been an equal but opposite reaction that Unicode was too stubborn to correct its own mistakes, and that NFKC was rendered "useless" because of these two incorrect mappings. The pages explaining the corrigenda include lengthy, detailed explanations of why the Technical Committee felt they were necessary and justified. As someone already mentioned, one of the justifications given for the Yiddish change was that no normative references existed *yet* for the Unicode normalization tables (i.e. from IDN). This implies that once such normative references *do* exist, a similar decision to correct an error might not be made. I imagine these were very difficult decisions for the UTC, who knew that someone would jump on the changes immediately as evidence that normalization is inherently unstable and Unicode is therefore "not secure." It's true that we are relying on "enlightened statesmen" to make the right decisions and not, say, decide one day to add a compatibility mapping for U+00C6 LATIN CAPITAL LETTER AE that would break everything. The UTC has tried to assure us that such a thing will not happen, but in the end, all we can do is trust. -Doug Ewell Fullerton, California ----- Original Message ----- From: To: Sent: Sunday, June 02, 2002 5:44 am Subject: [idn] Re: :Re: Last Call: Preparation of Internationalized Strings [Resending with different From: address.] Patrik Fältström writes: > --On 2002-05-30 12.16 +0200 Simon Josefsson wrote: > >> This is interesting -- has the Unicode consortium promised to always >> update the CK normalization tables in a forward compatible way? > > Yes. The reference for that statement seem to be (correct me if I'm wrong) http://www.unicode.org/unicode/standard/policies.html: ,---- | Normalization. Once a character is encoded, its canonical combining | class and decomposition mapping will not be changed in a way that will | destabilize normalization. `---- Which looks good. However, reading on: ,---- | The decomposition mapping may only be changed at all in the following | _exceptional_ set of circumstances: | | + when there is a clear and evident mistake identified in the Unicode | Character Database (such as a typographic mistake), and | | + when that error constitutes a clear violation of the identity | stability policy (#4), and | | + when the correction of such an error does not violate constraints (a)-(d) `---- So it appears as if the statement isn't strictly true? A further security consideration of IDNA could be that whenever such modifications is done in the Unicode standards, they may be exploited and it should be an operational consideration to never register domains, issues PKIX certifices for domains, create Kerberos realms, create PGP keys, etc, for IDNs that contains characters that have their decomposition mapping changed by the Unicode consortium. It seems as if a modification of this kind occured between Unicode 3.0 and 3.1: http://www.unicode.org/versions/corrigendum2.html. The conclusion here is that this isn't a practical problem -- only one character changed normalization between 3.0 and 3.1 and none between 3.1 and 3.2 AFAIK. I am more worried about the transcoding problem. From owner-idn@ops.ietf.org Sun Jun 2 17:49:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19621 for ; Sun, 2 Jun 2002 17:49:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Eczd-0009NK-00 for idn-data@psg.com; Sun, 02 Jun 2002 14:34:29 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17EczU-0009N0-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 14:34:20 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17EczT-0006Xo-00 for ; Sun, 02 Jun 2002 14:34:19 -0700 Date: Sun, 2 Jun 2002 21:34:19 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Using a new class for IDN Message-ID: <20020602213419.GA24320@nicemice.net> Reply-To: IETF idn working group References: <3CF9DE37.1A360FF9@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF9DE37.1A360FF9@trab.se> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Oscarsson wrote: > - The count of characters that can fit into 63 octets differ when > using ACE-names and native UCS-names. True. As an extreme example, consider a label consisting of many repetitions of the same character outside plane 0. UTF-8, UTF-16, and UTF-32 all use 4 octets per character, while Punycode uses about 1. As an extreme example the other way, consider a label consisting of random characters from plane 0. UTF-16 uses 2 octets per character, while Punycode uses about 3.5. > To make things easier for the future, IDNA should require that the IDN > in the ToUnicode form must not be longer than 63 octets. ToUnicode does not output octets, it outputs code points. Which encoding form did you have in mind, UTF-8, UTF-16, or UTF-32? UTF-32 is always at least as large as UTF-16, sometimes larger, so I'll assume you don't want that one. If you go with UTF-16, then all existing ASCII labels over 31 characters become retroactively invalid, which seems very bad. If you go with UTF-8, then Indian scripts can fit only 21 characters per label, versus about 40 for ACE. It's seems a shame to halve the limit for a billion users. I'd really rather not. AMC From owner-idn@ops.ietf.org Sun Jun 2 21:25:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21584 for ; Sun, 2 Jun 2002 21:25:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EgOs-000KVm-00 for idn-data@psg.com; Sun, 02 Jun 2002 18:12:46 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17EgOn-000KVV-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 18:12:41 -0700 Received: from MASTER ([203.229.224.215]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g531CZA22924 for ; Mon, 3 Jun 2002 10:12:35 +0900 Message-ID: <001101c20a9b$b5585970$2b19fea9@temp> From: "Soobok Lee" To: References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> <006701c207f2$84b045e0$2b19fea9@temp> <20020530172957.GA9301@rap.rap.dk> Subject: [idn] utf8/legacy versioning Date: Mon, 3 Jun 2002 10:11:13 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thanks. IANA maintains this charset list: http://www.iana.org/assignments/character-sets But, it does not have any entry for revised legacy charset like "ks_c_5601-1992" nor "ksx1001:1992". Moreover, It does not have "utf8" charset entry, because "utf8" is just one of the encodings of the Universal Character Set, not an independent charset plus encoding like "ks_c_5601-1987". Everyone knows UCS(ISo10646) and Unicode (UTC) changes and expands over time. Does UCS (ISO10646) versioning strictly follow Unicode Versioning (UTC) ? Then, Why can't we see "utf8-3.1" or "utf8-3.2" for Unicode 3.1 and 3.2 recpectively? Many applications performs CaseFold3.x(IDN) or NFKC3.x(CaseFold3.x(IDN)) or legacy2Unicode(IDN) upon input texts or parameters and tags their outputs with "encoding='utf8'". But this loose tagging without the precise version of applied Unicode standard, will cause interoperability problems between the sending and receiveing application using different versions of unicode standard. they will have different criteria and assumptions about being normalized or casefolded. Loose versioning tradition/practice on encodings of both of Unicode and Local char sets are so profound and prevalent that we can't cure this situation in the foreseeable future. I can't imagine all XML applications switch to "utf8-3.2" from "utf8". Unicode and Legacy charsets are not designed to be used in rigorous identifier contexts, instead primarily for textual applications or printer/display industries. that explains the origin of loose versioning practice in UCS and local char sets. Some application may adhere to this proposed precise versioning convention and may reflect the changes on legacy and UCS mapping tables as frequently as possible. But, significant majority of other applications would be unwilling to or unable or too late to do that. This situation cause another interoperability problems among applications. Currently proposed IDN standard is at best an experimental one and not adequate for any mission critial use. Approximation and exception handling are inevitable in UCS/legacy handling, but it is not allowed in universal identifier system like DNS. Rather, directory/search approach would do better that job for internationalized *access* to domain names. Soobok Lee ----- Original Message ----- From: "Keld Jørn Simonsen" To: "Soobok Lee" Cc: Sent: Friday, May 31, 2002 2:29 AM Subject: Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt (in ksc5601-1987) > On Fri, May 31, 2002 at 12:56:05AM +0900, Soobok Lee wrote: > > By "additions", i mean the required new tag for new version of legacy encoding, like "ks_c_5601-1992" > > which should have been used, but never have been, as far as i know. Is there any central > > registry that maintain the correct tag values for vaiour versions of numorous legacy encodings ?? > > If not, how to ensure stable and interoperable legacy-2-unicode conversion among myriads of applications ? > > IANA has a registry of charsets, and many of them have mappings defined > for UCS. There is also an ISO register that has mappings between > legacy charsets and UCS, available at > http://www.dkuug.dk/cultreg/registrations/charmap > > Kind regards > Keld From owner-idn@ops.ietf.org Sun Jun 2 21:45:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21923 for ; Sun, 2 Jun 2002 21:45:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EgmT-000LPK-00 for idn-data@psg.com; Sun, 02 Jun 2002 18:37:09 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17EgmP-000LOm-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 18:37:05 -0700 Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g531aug02923; Sun, 2 Jun 2002 18:36:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <001101c20a9b$b5585970$2b19fea9@temp> References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> <006701c207f2$84b045e0$2b19fea9@temp> <20020530172957.GA9301@rap.rap.dk> <001101c20a9b$b5585970$2b19fea9@temp> Date: Sun, 2 Jun 2002 18:36:56 -0700 To: "Soobok Lee" , From: Paul Hoffman / IMC Subject: Re: [idn] utf8/legacy versioning Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:11 AM +0900 6/3/02, Soobok Lee wrote: >Moreover, It does not have "utf8" charset entry, because "utf8" is >just one of the encodings of the Universal >Character Set, not an independent charset plus encoding like "ks_c_5601-1987". Both your statement and your reasoning are wrong. UTF-8 has been a registered charset since RFC 2279 was issued. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Jun 2 22:16:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22503 for ; Sun, 2 Jun 2002 22:16:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EhC1-000Mex-00 for idn-data@psg.com; Sun, 02 Jun 2002 19:03:33 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17EhBx-000Mef-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 19:03:29 -0700 Received: from MASTER ([211.197.15.191]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5323LA23264; Mon, 3 Jun 2002 11:03:21 +0900 Message-ID: <000801c20aa2$ce2e5d80$2b19fea9@temp> From: "Soobok Lee" To: , "Paul Hoffman / IMC" References: <004d01c206d2$3521c6a0$fa424244@anhmca.adelphia.net> <006701c207f2$84b045e0$2b19fea9@temp> <20020530172957.GA9301@rap.rap.dk> <001101c20a9b$b5585970$2b19fea9@temp> Subject: Re: [idn] utf8/legacy versioning Date: Mon, 3 Jun 2002 11:03:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for your correction. UTF-8 (not utf8) is in that list. But, UTF-8 is a character encoding form of UCS and does not specify the specific set of supported characters in the numerous versions of UCS. That is the point where utf-8 and iso8859-1/ksc_5601_1987 differ. I.e., UTF-8 defines encoding schemes over UCS which has been an open set and will remains as an open set. UTF-8 , from its definition, cannot have versioing suffices, like "utf-8-3.2" or "utf-8-3.1". That's why "utf-8" should not be regardsed as a "genuine" charset, IMO. Correct me if i am wrong at some points. Thanks. Soobok Lee ----- Original Message ----- From: "Paul Hoffman / IMC" To: "Soobok Lee" ; Sent: Monday, June 03, 2002 10:36 AM Subject: Re: [idn] utf8/legacy versioning > At 10:11 AM +0900 6/3/02, Soobok Lee wrote: > >Moreover, It does not have "utf8" charset entry, because "utf8" is > >just one of the encodings of the Universal > >Character Set, not an independent charset plus encoding like "ks_c_5601-1987". > > Both your statement and your reasoning are wrong. UTF-8 has been a > registered charset since RFC 2279 was issued. > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Jun 2 22:28:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22615 for ; Sun, 2 Jun 2002 22:28:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EhNR-000NJN-00 for idn-data@psg.com; Sun, 02 Jun 2002 19:15:21 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17EhNM-000NIj-00 for idn@ops.ietf.org; Sun, 02 Jun 2002 19:15:16 -0700 Received: from MASTER ([211.197.15.191]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g532F8A23343; Mon, 3 Jun 2002 11:15:08 +0900 Message-ID: <001401c20aa4$73800800$2b19fea9@temp> From: "Soobok Lee" To: "Soobok Lee" , , "Paul Hoffman / IMC" Subject: Re: [idn] utf8/legacy versioning Date: Mon, 3 Jun 2002 11:14:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Moreover, if "utf-8" is to be a charset, it should have defined the specific set of characters and contains versioning tags. I suggest: "utf-8" is an encoding form for UCS. "utf8-8-3.1" and "utf-8-3.2" are charsets names which are snapshots of UCS with specified encoding form utf-8. This taxonomy would make this situation clear. Do not forget the set of characters of vague "utf-8" is not fixed from its definition. Soobok Lee ----- Original Message ----- From: "Soobok Lee" To: ; "Paul Hoffman / IMC" Sent: Monday, June 03, 2002 11:03 AM Subject: Re: [idn] utf8/legacy versioning > > Thanks for your correction. UTF-8 (not utf8) is in that list. > > But, UTF-8 is a character encoding form of UCS and does not specify the specific set of supported characters > in the numerous versions of UCS. That is the point where utf-8 and iso8859-1/ksc_5601_1987 differ. > I.e., UTF-8 defines encoding schemes over UCS which has been an open set and will remains as an open set. > > UTF-8 , from its definition, cannot have versioing suffices, like "utf-8-3.2" or "utf-8-3.1". > That's why "utf-8" should not be regardsed as a "genuine" charset, IMO. > > Correct me if i am wrong at some points. Thanks. > > Soobok Lee > > ----- Original Message ----- > From: "Paul Hoffman / IMC" > To: "Soobok Lee" ; > Sent: Monday, June 03, 2002 10:36 AM > Subject: Re: [idn] utf8/legacy versioning > > > > At 10:11 AM +0900 6/3/02, Soobok Lee wrote: > > >Moreover, It does not have "utf8" charset entry, because "utf8" is > > >just one of the encodings of the Universal > > >Character Set, not an independent charset plus encoding like "ks_c_5601-1987". > > > > Both your statement and your reasoning are wrong. UTF-8 has been a > > registered charset since RFC 2279 was issued. > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Jun 3 08:30:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09939 for ; Mon, 3 Jun 2002 08:30:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Eqnu-0000Su-00 for idn-data@psg.com; Mon, 03 Jun 2002 05:19:18 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Eqnj-0000Sd-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 05:19:07 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Eqnj-0009tK-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 12:19:07 +0000 Date: Mon, 03 Jun 2002 08:19:06 -0400 From: John C Klensin To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <69474120.1023092346@localhost> In-Reply-To: <20020530215238.GB32634@nicemice.net> References: <20020530215238.GB32634@nicemice.net> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 30 May, 2002 21:52 +0000 "Adam M. Costello" wrote: >> Since they are undefined, they are not alphabetic > > That's the one point where I don't follow you. If they are > undefined, then their alphabeticness is undefined, and hence > the proper way to compare them is undefined. RFC 1035 says > that comparisons of text strings must be case-insensitive > "without exception". Doing an exact match of 0x80-0xFF is > guaranteed to violate that requirement for every charset I > know of that uses the 8th bit. Yes, exactly. This is the problem that keeps leading me back to the belief that we have RRs whose labels are alphabetic (characters) and RRs whose labels are binary. If the former, and octet values of 0x80 and above are permitted, then I think _defined_ case mapping rules are required. Until and unless they are defined, the robustness principle argues fairly strongly that such values should not be sent or put into tables, since there is no predicting what servers will do with them (i.e., no specification of undefined behavior). By contrast, if one really has an RR with a binary label, I think it would violate the intent of the protocol to make comparisons with any of the bits masked, even if the relevant octets fall in the 0x00 through 0x7F range. > If you send a query containing an 8-bit name, I think you do > so at your own risk, because RFC 1035 doesn't say what the > server will do. And "do so at your own risk" and "different servers can do different things and still conform to the spec" amount, given the robustness principle and a commitment to interoperability, to a requirement to not do it at all. john From owner-idn@ops.ietf.org Mon Jun 3 08:38:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10129 for ; Mon, 3 Jun 2002 08:38:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Er03-00017R-00 for idn-data@psg.com; Mon, 03 Jun 2002 05:31:51 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Eqzz-000177-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 05:31:47 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Eqzu-0009vg-00; Mon, 03 Jun 2002 12:31:42 +0000 Date: Mon, 03 Jun 2002 08:31:42 -0400 From: John C Klensin To: "Eric A. Hall" cc: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <70229699.1023093102@localhost> In-Reply-To: <3CF64CE7.7AB11BF9@ehsco.com> References: <3CF64CE7.7AB11BF9@ehsco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 30 May, 2002 11:01 -0500 "Eric A. Hall" wrote: > John C Klensin wrote: >> >> The disagreement between kre and myself about how to read the >> spec is, indeed, I think the key to this issue. It should be >> noted that we disagree about two things, which are separate: >> >> (i) Whether the correct reading on the DNS specs is that >> "ASCII" versus "binary" is a function of RR type, or a >> function of the bits in the octets. I take the text to >> suggest that _only_ ASCII (note, ASCII, not LDH) is permitted >> in RR types defined in or by 1034/1035, but that "future" RR >> types (and Classes) can be defined to have binary labels. >> Robert takes it as permitted characters outside the ASCII >> range, with case handling undefined for those characters. > > You are both correct, but Robert is more correct. Note that > Robert didn't disagree with you "future" use. Essentially this > boils down to having biblical scholars arguing over how MUCH > they should love their neighbor. Well, I'm not sure, partially because I am not convinced that 1034/1035 permit (or require) an octet-by-octet interpretation. See below. Also, in the robustness principle, we have a rule, applicable to the DNS as to other Internet protocols, that governs the model for loving one's neighbor especially in cases of ambiguity. > There are three elements here: > > 1) The lower seven-bit range is definitely interpreted as > ASCII. For RRs whose labels are character strings, yes, certainly. > 2) The upper eight-bit range is definitely undefined for > those RRs and classes which do not have an > interpretation. While some new RR and/or class could > define an interpretation for the eight-bit range, the > existing RRs in the IN class treat this range as > undefined values. Yes. > 3) STD13 is quite clear that queries may contain eight-bit > codes. Yes. The question is whether this is appropriate (given both STD13 and the robustness principle) for RRs with character labels (i.e., the "existing" RRs in Class IN) for for an query. Or, put differently, while it is clear that eight-bit codes can be sent in a query (given the query structure and the ability to specify "ANY" as a query type, any other conclusion would lead to contradictions), it is not clear how a server should interpret such a query when it would match an RR with a character label. > So, taking all of the above into consideration, how do you > treat the eight-bit codes for existing RRs in the IN class, > where an interpretation has not been defined? You have to > treat them as undefined. Since they are undefined, they are > not alphabetic, and the non-alphabetic comparison rule kicks > in. As has been pointed out, "undefined" means "undefined" and, given interoperability and the robustness principle, something that should not be (attempted to be) used. It doesn't mean "non-alphabetic" -- that constitutes defining it. I believe that loving my neighbor, under the robustness principle, implies that I don't send that neighbor stuff that is undefined. And I believe that, under robustness principle, that neighbor should _accept_ anything I send it, but that its responses should avoid returning as a match anything that might not actually be a match, i.e., that something that is "undefined" doesn't match at all, regardless of the bit patterns. > Whether or not any of these RRs allow eight-bit codes to be > defined is a totally different question, but one which was > answered in the affirmative by RFC 2181. Yes. But in language that, given the matching rules and the above interpretation of "undefined" (which I would claim is our historic one), becomes almost as unclear as that in 1034/1035. > So, unless a new RR or class (or EDNS tag, or whatever) > defines some specific interpretation, the eight-bit codes are > to be treated as undefined codes, and must match exactly. Or, with equal or greater justification, "... to be treated as undefined codes, and not matched at all". john From owner-idn@ops.ietf.org Mon Jun 3 10:23:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15000 for ; Mon, 3 Jun 2002 10:23:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EsaJ-0006Yh-00 for idn-data@psg.com; Mon, 03 Jun 2002 07:13:23 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17Esa7-0006WV-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 07:13:11 -0700 Message-ID: <055101c20af2$5e7d7980$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Dan Oscarsson" , References: <3CF9D327.99DDC5D8@trab.se> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Date: Mon, 3 Jun 2002 07:32:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dan, You could add NeDNS to your list. And bettering the two you have listed, we already deal with the inevitable ACE requests that are being sporadically sent to the NeDNS servers at the various registries that we run. To allow for hosting the delegated IDN using existing nameservers, NeDNS also offers the ability for the delegatee host server to use only the ACE form. But, I do in fact agree with your observation that IDNA, even though heralded as being fully backward compatible, isnt such, and is also not forward looking which is the key issue at stake here I believe. Edmon ----- Original Message ----- From: "Dan Oscarsson" To: Sent: Sunday, June 02, 2002 4:11 AM Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt > Adam M. Costello wrote: > > >That's not what we're doing. In data intended for machine consumption > >(protocol messages, function arguments, machine-readable file formats, > >etc) we are insisting that domain names continue to be ASCII-only; > >non-ASCII domain names may appear only where they are explicitly invited > >by new protocols/interfaces/formats (or new versions of old ones). > > > >What's bad is if old software and new software both accept the same > >things, but behave differently. That's the situation we're afraid of > >with 8-bit domain names in DNS. Existing DNS servers already accept > >8-bit names in queries. If we were to declare that such queries must > >now be handled differently, we'd create interoperability problems. > > > But domain names in use today are not ASCII-only. I know at least > two DNS servers serving names using UTF-8 (Microsofts and .NU-bind). > IDNA will change how things are handle. Applications that before > sent UTF-8 will now send ACE-names breaking what worked before. > This creates interoperability problems. > It will force changes in DNS servers, despite IDNA saying that > no changes are needed in DNS servers. The .Nu-bind and Microsoft > servers will have to be changed so they can both recognise the > old native UTF-8 names and the new ACE-names, for the same name. > > So you see, IDNA will break the current handling of non-ASCII > names in DNS. As things will break, why not standardise the > usage of non-ASCII in domain names. This would result in > some servers breaking, but will give better stability for the future. > > Dan > > From owner-idn@ops.ietf.org Mon Jun 3 10:24:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15020 for ; Mon, 3 Jun 2002 10:24:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EseB-0006m8-00 for idn-data@psg.com; Mon, 03 Jun 2002 07:17:23 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17Ese6-0006ln-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 07:17:18 -0700 Message-ID: <056b01c20af4$d5e55630$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "IETF idn working group" References: <3CF9D327.99DDC5D8@trab.se> <20020602090206.GA19405@nicemice.net> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Date: Mon, 3 Jun 2002 07:50:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Adam M. Costello" > I have no problem with that, but as long as you're willing to break > things, why not segregate the non-ASCII requests using EDNS or a new > class, so that things break in a predictable fashion rather than getting > randomly misinterpreted? This is a misleading statement that you are making. non-ASCII requests are not "randomly misinterpreted", at least not in NeDNS, they get uniquely resolved into the intended domain name that a non-aware user is typing in. Adam, whether you like it or not, the reality is that non-ASCII request are reaching registry name servers and whether you resolve these domain names or not is the operator's choice. Resolve it and resolve customer support issues at the same time because existing users will be able to immediately get to multilingual domain names. Reject it and expect frustrated registrants asking you why their name doesnt work yet. At the end of the day, it is the registry's choice, but I would advise that...reject at your own peril... Just look at the support nightmare some registries have face by introducing names that do not yet work for most people... So, my point is that while it is all well that an IDNA standard will be published, the real world will have to have some sort of a transitional system that supports accurate resolution of non-ASCII requests so that existing users can access these names. Edmon From owner-idn@ops.ietf.org Mon Jun 3 10:24:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15081 for ; Mon, 3 Jun 2002 10:24:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ese2-0006lh-00 for idn-data@psg.com; Mon, 03 Jun 2002 07:17:14 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17Esdz-0006lQ-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 07:17:11 -0700 Message-ID: <055901c20af3$690214f0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Dan Oscarsson" , , References: <3CF9DE37.1A360FF9@trab.se> Subject: Re: [idn] Using a new class for IDN Date: Mon, 3 Jun 2002 07:40:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dan, As an advocate for a clean approach to IDN I would like to offer my support. Though I think EDNS is a better solution because IDN is really just another domain name and should exist in both classes, I dont mind seeing a new class being created for IDNs because I believe that the world wants a good forward looking architecture for IDN and will move towards the new class as it becomes available. Edmon ----- Original Message ----- From: "Dan Oscarsson" To: ; Sent: Sunday, June 02, 2002 4:58 AM Subject: [idn] Using a new class for IDN > John C Klensin published the idea to use a new class in DNS > for IDN. As I now feel that there is no way to stop IDNA, I have > looked on how to introduce native handling of non-ASCII in DNS > in a easy way. While it can be done by EDNS and a new label type, > I think a cleaner, and probably easier to implement, way is > to use a new class. Using a new class you get: > - a simple flag telling the DNS server that all text data (both > labels and other) are in a well defined encoding of UCS. > - clients get a error response if server do not support new class. > Telling the client to retry using old IN class. > - Basic support in DNS can be added by just defining all records > in IN and new class. When in IN, use ACE encoded labels. > When in new class, use UCS. A more efficient implementation can > be added later. > - A clean break from the old DNS world. > - Compared to IDNA you get the same native encoding of > characters everywhere (all labels get internationalised, and > text fields like those in HINFO and TXT gets well defined) and > case can be preserved in responses. > > I could write a draft for this, if some of you would support it. > > IDNA as it is today, does complicate the above way in at least two > ways: > - The count of characters that can fit into 63 octets differ > when using ACE-names and native UCS-names. > The above solution is very simple if we can require all > names to fit in 63 octets. Then no new label types are needed > and the DNS server use exactly the same records in both > classes, only encoding in labels differ. > - IDNA does not define that the same ACE/string preparation should > be used in all labels. > > To make things easier for the future, IDNA should require that > the IDN in the ToUnicode form must not be longer than 63 octets. > That is, both the ACE-form and the UCS form must fit in > 63 octets. > > > Do we plan for a future with a fully internationalised DNS now? > Or maybe we do not need one? > > Regards, > > Dan > > From owner-idn@ops.ietf.org Mon Jun 3 11:10:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17491 for ; Mon, 3 Jun 2002 11:10:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EtJZ-0009FI-00 for idn-data@psg.com; Mon, 03 Jun 2002 08:00:09 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17EtJU-0009EV-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 08:00:04 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17EtIC-000AJW-00; Mon, 03 Jun 2002 14:58:44 +0000 Date: Mon, 03 Jun 2002 10:58:44 -0400 From: John C Klensin To: Edmon Chung , Dan Oscarsson , idn@ops.ietf.org Subject: Re: [idn] Using a new class for IDN Message-ID: <79053184.1023101924@localhost> In-Reply-To: <055901c20af3$690214f0$0f01a8c0@neteka.inc> References: <055901c20af3$690214f0$0f01a8c0@neteka.inc> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 03 June, 2002 07:40 -0400 Edmon Chung wrote: > Hi Dan, > As an advocate for a clean approach to IDN I would like to > offer my support. Though I think EDNS is a better solution > because IDN is really just another domain name and should > exist in both classes, I dont mind seeing a new class being > created for IDNs because I believe that the world wants a good > forward looking architecture for IDN and will move towards the > new class as it becomes available. Edmon, A few observations: The advantage of both EDNS and a new Class approach is that they require explicit action on the part of the part of the client to get "idn" treatment of a name. Without that action, and agreement from the server in some appropriate form, nothing is going to happen, which means no heuristics about how names are to be interpreted, no nonsense strings showing up in front of users (at least with decent-quality implementations), etc. The disadvantage is what it always has been and what caused the WG (I think) to ignore these solutions from the beginning -- they are infrastructure changes, not quick fixes, and the WG has been focused on quick fixes. Between the two, I see a fairly similar tradeoff. EDNS is easier to think about in terms of incremental deployment, but raises complex issues about, e.g., handling of secondaries. "New class" gives us the opportunity --but also the probably-very-painful obligation-- to rethink almost everything and get it right this time. But let me repeat, and expand slightly, the advice I previously gave Dan in an off-list note. My "new class" I-D was nothing more than a sketch of how it might be done and what some of the issues would be about doing it. It does contain at least some of the justification, which ought to be useful, but it is (deliberately) notably short on fine details. David Lawrence has raised issues I didn't explicitly address as has, more recently, Eric Hall. What is going to be needed if anyone is to take "new class" seriously as a proposal (and not as yet-another attempted blocking action (of which I am not accusing anyone in particular, only noting that there have been far too many suspicions along those lines in the WG)) is a coherent internet draft that really does the case analysis and considers, and offers at least tentative solutions for, the many issues, questions, and loose ends. And, while I'll promise to read such a draft, I'm not going to be much help. IDNA and the various (incomplete) EDNS and new Class proposals ultimately differ in how they represent data, how the query stream is handled, and a number of other details. While --being very conservative about risks to the DNS and the Internet-- I still prefer the new Class one, I see far more of the important problems lying in the areas of acceptable character repertoires and matching rules for those characters that are permitted, and I've concluded that _those_ issues and people's expectations about them can't be dealt with in the DNS at all. So, if this really interests you, and Dan, and David, and anyone else who has read this far, _please_ go form yourselves into a design team and produce a comprehensive draft. Get it posted. And then have a discussion with Erik and Thomas as to whether to try to get it reviewed in this WG or in DNSEXT, as well as about its impact on the IDN/ IDNA proposals. But, while I wouldn't presume to speak for the ADs or the IDN WG, I can't imagine anyone taking "new Class" (or anything else) seriously as an alternative to the IDNA proposal at this late date unless there is a clear and complete I-D on the table. So, again, please start writing I-D text, rather than notes to the WG mailing list. And good luck. john From owner-idn@ops.ietf.org Mon Jun 3 11:51:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20394 for ; Mon, 3 Jun 2002 11:51:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EtxJ-000BYr-00 for idn-data@psg.com; Mon, 03 Jun 2002 08:41:13 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EtxE-000BY0-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 08:41:08 -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 130001; Mon, 03 Jun 2002 10:39:08 -0500 Message-ID: <3CFB8E0E.AC41126@ehsco.com> Date: Mon, 03 Jun 2002 10:41:02 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CF64CE7.7AB11BF9@ehsco.com> <70229699.1023093102@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > As has been pointed out, "undefined" means "undefined" and, > given interoperability and the robustness principle, something > that should not be (attempted to be) used. It doesn't mean > "non-alphabetic" -- that constitutes defining it. They are "undefined" for interpretation, but they are "defined" as eight-bit code values for the purposes of storage and transfer. Consider the lowly cache. What if a client and server exchange eight-bit domain names linked with an expiremental RR which the cache knows absolutely nothing about? What if eight-bit owner names are explicitly interpreted for that RR? Clearly there is only one interpretation that works in the distributed model. I suppose you could argue that the ~standard RRs from STD13 are special and do not have any such meaning, although I would argue against it. You could also argue that sending eight-bit codes with the ~standard RRs from STD13 is a bad idea but not prohibited and I would agree with you. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 3 13:17:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24472 for ; Mon, 3 Jun 2002 13:17:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EvCU-000GBL-00 for idn-data@psg.com; Mon, 03 Jun 2002 10:00:58 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EvCP-000GAk-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 10:00:53 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 130009; Mon, 03 Jun 2002 11:58:57 -0500 Message-ID: <3CFBA0C2.C0A70A0A@ehsco.com> Date: Mon, 03 Jun 2002 12:00:50 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: idn@ops.ietf.org Subject: Re: [idn] Using a new class for IDN References: <055901c20af3$690214f0$0f01a8c0@neteka.inc> <79053184.1023101924@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > attempted blocking action (of which I am not accusing anyone in > particular, only noting that there have been far too many > suspicions along those lines in the WG)) Unfortunately, your role gives these kinds of statements a lot more weight than you probably intend them to have. In response, I will say that the only blocking actions I have seen has been to shutdown critical analysis of IDNA. To wit: > from the beginning -- they are infrastructure changes, not quick > fixes, and the WG has been focused on quick fixes. Anybody who understands IDNA knows that it is anything but a quick fix. Oh sure, it lets registrars *sell* domains quickly, but its success with the user community hinges on every application in the world being upgraded to perform conversion. Furthermore, it is known that this will be a disruptive process which will absolutely cause interoperability failures. There is nothing fast or resolute about this. The only thing going for it is that it is backwards compatible. While that is a necessary attribute of any solution, it is not by itself a "quick fix" for anybody other than domain resellers. Most of the alternative proposals seemed to have recognized that. None of them have been attempts at derailing anything, AFAICT. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 3 15:07:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27879 for ; Mon, 3 Jun 2002 15:07:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ex09-000N28-00 for idn-data@psg.com; Mon, 03 Jun 2002 11:56:21 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ewzv-000N1D-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 11:56:07 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Ewzs-000AuW-00; Mon, 03 Jun 2002 18:56:04 +0000 Date: Mon, 03 Jun 2002 14:56:03 -0400 From: John C Klensin To: "Eric A. Hall" cc: idn@ops.ietf.org Subject: Re: [idn] Using a new class for IDN Message-ID: <93294759.1023116163@localhost> In-Reply-To: <3CFBA0C2.C0A70A0A@ehsco.com> References: <3CFBA0C2.C0A70A0A@ehsco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 03 June, 2002 12:00 -0500 "Eric A. Hall" wrote: >> attempted blocking action (of which I am not accusing anyone >> in particular, only noting that there have been far too many >> suspicions along those lines in the WG)) > > Unfortunately, your role gives these kinds of statements a lot > more weight than you probably intend them to have. Eric, _I_ have been accused, loudly and repeatedly, of intentionally attempting to block action. That isn't true, and I'm certainly not trying to give it weight. > In response, I will say that the only blocking actions I have > seen has been to shutdown critical analysis of IDNA. To wit: > >> from the beginning -- they are infrastructure changes, not >> quick fixes, and the WG has been focused on quick fixes. > > Anybody who understands IDNA knows that it is anything but a > quick fix. I completely agree. But I believe it is also correct to say that the WG has tended, over its lifetime, to focus its attention on things that appear to be quick fixes, in preference to options that would take longer but that might be more satisfactory. > Oh sure, it lets registrars *sell* domains quickly, but its > success with the user community hinges on every application in > the world being upgraded to perform conversion. Furthermore, > it is known that this will be a disruptive process which will > absolutely cause interoperability failures. There is nothing > fast or resolute about this. The only thing going for it is > that it is backwards compatible. While that is a necessary > attribute of any solution, it is not by itself a "quick fix" > for anybody other than domain resellers. Again, I agree. But domain resellers, others who believe that having "multilingual names" --somehow-- quickly are important, and the fear that, if the WG doesn't do something... Right Now... various sorts of interoperability catastrophies would occur, have been the sources of huge pressures on the WG to try to do _something_ that can be deployed quickly. And "deployed" has been defined in that context by ability to put names in tables and get them back out. One can believe that pattern was either good or bad, but I think it is indisputable that the WG has been operating under pressure --quite large by IETF averages-- to produce some solution quickly. Now, the fact that the WG has rejected the really lousy solutions proposed as "quick fixes" is to its credit. Similarly, it has avoided falling into the quick-fix traps that would have permitted efficient use of some (typically Latin-based) scripts other than English while pushing non-Latin-based and non-alphabetic scripts even further back, which is again to its credit. And it has struck some sort of balance between "quick" and careful consideration of alternatives and implications which has certainly not been as quick as some would like nor as careful as others would like -- if you subscribe to the principle that a successful consensus position is one with which everyone is equally unhappy, IDNA may be an excellent example. > Most of the alternative proposals seemed to have recognized > that. None of them have been attempts at derailing anything, > AFAICT. I don't think this is worth a long discussion at this stage, but the accusations have been made and repeated, especially in the direction of those of us who are concerned that IDNA (and DNS-based solutions generally) will not satisfy the requirement as seen by users, in the direction of some of those who have focused strongly on issues with a small family of scripts or languages, and in the direction of those who have proposed ideas but not protocols (in the form of I-Ds that were detailed enough to be analysed and seriously considered). john From owner-idn@ops.ietf.org Mon Jun 3 15:46:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28895 for ; Mon, 3 Jun 2002 15:46:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Exf5-000PYX-00 for idn-data@psg.com; Mon, 03 Jun 2002 12:38:39 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Exf0-000PYF-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 12:38:35 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Exey-000B20-00; Mon, 03 Jun 2002 19:38:32 +0000 Date: Mon, 03 Jun 2002 15:38:31 -0400 From: John C Klensin To: "Eric A. Hall" cc: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <95843624.1023118711@localhost> In-Reply-To: <3CFB8E0E.AC41126@ehsco.com> References: <3CFB8E0E.AC41126@ehsco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 03 June, 2002 10:41 -0500 "Eric A. Hall" wrote: >> As has been pointed out, "undefined" means "undefined" and, >> given interoperability and the robustness principle, something >> that should not be (attempted to be) used. It doesn't mean >> "non-alphabetic" -- that constitutes defining it. > > They are "undefined" for interpretation, but they are > "defined" as eight-bit code values for the purposes of storage > and transfer. ok > Consider the lowly cache. What if a client and server exchange > eight-bit domain names linked with an expiremental RR which > the cache knows absolutely nothing about? What if eight-bit > owner names are explicitly interpreted for that RR? Clearly > there is only one interpretation that works in the distributed > model. No, there are two. One is your interpretation, i.e., that all labels are to be construed as character strings, with ASCII and case mapping behavior in 0x00-0x7F and exact matching otherwise. The other is that true binary labels are permitted by the DNS spec: if they are, then 0x00-0x7F had better not be case-mapped and a cache must know how to interpret an RR in order to answer a query on that RR. I.e., my reading of RFC 1035, section 2.3.3, "Character Case",... For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, [...] is that "full binary octet capability" implies not only that those bits might be turned on, but that comparisons might be required to be binary (i.e., exact) ones, even within the 0x00-0x7F range. > I suppose you could argue that the ~standard RRs from STD13 > are special and do not have any such meaning, although I would > argue against it. And we would certainly continue to disagree, since I read "all parts... that are part of the official protocol" and "at present... However, future additions beyond current usage..." as saying exactly that. This is reinforced, for me, by section 3.1 of RFC 1034, which says, in part but domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. and The rationale for this choice is that we may someday need to add full binary domain names for new services; existing services would not be changed. which appears, to me, to constrain those "existing services" (which I take to be those "standard" RRs in Class IN) to ASCII. That interpretation makes non-ASCII octets in _their_ labels a protocol violation, not merely an "undefined" state -- see below. Now a slightly different reading of 1035 -- and, in particular, its syntax references to "character strings" -- globally prohibits binary labels (e.g., numbers with values > 255) as distinct from octet strings which might have the high bit of such octets set. That would, I think, be an unfortunate restriction on future extensibility, but it makes things a bit less complicated. But I can't get from "they are all characters" to "case-map ASCII graphics only, and exact-match everything else" -- it appears to me that matching rules for the above 0x7F range would then be strictly undefined until rules are standardized for their interpretation (in the existing RRs or otherwise). The advantage of that "character string" reading is that it would be possible to write RFCs that specify how those "high bit" octets should be processed. If "full binary" is permitted, then I think such octets are prohibited forever in the vintage-1035 "standard" RRs. > You could also argue that sending eight-bit > codes with the ~standard RRs from STD13 is a bad idea but not > prohibited and I would agree with you. I would accept that argument and then note that the robustness principle slides [generally] "sending [is a] bad idea" into "prohibited" rather quickly. john From owner-idn@ops.ietf.org Mon Jun 3 16:01:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29403 for ; Mon, 3 Jun 2002 16:01:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Exsh-0000PN-00 for idn-data@psg.com; Mon, 03 Jun 2002 12:52:43 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17Exsd-0000OX-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 12:52:39 -0700 Message-ID: <002d01c20b37$9cbb1b90$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "John C Klensin" , "Eric A. Hall" Cc: References: <3CFBA0C2.C0A70A0A@ehsco.com> <93294759.1023116163@localhost> Subject: Re: [idn] Using a new class for IDN Date: Mon, 3 Jun 2002 15:48:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John C Klensin" > > Oh sure, it lets registrars *sell* domains quickly, but its > > success with the user community hinges on every application in > > the world being upgraded to perform conversion. Furthermore, > > it is known that this will be a disruptive process which will > > absolutely cause interoperability failures. There is nothing > > fast or resolute about this. The only thing going for it is > > that it is backwards compatible. While that is a necessary > > attribute of any solution, it is not by itself a "quick fix" > > for anybody other than domain resellers. > > Again, I agree. But domain resellers, others who believe that > having "multilingual names" --somehow-- quickly are important, > and the fear that, if the WG doesn't do something... Right > Now... various sorts of interoperability catastrophies would > occur, have been the sources of huge pressures on the WG to try > to do _something_ that can be deployed quickly. And "deployed" > has been defined in that context by ability to put names in > tables and get them back out. I think it is more important for registrars as well as the more critical registrant to have multilingual domain names that are usable by the general audience quickly. That is the key I see the market demanding. Whether we use IDNA or EDNS or new class the transition is going to be as slow because the major problem is getting the new client propagated. The only real to addresss market demands is a good "Transitional Strategy". One which has to include a brute-force approach whereby the name server resolving a request containing a non-ascii domain request. While I find it kind of ironic, though not surprising that the so heralded "quick fix" method is not so "quick" afterall, perhaps our effort should now (that the IDNA thing is more or less ready) move towards a solution that is truly more "satisfactory" as you have mentioned. By the way, just to make it clear, this is not intended to block or stall the current IDNA effort, but pointing out the plain fact about a real world demand and a real world transition path that has to take place for multilingual domain names to become usable. Edmon From owner-idn@ops.ietf.org Mon Jun 3 16:23:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29862 for ; Mon, 3 Jun 2002 16:23:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EyF2-0001no-00 for idn-data@psg.com; Mon, 03 Jun 2002 13:15:48 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EyEx-0001nW-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 13:15:44 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 130056; Mon, 03 Jun 2002 15:13:48 -0500 Message-ID: <3CFBCE6C.545C5130@ehsco.com> Date: Mon, 03 Jun 2002 15:15:40 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3CFB8E0E.AC41126@ehsco.com> <95843624.1023118711@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > The other is that true binary labels are permitted by the DNS There is no such thing as a true binary label as far as the DNS transfer protocol and/or storage subsystem is concerned. Where there is a mapping, it occurs within the realm of the application that is using DNS, and not within the DNS network service itself. That is the only way which allows *any* new usages to be defined. Otherwise, no systems could ever tell what format *any* domain name was stored in. Not only would this include interpretations of eight-bit characters, but it would also include any case-specific ASCII alphabetic mappings which might be required for a given RR. For example, NB that RFC 1035 defined case-specific owner names for MB, MG, etc, but even those are compared using the simple rules. If we had different storage rules for "binary" then those RRs would have to be treated special, but they are treated the same as every other RR. Furthermore, nothing like those RRs could _ever_ be defined and deployed again unless the entire Internet architecture were upgraded to support that specific RR. Also keep in mind that caches are not the only transparent boxes on the network. Many DNS servers also allow new opaque RRs to be defined as simple octet streams. Deployment of new RRs practically depends upon this feature. The notion that there is such a thing as a special "binary" label is partly the fault of the DNS community since this term is frequently used to describe names which are "not hostnames", but really there is no such thing. The "binary" name you describe is the default domain name, and hostnames are a special octet-restricted subset of those names. They all share the same storage/transfer/mapping rules, however, which is octet maps with case insensitive comparison for ASCII letters. The infrastructure would not function otherwise. > > I suppose you could argue that the ~standard RRs from STD13 > > are special and do not have any such meaning, although I would > > argue against it. > > And we would certainly continue to disagree, since I read "all I can't do this anymore. I would encourage you to take this to namedroppers where it can be debated to your satisfaction. IMO, the recommendations for hostname-compatible names are only suggestions, and not requirements. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 3 20:02:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04557 for ; Mon, 3 Jun 2002 20:02:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F1cN-000EgI-00 for idn-data@psg.com; Mon, 03 Jun 2002 16:52:07 -0700 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.36 #1) id 17F1cJ-000Eg1-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 16:52:03 -0700 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id QAA25236 for ; Mon, 3 Jun 2002 16:51:34 -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 QAA29856 for ; Mon, 3 Jun 2002 16:52:02 -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 QAA29847; Mon, 3 Jun 2002 16:52:01 -0700 (PDT) Received: from birdie.sybase.com (birdie.sybase.com [130.214.201.140]) by olympus-dublin.sybase.com (8.10.2+Sun/8.10.2) with ESMTP id g53Nq0507258; Mon, 3 Jun 2002 16:52:01 -0700 (PDT) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id QAA27297; Mon, 3 Jun 2002 16:51:48 -0700 (PDT) Date: Mon, 3 Jun 2002 16:51:48 -0700 (PDT) From: Kenneth Whistler Message-Id: <200206032351.QAA27297@birdie.sybase.com> To: lsb@postel.co.kr Subject: Re: [idn] utf8/legacy versioning Cc: idn@ops.ietf.org X-Sun-Charset: US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk I'm not stepping into the issue of how to define the charsets, but to answer Soobok Lee's specific inquiry: > Everyone knows UCS(ISo10646) and Unicode (UTC) changes and expands over time. > Does UCS (ISO10646) versioning strictly follow Unicode Versioning (UTC) ? The answer to that question is no. Unicode versioning is specified exactly on the Unicode website, by references to specific sets of contributory data files. ISO/IEC 10646 expansion is by the publication of amendments, once they have gone through international ballotting. The two encoding committees, UTC and SC2/WG2, work hard to have significant synchronization points, where the two standards can be matched up with identical repertoires, but in between major versions it can get a little tricky to match "versions" of the two standards. The recent major synchronization point was Unicode 3.0. Here is the information about that and subsequent synchronizations: Unicode Version 10646 Publication Unicode 3.0 ISO/IEC 10646-1:2000 (Second Edition) ======================================================================= Unicode 3.1 ISO/IEC 10646-1:2000 (Second Edition) + 2 characters from Amendment 1 to Part 1 ISO/IEC 10646-2:2001 ======================================================================= Unicode 3.2 ISO/IEC 10646-1:2000 (Second Edition) Amendment 1 to 10646-1:2000 (published 2002) ISO/IEC 10646-2:2001 ======================================================================= And prospectively, we anticipate the following synchronization in repertoires sometime late next year: Unicode 4.0 ISO/IEC 10646-1:2000 (Second Edition) Amendment 1 to 10646-1:2000 (published 2002) Amendment 2 to 10646-1:2000 (to appear 2003?) ISO/IEC 10646-2:2001 Amendment 1 to 10646-1:2001 (to appear 2003?) But this situation is somewhat muddied by the fact that SC2/WG2 is also starting on a project to merge Part 1 and Part 2 of 10646 into a single standard, in which case it is conceivable that in 2003 or 2004 the coalesced 10646 will be reissued, presumably as ISO/IEC 10646:2003 (or 2004) (Third Edition), rolling in the amendments. If so, we would return to a relatively simpler publication situation, as for Unicode 3.0. --Ken > Then, Why can't we see "utf8-3.1" or "utf8-3.2" for Unicode 3.1 and 3.2 recpectively? > From owner-idn@ops.ietf.org Mon Jun 3 21:51:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06724 for ; Mon, 3 Jun 2002 21:51:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F3Kl-000LOH-00 for idn-data@psg.com; Mon, 03 Jun 2002 18:42:03 -0700 Received: from 132.0.asiainfra.com ([203.207.0.132] helo=mail.asiainfra.com) by psg.com with esmtp (Exim 3.36 #1) id 17F3Kd-000LNP-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 18:41:55 -0700 Received: from gix ([10.1.1.101]) by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id JAA16099; Tue, 4 Jun 2002 09:35:30 +0800 From: "Kenny Huang" To: "Edmon Chung" , "John C Klensin" , "Eric A. Hall" Cc: Subject: RE: [idn] Using a new class for IDN Date: Tue, 4 Jun 2002 09:48:03 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <002d01c20b37$9cbb1b90$0f01a8c0@neteka.inc> X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06724 > > While I find it kind of ironic, though not surprising that the so heralded > "quick fix" method is not so "quick" afterall, perhaps our effort > should now > (that the IDNA thing is more or less ready) move towards a > solution that is > truly more "satisfactory" as you have mentioned. > You try to identify the potential issue from a broader aspect. Which is out of the wg concern. > By the way, just to make it clear, this is not intended to block or stall > the current IDNA effort, but pointing out the plain fact about a > real world Fact (or potential fact) may not be the key issue. You already mentioned who can be benefited from the quick fix. It's not difficult to extend the logic. Kenny From owner-idn@ops.ietf.org Mon Jun 3 23:31:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08348 for ; Mon, 3 Jun 2002 23:31:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F4ro-0001NM-00 for idn-data@psg.com; Mon, 03 Jun 2002 20:20:16 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17F4rj-0001MP-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 20:20:11 -0700 Received: from MASTER ([211.197.15.191]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g543JiA01271; Tue, 4 Jun 2002 12:19:51 +0900 Message-ID: <016601c20b76$a7b92390$2b19fea9@temp> From: "Soobok Lee" To: "John C Klensin" , "Eric A. Hall" Cc: References: <3CFBA0C2.C0A70A0A@ehsco.com> <93294759.1023116163@localhost> Subject: Re: [idn] Using a new class for IDN Date: Tue, 4 Jun 2002 12:19:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John C Klensin" > > > Oh sure, it lets registrars *sell* domains quickly, but its > > success with the user community hinges on every application in > > the world being upgraded to perform conversion. Furthermore, > > it is known that this will be a disruptive process which will > > absolutely cause interoperability failures. There is nothing > > fast or resolute about this. The only thing going for it is > > that it is backwards compatible. While that is a necessary > > attribute of any solution, it is not by itself a "quick fix" > > for anybody other than domain resellers. > > Again, I agree. But domain resellers, others who believe that > having "multilingual names" --somehow-- quickly are important, > and the fear that, if the WG doesn't do something... Right > Now... various sorts of interoperability catastrophies would > occur, have been the sources of huge pressures on the WG to try > to do _something_ that can be deployed quickly. And "deployed" > has been defined in that context by ability to put names in > tables and get them back out. I have never seen any of such written threat or pressure appear in this WG. maybe, behind the curtain: "Publish the RFC, Right now! if not, we will balkanize the DNS!". For what reason should we be so generous to this kind of pressure? I can't believe any registries make such threats. Most of them promise they will switch to/adhrere to IETF-approve IDN standards in their homepages. In the same time, from the opposite group of consumers and countries, there has been public and written *strong pressure* on this WG to produce more mature and stable and interoperrable and long-term-safe solutions. For what reason should we be so harsh on this appeal ? > > One can believe that pattern was either good or bad, but I think > it is indisputable that the WG has been operating under pressure > --quite large by IETF averages-- to produce some solution > quickly. Do you say that above standardization pattern was bad ? From owner-idn@ops.ietf.org Tue Jun 4 00:17:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08839 for ; Tue, 4 Jun 2002 00:17:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F5Vy-0003yx-00 for idn-data@psg.com; Mon, 03 Jun 2002 21:01:46 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17F5Vq-0003ya-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 21:01:38 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17F5Vq-0007nV-00 for ; Mon, 03 Jun 2002 21:01:38 -0700 Date: Tue, 4 Jun 2002 04:01:38 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020604040137.GA29908@nicemice.net> Reply-To: IETF idn working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <056b01c20af4$d5e55630$0f01a8c0@neteka.inc> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk [Edmon, sorry you got two copies of this, it was an accident.] Edmon Chung wrote: > non-ASCII requests are not "randomly misinterpreted", at least not in > NeDNS, they get uniquely resolved into the intended domain name that a > non-aware user is typing in. Really? So if I type a name, and my IDN-unaware software blindly copies the name into a DNS request (which won't necessarily happen, but let's say it does), the server will match on the name I intended no matter whether my system uses iso-8869-1 or shift_jis or iso-2022-jp or euc-jp or UTF-8 or UTF-16be or UTF-16le or...? And it will match uppercase Latin letters with fullwidth lowercase Latin letters? And it will match precomposed characters with their decomposed equivalents? Isn't it inevitable that there will be collisions between the various charsets, so that a request for one name using one charset will accidentally match an unrelated name stored under a different charset? That's what I mean by random misinterpretation. In the current DNS protocol, the semantics of octets 80..FF are undefined, so the server cannot know what the client is really asking for--it cannot know what the user typing the name really saw on the screen. It can guess, and maybe guess right most of the time, but it can't really know. > Adam, whether you like it or not, the reality is that non-ASCII > request are reaching registry name servers and whether you resolve > these domain names or not is the operator's choice. That's true, I'm just saying it's risky. Whenever text is passed around without a charset tag (implicit or explicit), there is a risk of misinterpretation. If RFC 1035 had said clearly "domain names in zones shall not contain 80..FF until the semantics have been defined", then we could decide tomorrow that 80..FF are nameprepped UTF-8 (or arbitrary UTF-8 if we require the server to perform Nameprep), and there would be no problem. Unfortunately, RFC 1035 contained no such clear prohibition, and various conflicting interpretations of 80..FF have been deployed, and now any standard definition will conflict with those deployments, and so people who want standard 8-bit names are turning to EDNS and/or new classes. AMC From owner-idn@ops.ietf.org Tue Jun 4 09:46:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28470 for ; Tue, 4 Jun 2002 09:46:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FERh-0008vT-00 for idn-data@psg.com; Tue, 04 Jun 2002 06:33:57 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17FERe-0008vE-00 for idn@ops.ietf.org; Tue, 04 Jun 2002 06:33:54 -0700 Message-ID: <00bf01c20bcc$426def10$0f01a8c0@neteka.inc> From: "Edmon Chung" To: References: <20020604040137.GA29908@nicemice.net> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Date: Tue, 4 Jun 2002 09:32:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Adam M. Costello" > Edmon Chung wrote: > > > non-ASCII requests are not "randomly misinterpreted", at least not in > > NeDNS, they get uniquely resolved into the intended domain name that a > > non-aware user is typing in. > > Really? So if I type a name, and my IDN-unaware software blindly copies > the name into a DNS request (which won't necessarily happen, but let's > say it does), the server will match on the name I intended Unless you are misinformed, yes you will be reaching the "intended" domain. > That's what I mean by random misinterpretation. Therefore it is not "random" and there is no "misinterpretation". > > Adam, whether you like it or not, the reality is that non-ASCII > > request are reaching registry name servers and whether you resolve > > these domain names or not is the operator's choice. > > That's true, I'm just saying it's risky. Whenever text is passed > around without a charset tag (implicit or explicit), there is a risk of > misinterpretation. > > and so people > who want standard 8-bit names are turning to EDNS and/or new classes. The point I am putting out is that it is a fact that non-ASCII request will reach the registry and it is the registry's choice to resolve it or not. A new protocol is entirely another discussion and I think anyone in this group knows very well. Of course if we want to "standardize" a 8-bit transport we would need extra bit-identifiers in the DNS packets whether by way of EDNS or new class. What I am saying is that in the public point of view what users care is that their names work immediately, if not, they will be confused and frustrated. It is the engineer's responsibility to try their best to match the user's expectation in deploying any technology, and mind you these are the unsophisticated users. Therefore registries that are putting out multilingual domain names for registration should think long and hard about their responsibility and try to accomodate their users the best they can. That is what I am saying. Edmon From owner-idn@ops.ietf.org Tue Jun 4 10:01:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29060 for ; Tue, 4 Jun 2002 10:01:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FEZu-0009PU-00 for idn-data@psg.com; Tue, 04 Jun 2002 06:42:26 -0700 Received: from [66.48.4.181] (helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17FEZr-0009PG-00 for idn@ops.ietf.org; Tue, 04 Jun 2002 06:42:23 -0700 Message-ID: <00d701c20bcd$6e783c90$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Kenny Huang" , "John C Klensin" , "Eric A. Hall" Cc: References: Subject: Re: [idn] Using a new class for IDN Date: Tue, 4 Jun 2002 09:40:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kenny, > By the way, just to make it clear, this is not intended to block or stall > the current IDNA effort, but pointing out the plain fact about a > real world I am not sure what do you mean by: "Fact (or potential fact) may not be the key issue. You already mentioned who can be benefited from the quick fix. It's not difficult to extend the logic." I was pointing out that the real world needs a transition path not only an end protocol. Whether we like it or not, it is going to take a long time for the new protocol, whatever it may be, to be adopted by the millions of users on the internet today. Therefore, in a registry's perspective, a transition strategy that takes into consideration the usage of multilingual domain names by applications and users who might not be aware of new protocol requirements is most important to the successful roll out of IDNs. Edmon From owner-idn@ops.ietf.org Wed Jun 5 17:32:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21007 for ; Wed, 5 Jun 2002 17:32:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FhzV-000MoZ-00 for idn-data@psg.com; Wed, 05 Jun 2002 14:06:49 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17FhzM-000MoF-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 14:06:40 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17FhzL-0004h7-00 for ; Wed, 05 Jun 2002 14:06:39 -0700 Date: Wed, 5 Jun 2002 21:06:39 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020605210638.GA17962@nicemice.net> Reply-To: IETF idn working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFB8E0E.AC41126@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk [Another copy of this message accidentally got stuck in the pipe somewhere; I apologize in advance if it eventually comes through.] "Eric A. Hall" wrote: > Consider the lowly cache. What if a client and server exchange > eight-bit domain names linked with an expiremental RR which the cache > knows absolutely nothing about? What if eight-bit owner names are > explicitly interpreted for that RR? Excellent thought experiment. One option that is always open to a cache is to not cache something. Even if all caching DNS servers stopped caching everything, the DNS would still work, it would just take a performance hit. If the caching server receives a record with a name containing 80..FF, and the caching server is unaware of the semantics of 80..FF for that record, then the safest and simplest thing to do is not cache it. However, it could be a little more intelligent. Surely, if two byte strings match exactly, then they match in every other way too. So the caching server could cache the record and do exact comparisons between it and queries, and return the record if they match exactly, and let the query fall through to the authoritative server if they don't match exactly. Furthermore, if the caching server knows that 0..7F are ASCII, and is unsure of only 80..FF, then it can do case-insensitive matching on 0..7F, and exact matching on 80..FF. Now I finally see an argument for why DNS servers in practice do comparisons that way. It's not because RFC 1035 requires it, but because it's the best effort they can make given 1035's silence on the issue. But how does the caching server know that 0..7F are ASCII in domain names attached to unknown RR types or unknown classes? We know that 0..7F are ASCII in all character strings, but are all domain labels necessarily character strings for all future RR types and classes? Or can future RR types and classes use non-text domain names? RFC 1035 is unclear. These sentences suggest that domain names are always text: For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. The labels in the domain name are expressed as character strings and separated by dots. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. But what does this mean: However, future additions beyond current usage may need to use the full binary octet capabilities in names, Does "full binary octet capabilities in names" mean non-text names? Or does it merely mean text names that use 80..FF to represent non-ASCII characters? Although RFC 1035 is not clear, I think the only sane design is that all domain names are text regardless of RR types and class. The data attached to a name might be non-text, but the name itself is text; 0..7F are ASCII and 80..FF are text in an unspecified format. The only safe way to add non-text names would be via an extension to the protocol that prevents old servers from participating, like EDNS. AMC From owner-idn@ops.ietf.org Wed Jun 5 20:22:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29948 for ; Wed, 5 Jun 2002 20:22:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Fkqs-0009fX-00 for idn-data@psg.com; Wed, 05 Jun 2002 17:10:06 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Fkqm-0009el-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 17:10:00 -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 140018 for idn@ops.ietf.org; Wed, 05 Jun 2002 19:07:54 -0500 Message-ID: <3CFEA854.2BD9574@ehsco.com> Date: Wed, 05 Jun 2002 19:09:56 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > Now I finally see an argument for why DNS servers in practice do > comparisons that way. Great. Can we make IDNA a dumb codec now? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed Jun 5 20:53:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01791 for ; Wed, 5 Jun 2002 20:53:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FlQK-000CGI-00 for idn-data@psg.com; Wed, 05 Jun 2002 17:46:44 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 17FWtK-0004IF-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 02:15:42 -0700 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GX873C00.52F; Wed, 5 Jun 2002 17:16:24 +0800 Message-ID: <005401c20c71$537eeca0$4607e29f@xiaodonglee> Reply-To: "Sheldon X.D.LEE" From: "xiaodong lee" To: , Cc: "IETF IDN WG" , "Vinton G. Cerf" , "John klensin" , "harald" , "Fred baker" , "Stuart Lynn" , "Erik Nordmark" , "H. T. Kung" , "Qiheng Hu" , "Marc Blanchet" , "James Seng/Personal" , "JET Members" , "hlqian" , "mao" , "Zhang Wen Hui" , "xiang deng" , "xiaodong lee" , , "hoho" , "Kenny Huang" , "Chun-Hsin Wu" , "sstseng" , "Wen-Sung Chen" , "Nai-Wen Hsu" , "yktham" , "jasonho" , "alanysho" , "christine" , "wang yanfeng" Subject: [idn] CDNC Final Comments on Last call of IDN drafts Date: Wed, 5 Jun 2002 17:13:58 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.4 required=5.0 tests=BASE64_ENC_TEXT,RCVD_IN_RELAYS_ORDB_ORG version=2.20 X-Spam-Level: *** Sender: owner-idn@ops.ietf.org Precedence: bulk LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSANCkNoaW5lc2UgRG9tYWluIE5hbWUgQ29uc29ydGl1bSAoQ0ROQykgRmluYWwgQ29tbWVudHMN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KVGhlIGZvbGxvd2luZyBjb21tZW50cyBhcmUgbWFkZSBieSBDRE5DOg0KIA0KMS5DdXJy ZW50bHksIElFVEYgSUVTRyBoYXMgYmVndW4gTGFzdCBDYWxsIG9uIHRoZSBzZXQgb2YgDQpjb3Jl IGRvY3VtZW50cyBJRE5BK05BTUVQUkVQK1BVTllDT0RFIG9mIElETiBXRywgYnV0IHRoZSANCmFy Y2hpdGVjdHVyZSBvZiBJRE4gZGVmaW5lZCBpbiB0aGUgYWJvdmUgdGhyZWUgZG9jdW1lbnRzIA0K ZG9lcyBub3Qgc29sdmUgdGhlIHRyYWRpdGlvbmFsIGFuZCBzaW1wbGlmaWVkIENoaW5lc2UgDQpj aGFyYWN0ZXIgdmFyaWFudCBwcm9ibGVtOiBpdKGvcyBhIGhhbGYtYmFrZWQgc29sdXRpb24gDQpm b3IgQ2hpbmVzZSB1c2Vycy4gVGhhdCB3aWxsIGNhdXNlIHNlcmlvdXMgZGVsZWdhdGlvbiANCnBy b2JsZW0gaW4gdGhlIGFwcGxpY2F0aW9uIG9mIENoaW5lc2UgRG9tYWluIE5hbWUuIA0KDQoyLklF VEYgSUROIFdHIGRvZXMgbm90IHNvbHZlIENoaW5lc2UgRG9tYWluIE5hbWUgdGVjaG5pY2FsIA0K cHJvYmxlbXMuIFVuZGVyIHRoZSBjdXJyZW50IGNvbmRpdGlvbiwgaWYgSUVURiBhcHByb3ZlcyAN CnRoZXNlIElETiBkcmFmdHMgd2l0aG91dCBwdWJsaXNoaW5nIGFueSBjb21wbGVtZW50YXJ5IA0K ZG9jdW1lbnRzIHNpbXVsdGFuZW91c2x5LCByZWdpc3RyYXJzIHdpbGwgb3BlbiBDaGluZXNlIA0K RG9tYWluIE5hbWUgcmVnaXN0cmF0aW9uIHdpdGhvdXQgY29uc2lkZXJpbmcgdGhlIHJlcXVpcmVt ZW50cyANCm9mIENoaW5lc2UgRG9tYWluIE5hbWUgYW5kIENoaW5lc2UgRG9tYWluIE5hbWUgd2ls bCBmYWxsIA0KaW50byBjb25mdXNpb24uIFRoaXMgd2lsbCBkYW1hZ2UgQ2hpbmVzZSBJbnRlcm5l dCBjb21tdW5pdHkgDQpzZXJpb3VzbHkuIA0KDQozLldoYXShr3MgbW9yZSwgaXQgc3RhbmRzIGEg Z29vZCBjaGFuY2UgdGhhdCBzb2Z0d2FyZSANCnZlbmRvcnMgd2lsbCBub3QgZGVwbG95IG9yIG1v ZGlmeSBjbGllbnQgc29mdHdhcmUgdG8gc3VwcG9ydCANCklETiB0b28sIGJlY2F1c2UgdGhlIGN1 cnJlbnQgc28tY2FsbGVkIElETiBzb2x1dGlvbiBpcyBhIA0KZGVmZWN0aXZlIHNvbHV0aW9uLCB3 aGljaCB3aWxsIGJlIHdpZGVseSBhZ2FpbnN0IGVuZCB1c2VycywgDQphZG1pbmlzdHJhdG9ycyBh bmQgQ2hpbmVzZSBJbnRlcm5ldCBjb21tdW5pdGllcywgYW5kIGJyaW5nIA0KdGhlbSBpbnRvIG11 Y2ggdHJvdWJsZS4NCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkNoaW5lc2UgRG9tYWluIE5hbWUgQ29uc29ydGl1bSANCkNETkMg Rm91bmRpbmcgbWVtYmVyczogQ05OSUMsIFRXTklDLCBIS05JQy9IS0ROUiwgTU9OSUMNCkNvLWNo YWlyIG9mIENETkM6IFFpYW4gSHVhbGluLCBQcm9mZXNzb3INCkNvLWNoYWlyIG9mIENETkM6IFNo aWFuLVNoeW9uZyBUc2VuZywgUHJvZmVzc29yDQpKdW5lIDUsIDIwMDINCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From owner-idn@ops.ietf.org Wed Jun 5 20:54:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01884 for ; Wed, 5 Jun 2002 20:54:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FlS9-000CTa-00 for idn-data@psg.com; Wed, 05 Jun 2002 17:48:37 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17FlS0-000CRx-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 17:48:28 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17FlS0-0005Mu-00 for ; Wed, 05 Jun 2002 17:48:28 -0700 Date: Thu, 6 Jun 2002 00:48:28 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020606004827.GE17511@nicemice.net> Reply-To: IETF idn working group References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFEA854.2BD9574@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > > Now I finally see an argument for why DNS servers in practice do > > comparisons that way. > > Great. Can we make IDNA a dumb codec now? I can't tell if that's a deliberate non sequitur (meaning "Okay, can we drop this topic and get back to a more important one?"), or if you see a connection between my statement and your suggestion (I don't). AMC From owner-idn@ops.ietf.org Wed Jun 5 20:58:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02084 for ; Wed, 5 Jun 2002 20:58:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FlRK-000CP5-00 for idn-data@psg.com; Wed, 05 Jun 2002 17:47:46 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17FlRF-000COa-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 17:47:41 -0700 Received: (qmail 40557 invoked from network); 6 Jun 2002 00:49:22 -0000 Received: from bb-203-125-7-4.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.7.4) by sentosa.post1.com with SMTP; 6 Jun 2002 00:49:22 -0000 Message-ID: <006701c20cf3$bfdeef80$9d00a8c0@JAMESSONYVAIO> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] Fw: BOUNCE idn@ops.ietf.org: Non-member submission from ["Adam M. Costello" ] Date: Thu, 6 Jun 2002 08:47:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From amc+f16nqj@nicemice.net Mon Jun 03 20:59:05 2002 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17F5TN-0003nz-00 for idn@ops.ietf.org; Mon, 03 Jun 2002 20:59:05 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17F5TM-0007mj-00 for ; Mon, 03 Jun 2002 20:59:04 -0700 Date: Tue, 4 Jun 2002 03:59:03 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020604035903.GB28532@nicemice.net> References: <3CF64CE7.7AB11BF9@ehsco.com> <70229699.1023093102@localhost> <3CFB8E0E.AC41126@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFB8E0E.AC41126@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: "Eric A. Hall" wrote: > Consider the lowly cache. What if a client and server exchange > eight-bit domain names linked with an expiremental RR which the cache > knows absolutely nothing about? What if eight-bit owner names are > explicitly interpreted for that RR? Excellent thought experiment. One option that is always open to a cache is to not cache something. Even if all caching DNS servers stopped caching everything, the DNS would still work, it would just take a performance hit. If the caching server receives a record with a name containing 80..FF, and the caching server is unaware of the semantics of 80..FF for that record, then the safest and simplest thing to do is not cache it. However, it could be a little more intelligent. Surely, if two byte strings match exactly, then they match in every other way too. So the caching server could cache the record and do exact comparisons between it and queries, and return the record if they match exactly, and let the query fall through to the authoritative server if they don't match exactly. Furthermore, if the caching server knows that 0..7F are ASCII, and is unsure of only 80..FF, then it can do case-insensitive matching on 0..7F, and exact matching on 80..FF. Now I finally see an argument for why DNS servers in practice do comparisons that way. It's not because RFC 1035 requires it, but because it's the best effort they can make given 1035's silence on the issue. But how does the caching server know that 0..7F are ASCII in domain names attached to unknown RR types or unknown classes? We know that 0..7F are ASCII in all character strings, but are all domain labels necessarily character strings for all future RR types and classes? Or can future RR types and classes use non-text domain names? RFC 1035 is unclear. These sentences suggest that domain names are always text: For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. The labels in the domain name are expressed as character strings and separated by dots. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. But what does this mean: However, future additions beyond current usage may need to use the full binary octet capabilities in names, Does "full binary octet capabilities in names" mean non-text names? Or does it merely mean text names that use 80..FF to represent non-ASCII characters? Although RFC 1035 is not clear, I think the only sane design is that all domain names are text regardless of RR types and class. The data attached to a name might be non-text, but the name itself is text; 0..7F are ASCII and 80..FF are text in an unspecified format. The only safe way to add non-text names would be via an extension to the protocol that prevents old servers from participating, like EDNS. AMC From owner-idn@ops.ietf.org Wed Jun 5 20:58:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02097 for ; Wed, 5 Jun 2002 20:58:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FlSm-000CWy-00 for idn-data@psg.com; Wed, 05 Jun 2002 17:49:16 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 17FWtK-0004IF-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 02:15:42 -0700 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GX873C00.52F; Wed, 5 Jun 2002 17:16:24 +0800 Message-ID: <005401c20c71$537eeca0$4607e29f@xiaodonglee> Reply-To: "Sheldon X.D.LEE" From: "xiaodong lee" To: , Cc: "IETF IDN WG" , "Vinton G. Cerf" , "John klensin" , "harald" , "Fred baker" , "Stuart Lynn" , "Erik Nordmark" , "H. T. Kung" , "Qiheng Hu" , "Marc Blanchet" , "James Seng/Personal" , "JET Members" , "hlqian" , "mao" , "Zhang Wen Hui" , "xiang deng" , "xiaodong lee" , , "hoho" , "Kenny Huang" , "Chun-Hsin Wu" , "sstseng" , "Wen-Sung Chen" , "Nai-Wen Hsu" , "yktham" , "jasonho" , "alanysho" , "christine" , "wang yanfeng" Subject: [idn] CDNC Final Comments on Last call of IDN drafts Date: Wed, 5 Jun 2002 17:13:58 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.4 required=5.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA02097 µë-HN¸üCBý1OôBT?È7ôD,üäCó‘÷«²*'ÑÒ¥©ÿ-ëÞ—ÿÿý'§uêÿ£ Þ¯øŸú)³øžµÿè®ëyÇzwý»¥´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´€4) ¡¥¹•Í”½µ…¥¸9…µ” ½¹Í½ÉÑ¥Õ´€¡ 9 ¤¥¹…° ½µµ•¹ÑÌ4(´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´4(4)Q¡”™½±±½Ý¥¹œ½µµ•¹ÑÌ…É”µ…‘”‰ä 9 è4(€4(Ĺ ÕÉÉ•¹Ñ±ä°%Q%M¡…̉•Õ¸1…ÍÐ …±°½¸Ñ¡”͕н˜€4)½É”‘½Õµ•¹ÑÌ%9­95AI@­AU9e =½˜%8]°‰ÕÐÑ¡”€4)…É¡¥Ñ•ÑÕÉ”½˜%8‘•™¥¹•¥¸Ñ¡”…‰½Ù”Ñ¡É•”‘½Õµ•¹ÑÌ€4)‘½•Ì¹½Ðͽ±Ù”Ñ¡”ÑÉ…‘¥Ñ¥½¹…°…¹Í¥µÁ±¥™¥• ¡¥¹•Í”€4)¡…É…Ñ•ÈÙ…É¥…¹ÐÁɽ‰±•´è¥Ò†½Ì„¡…±˜µ‰…­•Í½±ÕÑ¥½¸€4)™½È ¡¥¹•Í”ÕÍ•É̸Q¡…ÐÝ¥±°…Õ͔͕ɥ½ÕÌ‘•±•…Ñ¥½¸€4)Áɽ‰±•´¥¸Ñ¡”…ÁÁ±¥…Ñ¥½¸½˜ ¡¥¹•Í”½µ…¥¸9…µ”¸€4(4(ȹ%Q%8]‘½•Ì¹½Ðͽ±Ù” ¡¥¹•Í”½µ…¥¸9…µ”Ñ•¡¹¥…°€4)Áɽ‰±•µÌ¸U¹‘•ÈÑ¡”ÕÉÉ•¹Ð½¹‘¥Ñ¥½¸°¥˜%Q…ÁÁɽٕ̀4)Ñ¡•Í”%8‘É…™ÑÌݥѡ½ÕÐÁÕ‰±¥Í¡¥¹œ…¹ä½µÁ±•µ•¹Ñ…Éä€4)‘½Õµ•¹ÑÌÍ¥µÕ±Ñ…¹•½Õͱä°É•¥ÍÑÉ…ÉÌÝ¥±°½Á•¸ ¡¥¹•Í”€4)½µ…¥¸9…µ”É•¥ÍÑÉ…Ñ¥½¸Ý¥Ñ¡½Õн¹Í¥‘•É¥¹œÑ¡”É•Åեɕµ•¹ÑÌ€4)½˜ ¡¥¹•Í”½µ…¥¸9…µ”…¹ ¡¥¹•Í”½µ…¥¸9…µ”Ý¥±°™…±°€4)¥¹Ñ¼½¹™ÕÍ¥½¸¸Q¡¥ÌÝ¥±°‘…µ…” ¡¥¹•Í”%¹Ñ•É¹•Ð½µµÕ¹¥Ñä€4)Í•É¥½Õͱ一4(4(̹]¡…Ò†½Ìµ½É”°¥ÐÍÑ…¹‘Ì„½½¡…¹”Ñ¡…Ðͽ™ÑÝ…É”€4)Ù•¹‘½ÉÌÝ¥±°¹½Ð‘•Á±½ä½Èµ½‘¥™ä±¥•¹Ðͽ™Ñ݅ɔѼÍÕÁÁ½ÉЀ4)%8ѽ¼°‰•…Õ͔ѡ”ÕÉÉ•¹Ðͼµ…±±•%8ͽ±ÕÑ¥½¸¥Ì„€4)‘•™•Ñ¥Ù”ͽ±ÕÑ¥½¸°Ý¡¥ Ý¥±°‰”Ý¥‘•±ä……¥¹ÍЕ¹ÕÍ•ÉÌ°€4)…‘µ¥¹¥ÍÑɅѽÉÌ…¹ ¡¥¹•Í”%¹Ñ•É¹•Ð½µµÕ¹¥Ñ¥•Ì°…¹‰É¥¹œ€4)Ñ¡•´¥¹Ñ¼µÕ ÑɽՉ±”¸4(€4(´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´4) ¡¥¹•Í”½µ…¥¸9…µ” ½¹Í½ÉÑ¥Õ´€4) 9 ½Õ¹‘¥¹œµ•µ‰•ÉÌè 99% °Q]9% °!-9% ½!-9H°5=9% 4) ¼µ¡…¥È½˜ 9 èE¥…¸!Õ…±¥¸°Aɽ™•ÍͽÈ4) ¼µ¡…¥È½˜ 9 èM¡¥…¸µM¡å½¹œQÍ•¹œ°Aɽ™•ÍͽÈ4))Õ¹”€Ô°€ÈÀÀÈ4(´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´4( From owner-idn@ops.ietf.org Wed Jun 5 21:30:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04024 for ; Wed, 5 Jun 2002 21:30:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Flw4-000Ep3-00 for idn-data@psg.com; Wed, 05 Jun 2002 18:19:32 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Flvw-000EoW-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 18:19:24 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Flvv-0005Ta-00; Wed, 05 Jun 2002 18:19:23 -0700 Date: Thu, 6 Jun 2002 01:19:23 +0000 From: "Adam M. Costello" To: IETF IDN WG , "Sheldon X.D.LEE" Subject: Re: [idn] CDNC Final Comments on Last call of IDN drafts Message-ID: <20020606011923.GF17511@nicemice.net> Reply-To: IETF idn working group References: <005401c20c71$537eeca0$4607e29f@xiaodonglee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005401c20c71$537eeca0$4607e29f@xiaodonglee> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,DIFFERENT_REPLY_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk That message claims Content-type: text/plain; charset=gb2312, but that doesn't seem to be accurate. Does anyone know the format of the message body? AMC From owner-idn@ops.ietf.org Wed Jun 5 21:54:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05935 for ; Wed, 5 Jun 2002 21:54:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FmIy-000GeM-00 for idn-data@psg.com; Wed, 05 Jun 2002 18:43:12 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 17FmIv-000Ge7-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 18:43:10 -0700 Received: from cnnic.net.cn ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP id GX9GT800.53T; Thu, 6 Jun 2002 09:43:56 +0800 Message-ID: <3CFEBDC9.9BE96DB6@cnnic.net.cn> Date: Thu, 06 Jun 2002 09:41:29 +0800 From: "xiaodong lee" Reply-To: lee@cnnic.net.cn Organization: CNNIC-CNIC-CAS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: zh-CN,zh-TW,en,sv,el MIME-Version: 1.0 CC: iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org Subject: [idn] CDNC Final Comments on Last call of IDN drafts Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=2.9 required=5.0 tests=MISSING_HEADERS,RCVD_IN_OSIRUSOFT_COM version=2.20 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit -------------------------------------------------------------------------------- Chinese Domain Name Consortium (CDNC) Final Comments -------------------------------------------------------------------------------- The following comments are made by CDNC: 1)Currently, IETF IESG has begun Last Call on the set of core documents IDNA+NAMEPREP+PUNYCODE of IDN WG, but the architecture of IDN defined in the above three documents does not solve the traditional and simplified Chinese character variant problem: it’s a half-baked solution for Chinese users. That will cause serious delegation problem in the application of Chinese Domain Name. 2)IETF IDN WG does not solve Chinese Domain Name technical problems. Under the current condition, if IETF approves these IDN drafts without publishing any complementary documents simultaneously, registrars will open Chinese Domain Name registration without considering the requirements of Chinese Domain Name and Chinese Domain Name will fall into confusion. This will damage Chinese Internet community seriously. 3)What’s more, it stands a good chance that software vendors will not deploy or modify client software to support IDN too, because the current so-called IDN solution is a defective solution, which will be widely against end users, administrators and Chinese Internet communities, and bring them into much trouble. -------------------------------------------------------------------------------------------- Chinese Domain Name Consortium CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC Co-chair of CDNC: Qian Hualin, Professor Co-chair of CDNC: Shian-Shyong Tseng, Professor June 5, 2002 -------------------------------------------------------------------------------------------- From owner-idn@ops.ietf.org Wed Jun 5 22:52:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09621 for ; Wed, 5 Jun 2002 22:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Fn58-000KNJ-00 for idn-data@psg.com; Wed, 05 Jun 2002 19:32:58 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Fn4y-000KMe-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 19:32:48 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA19538; Wed, 5 Jun 2002 19:35:55 -0700 Message-Id: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 05 Jun 2002 19:32:31 -0700 To: lee@cnnic.net.cn From: Dave Crocker Subject: Re: [idn] CDNC Final Comments on Last call of IDN drafts Cc: iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org In-Reply-To: <3CFEBDC9.9BE96DB6@cnnic.net.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:41 AM 6/6/2002 +0800, xiaodong lee wrote: >the architecture of IDN defined in the above three documents >does not solve the traditional and simplified Chinese character >variant problem: it's a half-baked solution for Chinese users. It has never been a goal of IDN to create equivalence between different character sets. Therefore, for such requirements, IDN is not as good as half-baked. It is not baked at all. >That will cause serious delegation problem in the application >of Chinese Domain Name. The problem of equivalence between different character sets exists more broadly, so that the IDN situation is merely an example of a larger problem. That problem needs to be solved for the general case. IDN chose Unicode, so that IDN was not required to invent basic technology for representing different character sets. Similarly, IDN should not invent solutions for equivalence between different character sets. When standards bodies for character sets define such equivalences, and when those equivalences gain popularity, it might be appropriate for the IDN effort to consider incorporating these new standards. >2)IETF IDN WG does not solve Chinese Domain Name technical >problems. Under the current condition, if IETF approves these >IDN drafts without publishing any complementary documents >simultaneously, You do not state what is the nature of the complementary documents. From the remainder of your comments, it appears that you are seeking documents concerning DNS administration. These are probably more appropriate for ICANN, since they pertain to registry/registrar matters, rather than basic DNS technology, which is the purview of the IETF. >3)What's more, it stands a good chance that software vendors >will not deploy or modify client software to support IDN too, >because the current so-called IDN solution is a defective solution, Predictions about the behavior of software vendors are usually problematic. Ultimately, the market will decide whether IDN solves a significant problem in a useful way. So far, there is a strong rough consensus among those who have participated in the IETF process, indicating that it solves an important problem in an acceptable fashion. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Thu Jun 6 01:52:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20184 for ; Thu, 6 Jun 2002 01:52:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Fq05-0007xS-00 for idn-data@psg.com; Wed, 05 Jun 2002 22:39:57 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Fq01-0007xG-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 22:39:53 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140054 for idn@ops.ietf.org; Thu, 06 Jun 2002 00:37:47 -0500 Message-ID: <3CFEF5A4.2B5BF162@ehsco.com> Date: Thu, 06 Jun 2002 00:39:49 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > "Eric A. Hall" wrote: > > > > Now I finally see an argument for why DNS servers in practice do > > > comparisons that way. > > > > Great. Can we make IDNA a dumb codec now? > > I can't tell if that's a deliberate non sequitur (meaning "Okay, can we > drop this topic and get back to a more important one?"), or if you see a > connection between my statement and your suggestion (I don't). I forgot the smiley, but I am serious. Now that we are all a big happy family and agree that all labels are treated the same, we need to agree that all i18n labels will *ALSO* be treated this way. IOW, IDNA applies to any domain name defined as a profile of stringprep, and is not dependant on nameprep. This means that IDNA takes i18n labels as input and gives ACE as output (and vice-versa). IE, just one codec. No new codecs for localpart or for NetBIOS or for KERBEROS or anything else. This is required for IDNA to be useful, but it is also necessary for coordinating EDNS and IDNA. A system faced with an i18n domain name on input shouldn't have to say "well I can send it straight through in EDNS, but I'm afraid you'll have to do something else with it if you want STD13 because it isn't nameprep". -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 6 02:57:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00161 for ; Thu, 6 Jun 2002 02:57:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Fqvi-000Cr0-00 for idn-data@psg.com; Wed, 05 Jun 2002 23:39:30 -0700 Received: from gcndmz2.goa.gov.hk ([202.128.228.8]) by psg.com with esmtp (Exim 3.36 #1) id 17Fqve-000Cqm-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 23:39:26 -0700 Received: from gcnsmtp03.support.goa.gov.hk (gcnsmtp03.government.hk [10.113.3.138]) by gcndmz2.goa.gov.hk (8.11.2/8.11.1) with ESMTP id g566dPS71634 for ; Thu, 6 Jun 2002 14:39:25 +0800 X-Priority: 3 (Normal) Subject: [idn] Remove My Email Address from Mail List To: idn@ops.ietf.org From: David KM Chan Date: Thu, 6 Jun 2002 14:39:06 +0800 Message-ID: X-MIMETrack: Serialize by Router on GCNSMTP03/SERVERS/GCNDMZ/HKSARG(Release 5.0.8 |June 18, 2001) at 06/06/2002 02:39:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Please remove my email address from your mail list. Thanks. From owner-idn@ops.ietf.org Thu Jun 6 07:00:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06411 for ; Thu, 6 Jun 2002 07:00:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FulH-000141-00 for idn-data@psg.com; Thu, 06 Jun 2002 03:44:59 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 17FmCH-000G3u-00 for idn@ops.ietf.org; Wed, 05 Jun 2002 18:36:17 -0700 Received: from xiaodonglee ([159.226.7.70]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GX9GHR00.N40; Thu, 6 Jun 2002 09:37:03 +0800 Message-ID: <007101c20cfa$519323f0$4607e29f@xiaodonglee> Reply-To: "Sheldon X.D.LEE" From: "xiaodong lee" To: , Cc: "IETF IDN WG" , "Vinton G. Cerf" , "John klensin" , "harald" , "Fred baker" , "Stuart Lynn" , "Erik Nordmark" , "H. T. Kung" , "Qiheng Hu" , "Marc Blanchet" , "James Seng/Personal" , "JET Members" , "hlqian" , "mao" , "Zhang Wen Hui" , "xiang deng" , "xiaodong lee" , , "hoho" , "Kenny Huang" , "Chun-Hsin Wu" , "sstseng" , "Wen-Sung Chen" , "Nai-Wen Hsu" , "yktham" , "jasonho" , "alanysho" , "christine" , "wang yanfeng" , "zhang bing" Subject: [idn] CDNC Final Comments on Last call of IDN drafts(utf-8) Date: Thu, 6 Jun 2002 09:34:36 +0800 Organization: CAS&CNIC&CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.4 required=5.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id HAA06411 µë-HN¸üCBý1OôBT?È7ó’!8Tÿã/z»"¢ÿmý*Z›òÞ½éÿÿÿÒzw^¯ú0êÿ‰Ùÿ¢›ÿ‰ë_þŠà>·œyקqïÛºY KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKHBÚ[™\ÙHÛXZ[ˆ˜[YHÛÛœÛÜ][H ÑÊHš[˜[ÛÛ[Y[ÃB‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCBƒB•H›ÛÝÚ[™ÈÛÛ[Y[È\™HXYHžHÑ΃BˆBŒJPÝ\œ™[KQUˆQTÑÈ\È™YÝ[ˆ\ÝØ[ÛˆHÙ]ÙˆÛÜ™HB™ØÝ[Y[ÈQJÓSQT‘T ÔS–PÓÑHÙˆQˆÑË]BH\˜Ú]XÝ\™HÙˆQˆYš[™Y[ˆHX›Ý™H™YHØÝ[Y[ÈB™Ù\È›ÝÛÛ™HH˜Y][Û˜[[™Ú[\YšYYÚ[™\ÙHÚ\˜XÝ\ˆB˜\šX[›Ø›[Nˆ]8 &\ÈH[‹X˜ZÙYÛÛ][Ûˆ›ÜˆÚ[™\ÙH\Ù\œËˆB•]Ú[Ø]\ÙHÙ\š[Ý\È[YØ][Ûˆ›Ø›[H[ˆH\XØ][ÛˆÙˆBÚ[™\ÙHÛXZ[ˆ˜[YKˆBƒBŒŠRQUˆQˆÑÈÙ\È›ÝÛÛ™HÚ[™\ÙHÛXZ[ˆ˜[YHXÚšXØ[Bœ›Ø›[\ˈ[™\ˆHÝ\œ™[ÛÛ™][Û‹YˆQUˆ\›Ý™\È\ÙHB’Qˆ˜YÈÚ]Ý]X›\Ú[™È[žHÛÛ\[Y[\žHØÝ[Y[ÈBœÚ[][[™[Ý\ÛK™YÚ\ݘ\œÈÚ[Ü[ˆÚ[™\ÙHÛXZ[ˆ˜[YH™YÚ\ݘ][ÛˆBÚ]Ý]ÛÛœÚY\š[™ÈH™\]Z\™[Y[ÈÙˆÚ[™\ÙHÛXZ[ˆ˜[YH[™BÚ[™\ÙHÛXZ[ˆ˜[YHÚ[˜[[ÈÛÛ™\Ú[Û‹ˆ\ÈÚ[[XYÙHBÚ[™\ÙH[\›™]ÛÛ[][š]HÙ\š[Ý\ÛKˆBƒBŒÊUÚ]8 &\È[Ü™K]Ý[™ÈHÛÛÙÚ[˜ÙH]ÛÙØ\™H™[™ÜœÈÚ[B››Ý\ÞH܈[ÙYžHÛY[ÛÙØ\™HÈÝ\ÜQˆÛË™XØ]\ÙHBHÝ\œ™[ÛËXØ[YQˆÛÛ][Ûˆ\ÈHY™XÝ]™HÛÛ][Û‹ÚXÚÚ[B˜™HÚY[HYØZ[œÝ[™\Ù\œËYZ[š\ݘ]ÜœÈ[™Ú[™\ÙH[\›™]B˜ÛÛ[][š]Y\Ë[™œš[™È[H[È]XÚ›ÝX›KƒBˆB‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCBÚ[™\ÙHÛXZ[ˆ˜[YHÛÛœÛÜ][HBÑÈ›Ý[™[™ÈY[X™\œÎˆÓ“’PËÓ’PËÓ’PËÒÑ”‹SÓ’PÃBÛËXÚZ\ˆÙˆÑΈZX[ˆX[[‹›Ù™\ÜÛ܃BÛËXÚZ\ˆÙˆÑΈÚX[‹TÚ[Û™ÈÙ[™Ë›Ù™\ÜÛ܃B’[™H K Œ ƒB‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB From owner-idn@ops.ietf.org Thu Jun 6 07:03:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06497 for ; Thu, 6 Jun 2002 07:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FutS-0001WJ-00 for idn-data@psg.com; Thu, 06 Jun 2002 03:53:26 -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 17FutO-0001Vk-00 for idn@ops.ietf.org; Thu, 06 Jun 2002 03:53:23 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g56AqqXq014774; Thu, 6 Jun 2002 12:52:54 +0200 To: Dave Crocker Cc: lee@cnnic.net.cn, iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org Subject: [idn] Re: CDNC Final Comments on Last call of IDN drafts References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> From: Simon Josefsson Date: Thu, 06 Jun 2002 12:52:54 +0200 In-Reply-To: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> (Dave Crocker's message of "Wed, 05 Jun 2002 19:32:31 -0700") Message-ID: Lines: 39 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Dave Crocker writes: >>the architecture of IDN defined in the above three documents >>does not solve the traditional and simplified Chinese character >>variant problem: it's a half-baked solution for Chinese users. > > It has never been a goal of IDN to create equivalence between > different character sets. This means IDN is not guaranteed to be secure on non-Unicode systems. There are alot of non-Unicode systems out there today... >>That will cause serious delegation problem in the application >>of Chinese Domain Name. > > The problem of equivalence between different character sets exists > more broadly, so that the IDN situation is merely an example of a > larger problem. That problem needs to be solved for the general case. > > IDN chose Unicode, so that IDN was not required to invent basic > technology for representing different character sets. > > Similarly, IDN should not invent solutions for equivalence between > different character sets. > > When standards bodies for character sets define such equivalences, and > when those equivalences gain popularity, it might be appropriate for > the IDN effort to consider incorporating these new standards. This isn't an adequate solution IMHO, when the consequences of errors made by such standard bodies, or conflicts between different standard bodies, or different interpretations of said standards, or changes between different versions of those standards, or simply a complete lack of standardisation in the area (which is the situation today), may be exploitable for attacking systems on the Internet. (The details of how to attack systems based on charset equivalence mapping tables differences, or changes in Unicode decomposition tables, has been discussed recently on the IDN list.) From owner-idn@ops.ietf.org Thu Jun 6 11:13:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17656 for ; Thu, 6 Jun 2002 11:13:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FydZ-000CWZ-00 for idn-data@psg.com; Thu, 06 Jun 2002 07:53:17 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17FydV-000CWH-00 for idn@ops.ietf.org; Thu, 06 Jun 2002 07:53:13 -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 g56Er5n15591; Thu, 6 Jun 2002 07:53:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> Date: Thu, 6 Jun 2002 07:52:56 -0700 To: Simon Josefsson From: Paul Hoffman / IMC Subject: [idn] Re: CDNC Final Comments on Last call of IDN drafts Cc: iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:52 PM +0200 6/6/02, Simon Josefsson wrote: >This means IDN is not guaranteed to be secure on non-Unicode systems. >There are alot of non-Unicode systems out there today... Nothing is ever guaranteed to be secure. Even if we supplied mapping tables, there is no guarantee that the mapping tables we supplied would match those already in use in those systems, so there will be the same security issues. In fact, we can be sure that some "standardized" mapping tables would disagree with those already implemented. > > When standards bodies for character sets define such equivalences, and >> when those equivalences gain popularity, it might be appropriate for >> the IDN effort to consider incorporating these new standards. > >This isn't an adequate solution IMHO, when the consequences of errors >made by such standard bodies, or conflicts between different standard >bodies, or different interpretations of said standards, or changes >between different versions of those standards, or simply a complete >lack of standardisation in the area (which is the situation today), >may be exploitable for attacking systems on the Internet. And your proposal for an adequate solution is....? Short of forcing every current system to use a single set of standardized mapping table (which is patently unrealistic), how could you ever avoid such an exploit? Further, the exploit you descirbe is identical in every application that allows an encoding of the Unicode character set (such as UTF-8). Are you saying that we shouldn't allow any input in UTF-8 in any application until there is both a standard set of mapping tables and absolute conformance to them? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Jun 6 11:29:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18113 for ; Thu, 6 Jun 2002 11:29:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Fz1j-000E0Z-00 for idn-data@psg.com; Thu, 06 Jun 2002 08:18:15 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Fz1a-000E0H-00 for idn@ops.ietf.org; Thu, 06 Jun 2002 08:18:06 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA03049; Thu, 6 Jun 2002 08:21:17 -0700 Message-Id: <5.1.0.14.2.20020606080637.0229c308@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Jun 2002 08:17:29 -0700 To: Simon Josefsson From: Dave Crocker Subject: [idn] Re: CDNC Final Comments on Last call of IDN drafts Cc: lee@cnnic.net.cn, iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org In-Reply-To: References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:52 PM 6/6/2002 +0200, Simon Josefsson wrote: >This means IDN is not guaranteed to be secure on non-Unicode systems. >There are alot of non-Unicode systems out there today... 1. I assume your use of "secure" does not refer to security technology, but rather to something like correct or productive use. 2. New standards are about new capabilities. If a system does not support the standard -- in its entirety -- then of course it cannot use the standard. With respect to use of data formats, a system implementing a standard must map between the network standard format and their internal format. That is the nature of interoperability formats; it has been the approach to open systems standards for more than 30 years and it works well. > > When standards bodies for character sets define such equivalences, and > > when those equivalences gain popularity, it might be appropriate for > > the IDN effort to consider incorporating these new standards. > >This isn't an adequate solution IMHO, when the consequences of errors >made by such standard bodies, or conflicts between different standard It appears that you want to do standards development in a different world than the one we currently occupy. Most folks prefer to work within the current reality. On the plus side, the nature of the model is called divide and conquor. To make a complex problem tractable, solve as little of it as is practical, using an many existing component solutions as can be found. My own belief is that the single biggest cause of failed standards efforts is failure to constrain the initial solution effort, leading to confusion and delay. >(The details of how to attack systems based on charset equivalence >mapping tables differences, or changes in Unicode decomposition >tables, has been discussed recently on the IDN list.) Discussions are fine. However the only things that really matters is specifications and their acceptance. This issue has been under discussion for a few years. Please point me to the detailed specification that solves the equivalence problem. Please point me at the base of community support for this specification. Absent a concrete specification and community support for it, all you are suggesting it that we wait more years in the hope of developing something that has so far proved extremely elusive. That's not a very good plan for getting anything useful and getting it in a timely manner. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Fri Jun 7 02:45:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19171 for ; Fri, 7 Jun 2002 02:45:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GDDk-000AWX-00 for idn-data@psg.com; Thu, 06 Jun 2002 23:27:36 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17GDDb-000AWC-00 for idn@ops.ietf.org; Thu, 06 Jun 2002 23:27:27 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17GDDa-0000XY-00 for ; Thu, 06 Jun 2002 23:27:26 -0700 Date: Fri, 7 Jun 2002 06:27:26 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020607062726.GA1531@nicemice.net> Reply-To: IETF idn working group References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CFEF5A4.2B5BF162@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > IDNA applies to any domain name defined as a profile of stringprep, > and is not dependent on nameprep. Nameprep is essential to any IDN solution (IDNA or any other). In order to avoid chaos, we need everyone (not just DNS servers, but applications and everything else) to agree on whether two domain names are the same or not. We already have this property for ASCII domain names--everyone uses a case-insensitive ASCII comparison, which is equivalent to performing ToLower and then doing an exact comparision (which is how it's usually implemented). In order for everyone to agree on whether two IDNs are the same, we need to extend ToLower to work on non-ASCII strings. There needs to be a single precise transformation that everyone agrees on. That transformation has been decided--it's NFKC followed by the mapping step defined in Nameprep. Anything that compares non-ASCII domain names must know that transformation (or must be promised that its inputs have already had it applied). Nameprep is an inseparable part of IDNA. > This means that IDNA takes i18n labels as input and gives ACE as > output (and vice-versa). IE, just one codec. No new codecs for > localpart or for NetBIOS or for KERBEROS or anything else. Agreed, there is only one codec for converting between ASCII domain labels and non-ASCII domain labels. Nameprep is an integral part of it. For email address local parts, there is currently no interaction with IDNA, because local parts are ASCII only, according to RFC 2822. The procedure for mapping an email address onto a domain name is to trivially encode the local part as a single label prepended to the domain name. That procedure applies to ASCII local parts, because all local parts are ASCII. Presumably someday soon someone will define non-ASCII local parts. You could imagine two ways of mapping a non-ASCII email address onto an ASCII domain name. (1) You could extend the old precedure to work on non-ASCII email addresses, that is, trivially encode the local part as a single internationalized label prepended to the domain name, and then use IDNA to convert the domain name to ASCII. (2) You could convert the local part and the domain name to ASCII separately (using IDNA for the domain name and something else for the local part), and now you've reduced the problem to the old problem for ASCII email addresses. It will be up to the email folks to decide which approach to take. Local parts are *not* domain labels (even though they are sometimes *mapped* onto domain labels), so IDNA does not automatically apply to them. The mapping from internationalized local parts to domain labels might or might not be as trivial as it was for ASCII local parts. That's something for another working group to decide. As for NetBIOS and Kerberos, I'm not familiar with the issues there. AMC From owner-idn@ops.ietf.org Fri Jun 7 02:54:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19295 for ; Fri, 7 Jun 2002 02:54:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GDPd-000B0s-00 for idn-data@psg.com; Thu, 06 Jun 2002 23:39:53 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17GDPV-000AzE-00 for idn@ops.ietf.org; Thu, 06 Jun 2002 23:39:45 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17GDPV-0000ga-00 for ; Thu, 06 Jun 2002 23:39:45 -0700 Date: Fri, 7 Jun 2002 06:39:45 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020607063945.GA2615@nicemice.net> Reply-To: IETF idn working group References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020607062726.GA1531@nicemice.net> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk I wrote: > That transformation has been decided--it's NFKC followed by the > mapping step defined in Nameprep. Doh, I always get that backwards. First map, then normalize. AMC From owner-idn@ops.ietf.org Fri Jun 7 08:35:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24711 for ; Fri, 7 Jun 2002 08:35:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GIgv-000JMs-00 for idn-data@psg.com; Fri, 07 Jun 2002 05:18:05 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17GIgq-000JMc-00 for idn@ops.ietf.org; Fri, 07 Jun 2002 05:18:00 -0700 Received: from MASTER ([211.219.111.103]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g57CGmA32430; Fri, 7 Jun 2002 21:16:49 +0900 Message-ID: <024e01c20e1d$28a9eae0$2b19fea9@temp> From: "Soobok Lee" To: "Simon Josefsson" , "Dave Crocker" Cc: , , , References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.0.14.2.20020606080637.0229c308@jay.songbird.com> Subject: Re: [idn] Re: CDNC Final Comments on Last call of IDN drafts Date: Fri, 7 Jun 2002 21:16:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > > On the plus side, the nature of the model is called divide and conquor. To > make a complex problem tractable, solve as little of it as is practical, > using an many existing component solutions as can be found. > > My own belief is that the single biggest cause of failed standards efforts > is failure to constrain the initial solution effort, leading to confusion > and delay. > > Absent a concrete specification and community support for it, all you are > suggesting it that we wait more years in the hope of developing something > that has so far proved extremely elusive. > > That's not a very good plan for getting anything useful and getting it in a > timely manner. > Your above defense of premature and lacking-of-consensus IDN standards won't work because IDNA proposes universal and irreversible infrastructural changes on DNS by redefining the subspace ([a-z][a-z]--*) of ASCII domain namespace to have new i18n meanings which have been proved to be problematic. No application which supports ASCII hostnames can avoid this redefinition in the higer/later/human interpretation level. IDN standards are not like the message protocol "quoted-printable" which use is optional and we have many other alternatives like "base64". We have no alternative other than to-be-redefined DNS which is unique. You should not extend your logic into IDN standards. Finding any analogy between IDN standards efforts and those for tiny application protocols will be proved to be false. We have only single slot for new IDN standard. Incremental or "divide and conquor"-style changes or revisions on IDNA standards were already ruled out in IDNA documents themselves. if ever issued and deployed, DNS standards cannot be upgraded because they form crucial internet identifier system which should be stable. DNS is no more the sole property of US DoC/DoD/IETF/IANA, but rather internationallly shared resource. I hope you Dave share with us serious concerns about how to secure DNS from irreversible jeopardizations by commercial driving forces of IDN. "Be liberal in what you accept, Be conservative in what you *ISSUE* ". Soobok Lee > d/ > > > ---------- > Dave Crocker > TribalWise, Inc. > tel +1.408.246.8253; fax +1.408.850.1850 > From owner-idn@ops.ietf.org Fri Jun 7 12:49:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03832 for ; Fri, 7 Jun 2002 12:49:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GMjr-000PKM-00 for idn-data@psg.com; Fri, 07 Jun 2002 09:37:23 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17GMjn-000PK2-00 for idn@ops.ietf.org; Fri, 07 Jun 2002 09:37:19 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140324 for idn@ops.ietf.org; Fri, 07 Jun 2002 11:35:14 -0500 Message-ID: <3D00E13B.5015FD0B@ehsco.com> Date: Fri, 07 Jun 2002 11:37:15 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Adam M. Costello" wrote: > > "Eric A. Hall" wrote: > > > IDNA applies to any domain name defined as a profile of stringprep, > > and is not dependent on nameprep. > > Nameprep is essential to any IDN solution (IDNA or any other). Nameprep is only essential to the creation and intepretation of the domain names used with *specific* resource records. Storing, transferring and converting the data does not require this knowledge. For example, the authoritative master for a zone needs to know that nameprep applies to the owner name of an i18n A RR, so that these rules can be enforced when the RR is created. Similarly, an application which can create and/or read i18n A RRs from EDNS messages needs to know that nameprep applies so that it can validate the domain name. However, a cache inbetween an EDNS client and server does not need to know these rules, since it will only work with data which has already been properly formatted by the client or server. Furthermore, a cache which converts a UTF-8 i18n A RR into ACE does not need to know the rules, because the input data will have already been formatted properly. This is also true for replication servers within the zone; they can assume that the original data is properly formatted, with no knownledge of the rules used to generate that data. This same reasoning applies to all RRs regardless of the stringprep profile they use. If an i18n RP RR contains an i18n email address, the i18n localpart rules would only apply to the creation of the RR data. The infrastructure can be relatively ignorant about these rules. Consider another example, where a specific application requires the use of an i18n RR which does not conform to nameprep. It is feasible that a FOO RR will need to define it's own rules, perhaps because the application requires all-uppercase, or because the RR data is storing raw text which must not be normalized. If the infrastructure is opaque, then these RRs can be defined at the authoritative master for the zone and within the application that uses these RRs, while the infrastructure can be completely ignorant of the rules. Caches can even perform conversion because the rules say (or they *SHOULD* say) that the inputs and outputs are simple octet streams. That is the same model used today and we need to stick with it. > In order > to avoid chaos, we need everyone (not just DNS servers, but applications > and everything else) to agree on whether two domain names are the same > or not. Is IDNA capable of producing identical output for two different inputs (setting aside the issue of normalizations)? That is the only real question as to whether or not the separation can occur. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 8 01:05:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22764 for ; Sat, 8 Jun 2002 01:05:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GY9q-000Jwk-00 for idn-data@psg.com; Fri, 07 Jun 2002 21:48:58 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17GY9h-000JwR-00 for idn@ops.ietf.org; Fri, 07 Jun 2002 21:48:49 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17GY9g-0003YN-00 for ; Fri, 07 Jun 2002 21:48:48 -0700 Date: Sat, 8 Jun 2002 04:48:48 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020608044848.GD10913@nicemice.net> Reply-To: IETF idn working group References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3D00E13B.5015FD0B@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Eric A. Hall" wrote: > Nameprep is only essential to the creation and interpretation of the > domain names used with *specific* resource records. Nameprep is at the heart of the definition of equivalent labels. In today's domain name system, you cannot have foo and Foo and FOO as three separate entries in the same zone. No matter which one you ask for, you'll get the same records back, because they are equivalent labels. This will still be true for IDNs. No matter whether you ask for föo, Föo, or FÖO, you'll get the same records back. (For the Latin-1-impaired, the non-ASCII characters are o with umlaut.) You seem to be proposing a model in which there might be special kinds of labels that use different Stringprep profiles that don't do case folding. But then queries for föo, Föo, and FÖO could return three different results. That would be a fundamental departure from today's model. Nameprep is inseparable from IDNA not only for names of resource records but also for domain names appearing inside resource records, because you never know when or why or by whom domain names will get compared. Let's examine how föo and FÖO can get compared. The ACE form of both is xx--fo-fka. But if we were to skip Nameprep when converting FÖO, we would get xx--FO-ohA. Now consider an entity that knows that föo and FÖO and xx--fo-fka and xx--FO-ohA are domain labels, but does not know that they are special labels that don't use Nameprep. Will this entity consider föo and FÖO to be equivalent? Yes, because domain labels are case-insensitive. Will it consider föo and xx--fo-fka to be equivalent? Yes, because the latter is the ACE encoding of the former. Will it consider labels xx--fo-fka and xx--FO-ohA to be equivalent? No, because they are ASCII labels and the usual ASCII comparison rules apply. Therefore, by transitivity of equivalence, this entity cannot consider FÖO and xx--FO-ohA to be equivalent. That's an important result. An entity that doesn't know about special non-nameprepped labels cannot convert between the non-nameprepped-ACE form and the Unicode form (because it doesn't consider the two forms to be equivalent). Only an entity that knows the special nature of such labels can do the conversion. Therefore, we might as well not overload the IDNA prefix for such purposes, but instead use a different prefix associated with a different Stringprep profile. If an entity knows about the special non-nameprepped labels, it can easily look for the other prefix. If an entity doesn't know about the special non-nameprepped labels, it couldn't do the conversion anyway, so it doesn't matter that it doesn't know the prefix. Having different prefixes for different profiles would help avoid confusion and mistakes. I think these special non-nameprepped labels that you envision tend to be the result of mapping non-domain-label data onto domain labels (like email address local parts). Domain labels have their own matching rules, and those rules apply to all domain labels, and Nameprep is an integral part of those matching rules (for IDN labels). If you want to map some other data type onto domain labels, then it's up to you to define a mapping that copes with any differences between the domain label matching rules and the matching rules of the other data type. IDNA is designed to convert domain labels to other domain labels, and to compare domain labels. It is not designed to convert between domain labels and other data types. If you want to define such conversions, you are free to immitate IDNA. Maybe you will end up with something just like IDNA except that it uses a different Stringprep profile and a different ACE prefix. (But if the other data type has such different matching rules, it might be easier not to try to map it onto a domain name at all, but instead just let it be its own data type. There's no law that says everything needs to be represented as a domain name. Resource records can define arbitrary data formats.) > Is IDNA capable of producing identical output for two different inputs > (setting aside the issue of normalizations)? I'm not sure what you mean. Nameprep can of course produce identical output for two distinct inputs. But for two distinct outputs of Nameprep, ToASCII cannot produce the same output. AMC From owner-idn@ops.ietf.org Sat Jun 8 02:36:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02309 for ; Sat, 8 Jun 2002 02:36:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GZj1-000NE3-00 for idn-data@psg.com; Fri, 07 Jun 2002 23:29:23 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17GZiw-000NDl-00 for idn@ops.ietf.org; Fri, 07 Jun 2002 23:29:18 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140428 for idn@ops.ietf.org; Sat, 08 Jun 2002 01:27:15 -0500 Message-ID: <3D01A436.4060708@ehsco.com> Date: Sat, 08 Jun 2002 01:29:10 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit on 6/7/2002 11:48 PM Adam M. Costello said the following: > This will still be true for IDNs. No matter whether you ask for > föo, Föo, or FÖO, you'll get the same records back. Important footnote clarification. The i18n namespace is case-sensitive because of the AMC-Z encoding, not because of nameprep. The original capitalization has to be burned to suit the encoding. As a result, all i18n domain names (unencoded) must be compared as case-specific data, by requirement of the codec. This applies to every domain name which can be encoded with IDNA regardless of whether or not nameprep is used. > You seem to be proposing a model in which there might be special kinds > of labels that use different Stringprep profiles that don't do case > folding. Absolutely. If somebody needs an RR that preserves case, there's no reason they shouldn't be able to do so. It's a choice between: 1) do I store the data in case-specific form and require case-specific comparisons or 2) do I burn character case on creation through mandatory lowercasing and also require case-specific comparisons There is no reason to require #2, just as there is no reason to always require normalization. Furthermore, there are already well-known data-types that require #1. > But then queries for föo, Föo, and FÖO could return three > different results. That would be a fundamental departure from today's > model. We just finished this argument. Labels are currently stored, transferred and compared as octet-streams, with the exception being that ASCII A-z is compared as case-insensitive. The difference here is that ASCII A-z will always be case-specific for i18n domain names (a requirement of the codec). Otherwise, the behavior I am arguing for is *IDENTICAL* to the current model, while you are arguing for mandatory lowercasing for storage and transfer in addition to comparison. > Let's examine how föo and FÖO can get compared. The ACE form of both > is xx--fo-fka. But if we were to skip Nameprep when converting FÖO, we > would get xx--FO-ohA. > > Now consider an entity that knows that föo and FÖO and xx--fo-fka and > xx--FO-ohA are domain labels, but does not know that they are special > labels that don't use Nameprep. Why would it ask for a special RR that it doesn't know how to read? There are loads of RRs out there that applications cannot parse. ping can't process SOA RRs, why would it be expected to read the FOO RR? People can already write RRs that suit specific application requirements, and I'm asking that you consider this continued requirement. They are the only users of those RRs, so what do we care what they do? Moreover, why do we need an arbitrary rule that prohibits current practice? >>Is IDNA capable of producing identical output for two different inputs >>(setting aside the issue of normalizations)? > > I'm not sure what you mean. Nameprep can of course produce identical > output for two distinct inputs. But for two distinct outputs of > Nameprep, ToASCII cannot produce the same output. Is the encoding form guranteed to always be reversible to the original capitalization? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 8 11:42:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08338 for ; Sat, 8 Jun 2002 11:42:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GiDS-0009bQ-00 for idn-data@psg.com; Sat, 08 Jun 2002 08:33:22 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17GiDO-0009bE-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 08:33:18 -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 g58FXBn02798; Sat, 8 Jun 2002 08:33:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3D01A436.4060708@ehsco.com> References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> Date: Sat, 8 Jun 2002 08:33:10 -0700 To: "Eric A. Hall" , IETF idn working group From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Eric, at one point you offered to take this discussion to the DNSEXT Working Group. That seemed like a good offer because you are talking about features that are not in the expertise set of this WG. If the DNSEXT Working Group thinks that a change needs to be made in IDNA for resource records, they will certainly tell the Area Directors and probably this WG. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Jun 8 12:55:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09322 for ; Sat, 8 Jun 2002 12:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GjEK-000AR3-00 for idn-data@psg.com; Sat, 08 Jun 2002 09:38:20 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17GjEH-000AQs-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 09:38:17 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140456; Sat, 08 Jun 2002 11:36:13 -0500 Message-ID: <3D0232F5.2000805@ehsco.com> Date: Sat, 08 Jun 2002 11:38:13 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/8/2002 10:33 AM Paul Hoffman / IMC said the following: > Eric, at one point you offered to take this discussion to the DNSEXT > Working Group. That seemed like a good offer because you are talking > about features that are not in the expertise set of this WG. Case and normalization certainly should be in the expertise set of this WG. I mean, you seem to know enough to mandate arbitrary uses of it. If you want to plead ignorance, don't impose a rule you don't understand. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 8 12:57:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09363 for ; Sat, 8 Jun 2002 12:57:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GjR4-000Ae0-00 for idn-data@psg.com; Sat, 08 Jun 2002 09:51:30 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17GjR1-000Adf-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 09:51:27 -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 g58GpLn09917; Sat, 8 Jun 2002 09:51:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3D0232F5.2000805@ehsco.com> References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <3D0232F5.2000805@ehsco.com> Date: Sat, 8 Jun 2002 09:51:20 -0700 To: "Eric A. Hall" From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:38 AM -0500 6/8/02, Eric A. Hall wrote: > > Eric, at one point you offered to take this discussion to the DNSEXT >> Working Group. That seemed like a good offer because you are talking >> about features that are not in the expertise set of this WG. > >Case and normalization certainly should be in the expertise set of this >WG. Right, but that's not what you are arguing about. You are saying that we shouldn't impose them on all DNS RRs. The decision of what DNS RRs should be internationalized is for the DNSEXT WG. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Jun 8 13:20:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09539 for ; Sat, 8 Jun 2002 13:20:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GjhK-000Awy-00 for idn-data@psg.com; Sat, 08 Jun 2002 10:08:18 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17GjhG-000Awl-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 10:08:14 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140462; Sat, 08 Jun 2002 12:06:11 -0500 Message-ID: <3D0239FC.5010805@ehsco.com> Date: Sat, 08 Jun 2002 12:08:12 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <3D0232F5.2000805@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/8/2002 11:51 AM Paul Hoffman / IMC said the following: > At 11:38 AM -0500 6/8/02, Eric A. Hall wrote: >>Case and normalization certainly should be in the expertise set of this >>WG. > > Right, but that's not what you are arguing about. You are saying that > we shouldn't impose them on all DNS RRs. The decision of what DNS RRs > should be internationalized is for the DNSEXT WG. Paul, I am arguing against an arbitry architectural decision which prohibits alternative RRs and domain names from ever being used. Arguing over the RRs themselves is not going to be productive if the architecture won't support them. So yes, I am arguing against the mandatory and unnecessary case and normalization rules which are embedded into the architecture. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 8 13:25:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09657 for ; Sat, 8 Jun 2002 13:25:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GjqD-000B54-00 for idn-data@psg.com; Sat, 08 Jun 2002 10:17:29 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17GjqA-000B4t-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 10:17:26 -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 g58HHLn10657; Sat, 8 Jun 2002 10:17:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3D0239FC.5010805@ehsco.com> References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <3D0232F5.2000805@ehsco.com> <3D0239FC.5010805@ehsco.com> Date: Sat, 8 Jun 2002 10:17:20 -0700 To: "Eric A. Hall" From: Paul Hoffman / IMC Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:08 PM -0500 6/8/02, Eric A. Hall wrote: >Paul, I am arguing against an arbitry architectural decision which >prohibits alternative RRs and domain names from ever being used. And if the DNS folks believe your view of reality, they will will certainly speak up. If they don't believe your view of reality, well that says something. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Jun 8 13:45:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09832 for ; Sat, 8 Jun 2002 13:45:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Gk2w-000BHp-00 for idn-data@psg.com; Sat, 08 Jun 2002 10:30:38 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Gk2t-000BHc-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 10:30:35 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140457; Sat, 08 Jun 2002 12:28:32 -0500 Message-ID: <3D023F38.2040803@ehsco.com> Date: Sat, 08 Jun 2002 12:30:32 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <3D0232F5.2000805@ehsco.com> <3D0239FC.5010805@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/8/2002 12:17 PM Paul Hoffman / IMC said the following: > And if the DNS folks believe your view of reality, they will will > certainly speak up. The ones that are here have done so. On the other hand, there is no support for your capricious choices in the record. In fact, the record shows that they are based on factually incorrect interpretations of DNS technology and practices. Again, I have no expectation that the IDNA team will fix the problems that have been pointed out. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 8 17:20:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12028 for ; Sat, 8 Jun 2002 17:20:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GnRV-000EO1-00 for idn-data@psg.com; Sat, 08 Jun 2002 14:08:13 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17GnRM-000ENi-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 14:08:04 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA08329; Sat, 8 Jun 2002 14:11:29 -0700 Message-Id: <5.1.1.2.2.20020608135338.03caccc8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sat, 08 Jun 2002 14:00:00 -0700 To: "Soobok Lee" From: Dave Crocker Subject: Re: [idn] Re: CDNC Final Comments on Last call of IDN drafts Cc: , , In-Reply-To: <024e01c20e1d$28a9eae0$2b19fea9@temp> References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.0.14.2.20020606080637.0229c308@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:16 PM 6/7/2002 +0900, Soobok Lee wrote: >Your above defense of premature and lacking-of-consensus IDN standards >won't work If you review the amount of time spent on developing this work, you will discover that it is a long way from premature. Quite the contrary. The work has gone on approximately two years longer than it needed to. If you review the usual IETF processes for developing rough consensus, you will discover that IDN is a long way from lacking rough consensus. In fact the process has continued beyond achieving adequate rough consensus, because the IETF has been heeding the concerns of a vocal minority of the community, where most of the concerns of that vocal minority concern technical issues that are outside of the scope of this working group. > I hope you Dave share with us serious concerns about how to secure DNS from >irreversible jeopardizations by commercial driving forces of IDN. We heard similar hyperbole about MIME. It failed to prove true then. It will fail to prove true for IDN. IDN is a careful, focused response to a specific problem with DNS character sets. IDN correctly limits its scope to the solution of that character set problem. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 8 17:52:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12399 for ; Sat, 8 Jun 2002 17:52:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Gnzi-000F21-00 for idn-data@psg.com; Sat, 08 Jun 2002 14:43:34 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Gnze-000F1n-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 14:43:30 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140506; Sat, 08 Jun 2002 16:41:27 -0500 Message-ID: <3D027A80.2030700@ehsco.com> Date: Sat, 08 Jun 2002 16:43:28 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: CDNC Final Comments on Last call of IDN drafts References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.0.14.2.20020606080637.0229c308@jay.songbird.com> <5.1.1.2.2.20020608135338.03caccc8@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/8/2002 4:00 PM Dave Crocker said the following: > If you review the amount of time spent on developing this work, you will > discover that it is a long way from premature. Quite the contrary. The > work has gone on approximately two years longer than it needed to. > the process has continued beyond achieving adequate rough consensus, > because the IETF has been heeding the concerns of a vocal minority of the > community, where most of the concerns of that vocal minority concern > technical issues that are outside of the scope of this working group. If that were true we wouldn't be up to rev 9 of the core draft. Gee, maybe some of the concerns are real, in spite of two years of harping that we are finished. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sat Jun 8 19:44:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13515 for ; Sat, 8 Jun 2002 19:44:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Gpmm-000GWU-00 for idn-data@psg.com; Sat, 08 Jun 2002 16:38:20 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Gpmc-000GVs-00 for idn@ops.ietf.org; Sat, 08 Jun 2002 16:38:10 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA11266; Sat, 8 Jun 2002 16:41:30 -0700 Message-Id: <5.1.1.2.2.20020608162649.02bf3420@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sat, 08 Jun 2002 16:28:19 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] Re: CDNC Final Comments on Last call of IDN drafts Cc: iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org In-Reply-To: <3D027A80.2030700@ehsco.com> References: <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.1.2.2.20020605192007.0291dfd0@jay.songbird.com> <5.1.0.14.2.20020606080637.0229c308@jay.songbird.com> <5.1.1.2.2.20020608135338.03caccc8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 04:43 PM 6/8/2002 -0500, Eric A. Hall wrote: >on 6/8/2002 4:00 PM Dave Crocker said the following: > > the process has continued beyond achieving adequate rough consensus, > > because the IETF has been heeding the concerns of a vocal minority of the > > community, where most of the concerns of that vocal minority concern > > technical issues that are outside of the scope of this working group. > >If that were true we wouldn't be up to rev 9 of the core draft. 9 revisions is not unusual. It is also demonstrably true that one can keep revising a spec forever. Some working groups are very good at it. On the other hand, they are not very good at shipping a spec and getting it used. It would be nice for the IDN effort not to suffer that fate. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Jun 9 08:28:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29590 for ; Sun, 9 Jun 2002 08:28:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17H1SR-000PoY-00 for idn-data@psg.com; Sun, 09 Jun 2002 05:06:07 -0700 Received: from [202.27.17.78] (helo=mars.post1.com) by psg.com with esmtp (Exim 3.36 #1) id 17H1SO-000PoM-00; Sun, 09 Jun 2002 05:06:04 -0700 Received: from localhost (pobox@localhost) by mars.post1.com (8.10.2/8.10.2) with SMTP id g59C4wL06036; Sun, 9 Jun 2002 20:04:58 +0800 (SGT) Date: Sun, 9 Jun 2002 20:04:58 +0800 (SGT) Message-Id: <200206091204.g59C4wL06036@mars.post1.com> X-Mailer: PostOne Client v0.1b X-Sender: jseng@pobox.org.sg From: James Seng To: owner-idn@ops.ietf.org cc: Dave Crocker , iesg@ietf.org, ietf@ietf.org, idn@ops.ietf.org Subject: Re: [idn] Re: CDNC Final Comments on Last call of IDN drafts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk I have no doubt some of the concerns are very real (others are red herrings) . The question is whether we have a solution that have rough consensus or not to address these valid concerns. When we have acceptable solutions to these concerns, then we can discuss them. -James Seng > Gee, maybe some of the concerns are real, in spite of two years of harping > that we are finished. From owner-idn@ops.ietf.org Sun Jun 9 17:10:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07668 for ; Sun, 9 Jun 2002 17:10:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17H9eb-0007bd-00 for idn-data@psg.com; Sun, 09 Jun 2002 13:51:13 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17H9eR-0007bS-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 13:51:03 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17H9eQ-0007kt-00 for ; Sun, 09 Jun 2002 13:51:02 -0700 Date: Sun, 9 Jun 2002 20:51:02 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020609205101.GC28757@nicemice.net> Reply-To: IETF idn working group References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3D01A436.4060708@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "Eric A. Hall" wrote: > The i18n namespace is case-sensitive because of the AMC-Z encoding, > not because of nameprep. The original capitalization has to be burned > to suit the encoding. > > As a result, all i18n domain names (unencoded) must be compared as > case-specific data, by requirement of the codec. You have totally lost me. First, what does "case-specific" mean? I'll start by explaining exactly what "case-sensitive" and "case-insensitive" mean (as I understand the terms). To say that a text string is "case-insensitive" is to say that changing characters from upper to lower case or vice-versa does not change the identity of the string; in other words, case differences are ignored when the string is compared to other strings. To say that a text string is "case-sensitive" is to say that changing characters from upper to lower case or vice-versa does change the identity of the string; in other words, case differences are not ignored when the string is compared. Neither term says anything about whether the string is capable or incapable of preserving mixed-case text; that is an orthogonal question. So there are four possibilities: A string can be case-sensitive and case-preserving (like Unix file names), or case-insensitive and case-preserving (like Macintosh and Amiga file names), or case-insensitive and non-case-preserving (like MS-DOS file names), or case-sensitive and non-case-preserving (I can't think of any real-world examples). For IDNA, we wanted the mapping between non-ASCII labels and ACE labels to have the following property: A case-insensitive comparison of two ACE labels always returns the same answer as a case-insensitive comparison of the two corresponding non-ASCII labels. In order to achieve that property, a case-folding step is essential in the definition of the ACE mapping. (Maybe you don't want that property, but it was a fundamental design goal of IDNA, in order to avoid surprising users with different comparison rules for ASCII versus non-ASCII names.) The codec defined by IDNA has a number of steps, of which the two biggest are Nameprep and Punycode, but it's all a single codec. Punycode is broken out as a separate step because its implementation is independent of the other steps and because Punycode might be useful for things other than domain names. But for IDNs, Punycode is not the codec, it is merely one step of the codec, and Nameprep is another step of the codec. IDNA nowhere suggests the use of case-sensitive comparisons between domain names in any form. > If somebody needs an RR that preserves case, there's no reason they > shouldn't be able to do so. Agreed. And I suggest two ways they might do this: (1) Define a case-sensitive data format and don't call it a domain name. (2) Define a mapping from non-ASCII domain labels to ASCII domain labels that doesn't involve case-folding. But don't call this mapping IDNA, because it's not. It might look very similar to IDNA, and might reuse pieces of it, but it shouldn't use the IDNA ACE prefix for a mapping that is not the IDNA ACE mapping. > Labels are currently stored, transferred and compared as > octet-streams, with the exception being that ASCII A-z is compared as > case-insensitive. That's how most DNS servers handle 8-bit labels in practice, but I still don't think they're required to do so, I just think it's the best effort they can make given that they don't know the charset. But we've heard reports of some new DNS servers that try to guess the charset, in which case they might then do case-insensitive comparisons even for the non-ASCII characters. And there's still the wide world of entities other than DNS servers, which also compare domain names, and their handling of 8-bit names is even less predictable. > you are arguing for mandatory lowercasing for storage and transfer in > addition to comparison. Yes, because that's the only way to achieve that property I mentioned above. > > Now consider an entity that knows that föo and FÖO and xx--fo-fka > > and xx--FO-ohA are domain labels, but does not know that they are > > special labels that don't use Nameprep. > > Why would it ask for a special RR that it doesn't know how to read? Because it might be a caching DNS server. If you only care about the end applications, which know the special semantics of the special labels, then just use a different prefix to go with your different Stringprep profile. Then you can be sure that entities that know IDNA but don't know about your special labels won't accidentally muck with them. > > Nameprep can of course produce identical output for two distinct > > inputs. But for two distinct outputs of Nameprep, ToASCII cannot > > produce the same output. > > Is the encoding form guranteed to always be reversible to the original > capitalization? I'm not sure what you mean by "encoding form". The ACE form (which involves both Nameprep and Punycode) is not guaranteed to be reversible to the original capitalization. There is a mechanism called "mixed-case annotation", described in Appendix B of the Punycode spec, which can remember any capitalization you want (except for titlecase), but the ToASCII and ToUnicode operations described in the IDNA spec neither create nor apply these annotations. It's possible to write a conformant ToASCII that creates them, and a conformant ToUnicode that applies them, but the IDNA spec does not mention this possibility, mainly because the first two authors have never been convinced that it's really safe or effective. :) (I originally proposed this mechanism as a way to make IDNs case-preserving like ASCII domain names are, but I long ago gave up on that issue.) There is no analogous mechanism for recovering a non-normalized string. Punycode by itself can encode any arbitrary sequence of non-negative integers, and always decodes to exactly the same sequence. AMC From owner-idn@ops.ietf.org Sun Jun 9 19:02:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08544 for ; Sun, 9 Jun 2002 19:02:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HBTJ-0009iF-00 for idn-data@psg.com; Sun, 09 Jun 2002 15:47:41 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HBTC-0009i3-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 15:47:34 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140589 for idn@ops.ietf.org; Sun, 09 Jun 2002 17:45:31 -0500 Message-ID: <3D03DB02.10602@ehsco.com> Date: Sun, 09 Jun 2002 17:47:30 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit on 6/9/2002 3:51 PM Adam M. Costello said the following: > To say that a text string is > "case-sensitive" is to say that changing characters from upper to lower > case or vice-versa does change the identity of the string; in other > words, case differences are not ignored when the string is compared. That's right. And since the encoded representation of the original string has to be case-neutral for it to work in the legacy label, the input label has to be made case-specific. The input label cannot be changed. This is regardless of whether or not it is converted to lowercase before it is encoded; the label which actually gets encoded is permanently made case-specific, at least in its unencoded form. > For IDNA, we wanted the mapping between non-ASCII labels and ACE labels > to have the following property: A case-insensitive comparison of > two ACE labels always returns the same answer as a case-insensitive > comparison of the two corresponding non-ASCII labels. In order > to achieve that property, a case-folding step is essential in the > definition of the ACE mapping. (Maybe you don't want that property, but > it was a fundamental design goal of IDNA, in order to avoid surprising > users with different comparison rules for ASCII versus non-ASCII names.) We agree on history and partially agree on objectives. Let me explain where we differ. Specifically, I agree with the requirement to make *some domain names* lowercase in order to facilitate simple comparisons. In particular, any domain name which commonly represents a connection identifier (a hostname) should conform to this requirement. Examples of this would include the owner name of an A RR, the RRdata of MX and NS RRs, and most of the other domain names which are commonly used for connection identifiers. However, there are other domain names where this is not required. For example, consider that Apple might want to encode the NBP name of AFP servers within a zone as some kind of iNBP RR which is linked to an atalk zone name. There is absolutely no reason that the iNBP RR owner name or any of the RRdata elements must be mangled. Apple could choose to do so, but there is no reason that we should require it. Similar arguments can be made for NetBIOS names, NetWare SAP entries, NIS domains, and so forth. There are plenty of other examples where this kind of facility needs to be supported, but those are obvious candidates most of us are familiar with. What we need in order to support those kinds of applications is to separate nameprep from IDNA. Specifically, IDNA needs to apply encoding against any label which suits the requirements (UCS character code inputs which result in valid STD13 output), regardless of the stringprep profile in use. Then the applications which create and parse the domain names are the only ones that need to understand the stringprep profile in use for that specific domain name. The ridiculous part here is that under the existing STD13 rules, these RRs can be used simply by defining an interpretation to the octets. For example, Microsoft already provides a direct encoding of NetBIOS names into UTF-8 and simply applies their own interpration to the RRs. Under your rules, they couldn't use i18n domain names as effectively as STD13 domain names since they would have to sacrifice capitalization in the process. Get it? i18n domain names need to have *at least* the same flexibility as STD13 if they are to be adopted by the community. If not, then interoperability will be harmed, because people will continue using STD13 labels and doing their own thing. I think you are missing a key concept here, which is that all of the RRs are going to need to i18n definitions, and IDNA alone won't do it. When the RR rules are defined, they will get stringprep profiles assigned to them. At that point, the applications which create and interpret the unencoded labels are the only ones that need to know anything, and the infrastructure can store, transfer, compare and convert the opaque octets. DM-IDNS-00 also tried to define a global namespace. It doesn't work. The only way out is to use per-RR rules. >>If somebody needs an RR that preserves case, there's no reason they >>shouldn't be able to do so. > > Agreed. And I suggest two ways they might do this: (1) Define a > case-sensitive data format and don't call it a domain name. (2) Define > a mapping from non-ASCII domain labels to ASCII domain labels that > doesn't involve case-folding. But don't call this mapping IDNA, because > it's not. It might look very similar to IDNA, and might reuse pieces of > it, but it shouldn't use the IDNA ACE prefix for a mapping that is not > the IDNA ACE mapping. (1) Anything which fits in the i18n namespace is a domain name, regardless of whether or not IDNA can handle it. The problem is that IDNA is trying to mandate the namespace according to the requirements of nameprep, when there is no technological argument for doing so. (2) Defining alternative type-specific codecs hinders deployment, and is unnecessary. Thus the rule is not only arbitrary, but it also hinders interoperability. > heard reports of some new DNS servers that try to guess the charset, > in which case they might then do case-insensitive comparisons even for > the non-ASCII characters. And there's still the wide world of entities > other than DNS servers, which also compare domain names, and their > handling of 8-bit names is even less predictable. Non-argument. The EDNS label is there to prevent this confusion. What the owner of a zone does with the STD13 octets is up to them. >>>Now consider an entity that knows that föo and FÖO and xx--fo-fka >>>and xx--FO-ohA are domain labels, but does not know that they are >>>special labels that don't use Nameprep. >> >>Why would it ask for a special RR that it doesn't know how to read? > > Because it might be a caching DNS server. Caches and replication servers have no need to understand the capitalization or normalization rules in use with a particular domain name. Only the nodes that create and interpret the domain names need to know anything about the contents. Caches and replication servers only need to understand the layout of the message. > If you only care about the end applications, which know the special > semantics of the special labels, then just use a different prefix to > go with your different Stringprep profile. Then you can be sure that > entities that know IDNA but don't know about your special labels won't > accidentally muck with them. No, that won't work. That requires the resolvers, caches and replication servers to understand special rules about the domain names before the application can be deployed. Essentially, this requires the infrastructure to be upgraded for every new domain name which gets defined. There is absolutely no reason for this. It's a ridiculous artifact of an arbitrary design. Decouple IDNA from nameprep and the problem is solved. > I'm not sure what you mean by "encoding form". The ACE form (which > involves both Nameprep and Punycode) is not guaranteed to be reversible > to the original capitalization. Okay, that's a problem. May have to use something else entirely. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Jun 9 22:39:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12021 for ; Sun, 9 Jun 2002 22:39:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HEjl-000EEO-00 for idn-data@psg.com; Sun, 09 Jun 2002 19:16:53 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HEjc-000EEB-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 19:16:44 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HEjb-0002cA-00 for ; Sun, 09 Jun 2002 19:16:43 -0700 Date: Mon, 10 Jun 2002 02:16:43 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020610021643.GA31046@nicemice.net> Reply-To: IETF idn working group References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D03DB02.10602@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk This message responds to things in the order they appeared in the previous message. It might be easier to follow if I reordered some of it, but composing it has left me too tired to do so. You might want to make two passes. :) "Eric A. Hall" wrote: > And since the encoded representation of the original string has to be > case-neutral for it to work in the legacy label, the input label has > to be made case-specific. I asked for a definition of "case-specific", but you didn't give me one. Now you've introduced a second term I'm unfamiliar with, "case-neutral". I honestly don't know what you mean by those terms. > I agree with the requirement to make *some domain names* lowercase in > order to facilitate simple comparisons. > > However, there are other domain names where this is not required. The same could be said for domain names that use only ASCII characters. The case-insensitive comparison might not required for some of them, but it's done for all of them, whether they need it or not. IDNA extends this philosophy to IDNs. The same comparison rules apply to all IDNs. With ASCII domain names, we had the luxury that we could preserve case even while ignoring it; that is, ASCII domain names are case-insensitive/case-preserving. With IDNs in their ACE form, this is not possible (at least not officially); instead we have to choose case-insensitive/non-case-preserving or case-sensitive/case-preserving, and we chose the former, judging the case insensitivity to be more important that the case preservation. If applications want to map case-sensitive identifiers directly onto domain labels in owner names of resource records, they can, as long as they avoid collisions. This is already true for ASCII domain names, and continues to be true for IDNs. For example, in the ASCII world, we can store information under the name FoO.net, and when someone looks up FoO.net, they'll find the information. We can't store different information under fOo.net, even though fOo is a distinct identifier from FoO. Now reread that example but imagine an umlaut over the middle letter. With IDNA, it's all still true. The only difference is that if you do a reverse query, you won't get the original capitalization, but reverse queries are almost never used, so it's no big deal. If case-preservation is important to an application (which is more plausible if the applications is mapping case-sensitive identifiers onto domain labels *inside* resource records), then it can define a mapping that preserves case. For example, it could use 8-bit labels (like unprepped UTF-8 or foo-prepped UTF-8), or it could use something similar to IDNA but with a different Stringprep profile and a different prefix. > Microsoft already provides a direct encoding of NetBIOS names into > UTF-8 and simply applies their own interpration to the RRs. Under > your rules, they couldn't use i18n domain names as effectively as > STD13 domain names since they would have to sacrifice capitalization > in the process. Right, IDNA sacrifices case-preservation in order to get compatibility with the ASCII infrastructure while continuing the tradition of case-insensitive domain names. Maybe NetBIOS doesn't like that tradeoff, and would rather have case-preserving reverse queries. Microsoft can continue to use 8-bit DNS names if they want. Here's a stab at the relationship (or lack thereof) between 8-bit labels (which are allowed by RFC 1035) and IDN labels (which are defined by the IDNA spec). I'm sure some people (even IDNA supporters) might not agree with this interpretation, because it's a subtle question, but here goes: 8-bit labels in DNS (not EDNS) owner names, even if they are interpreted as UTF-8 by the end clients, do not contain non-ASCII characters from the point of view of the DNS infrastructure. RFC 1035 does not specify or allow any charset other than ASCII, therefore it's impossible for an owner name to contain non-ASCII characters; the octets 80..FF are allowed, but they don't represent any particular characters (from the point of view of DNS). Since IDNA explicitly applies only to text labels (which I understand to mean labels composed entirely of characters), DNS labels containing 80..FF are completely outside the scope of IDNA; they are not IDN labels, but labels in an independent namespace that is not subject to any of the rules for IDNs. Applications can continue to use use such labels under the rules of RFC 1035 without regard to IDNA. I personally think this namespace is under-specified and risky and should not be used, but it will still be as present after IDNA as it was before. That analysis applies to DNS, not EDNS. EDNS could define entirely new semantics and comparison rules for its 8-bit labels; there is no need for EDNS labels to be compared in the same way as DNS labels. EDNS could even define multiple namespaces each with its own comparison rules, and tag labels according to which namespace they belong to. > I think you are missing a key concept here, which is that all of the > RRs are going to need to i18n definitions, and IDNA alone won't do it. I'm not missing that, I know that. IDNA alone won't do it; IDNA is only for internationalized textual domain labels. RRs that map other data types onto domain names might find that IDNA is not suited to their needs. They are welcome to define a more suitable mapping directly from their non-domain-label data type to ASCII domain labels. They are welcome to borrow techniques from IDNA. > When the RR rules are defined, they will get stringprep profiles > assigned to them. At that point, the applications which create and > interpret the unencoded labels are the only ones that need to know > anything, and the infrastructure can store, transfer, compare and > convert the opaque octets. I'm finally starting to understand your vision. In order to correctly convert labels between the non-ASCII form and the ACE form, or to compare two labels, you would need to EITHER know and perform the preparation algorithm for this particular label OR be guaranteed that the the appropriate preparation has already been applied (in which case you don't need to know what it is). That's interesting, but I see a security concern: What if the entity handing you the label is maliciously not applying the appropriate preparation? It can trick you into making errors when comparing labels, or trick you into converting a label into a non-equivalent label. If you don't know the appropriate preparation algorithm, you can't detect this or protect yourself from it. I suppose it might be possible to address that concern. If you have an interest in the correctness of a comparison/conversion, then you need to know the preparation algorithm yourself. On the other hand, if you are performing comparisons/conversions without knowing the preparation algorithm, you better not be relying on the correctness of the answers, you better just be converting a name on behalf of the entity that prepared it, or comparing names on behalf of an entity that prepared one of them. In your vision of the world (as I understand it), the ASCII infrastructure would use ACE, while the new improved infrastructure would use prepared-UTF-8, where the preparation is not the same for all labels. But I don't see what's so great about prepared-UTF-8 versus ACE. Both require the same amount of effort from all applications; they have to do something special at the boundaries, the difference is in the details. If you want to sell me on a new infrastructure, it's got to offer something more. If it accepted unprepared-UTF-8, then I might find it interesting, because it would require less effort from applications that already use Unicode. But in order for the infrastructure to accept unprepared-UTF-8, the infrastructure would need to know the preparation algorithm... > (1) Anything which fits in the i18n namespace is a domain name, > regardless of whether or not IDNA can handle it. The i18n namespace doesn't exist until we define it. As I argued above, the 8-bit namespace that already exists under RFC 1035 is not an i18n namespace, because it cannot represent non-ASCII characters, because no charset other than ASCII is specified. It is the job of this working group to define the i18n namespace. The definition of IDN in the IDNA draft is a definition of the i18n namespace. > > If you only care about the end applications, which know the special > > semantics of the special labels, then just use a different prefix > > to go with your different Stringprep profile. Then you can be sure > > that entities that know IDNA but don't know about your special > > labels won't accidentally muck with them. > > No, that won't work. I don't see why not. At some point, someone needs to perform Stringprep with some profile. Why can't that entity go ahead and do the whole transformation at the same time (Unicode to ASCII, prepend the prefix)? What's the advantage of doing only the Stringprep part? AMC From owner-idn@ops.ietf.org Sun Jun 9 23:14:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12306 for ; Sun, 9 Jun 2002 23:14:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HFVz-000FaF-00 for idn-data@psg.com; Sun, 09 Jun 2002 20:06:43 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HFVv-000Fa4-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 20:06:39 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140623 for idn@ops.ietf.org; Sun, 09 Jun 2002 22:04:37 -0500 Message-ID: <3D0417BC.5030900@ehsco.com> Date: Sun, 09 Jun 2002 22:06:36 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Everything else discussed is irrelevant. We are there. on 6/9/2002 9:16 PM Adam M. Costello said the following: > "Eric A. Hall" wrote: >>When the RR rules are defined, they will get stringprep profiles >>assigned to them. At that point, the applications which create and >>interpret the unencoded labels are the only ones that need to know >>anything, and the infrastructure can store, transfer, compare and >>convert the opaque octets. > > I'm finally starting to understand your vision. In order to correctly > convert labels between the non-ASCII form and the ACE form, or to > compare two labels, you would need to EITHER know and perform the > preparation algorithm for this particular label OR be guaranteed that > the the appropriate preparation has already been applied (in which case > you don't need to know what it is). Exactly. Any node in the path can convert any RR (whose message structure is understood) between IDNA and ACE simply be piping from one to the other. They don't need to know the capitalization or normalization rules which were used. It's just octets. > That's interesting, but I see a security concern: What if the entity > handing you the label is maliciously not applying the appropriate > preparation? It can trick you into making errors when comparing labels, > or trick you into converting a label into a non-equivalent label. If > you don't know the appropriate preparation algorithm, you can't detect > this or protect yourself from it. That's why DM-IDNS-00 required the app to perform validation. This is discussed in the first paragraph of the Security Considerations section: | Where possible, this specification strengthens DNS with multiple | checks. For example, this specification requires that domain names | be validated three times before they are used by applications: | once on specification, once on entry at the authoritative zone or | hosts database, and once again when the answer data is received by | the requesting application. > In your vision of the world (as I understand it), the ASCII > infrastructure would use ACE, while the new improved infrastructure > would use prepared-UTF-8, where the preparation is not the same for all > labels. Actually, I kind of expect that tighter rules will be picked up for the STD13 RRs at the same time (with a formal definition of hostnames, etc). Some of the stringprep profiles will be for localpart and SRV anyway so those can be reused without effort. I'll leave that up to DNSEXT but I am kind of expecting it to happen (if I can proceed with this model at all). I am also expecting that they will want to use some of the other things as generic updates to STD13. The query timer would be useful for things like TCP fallback and DNSSEC as much as they are to IDNS. > But I don't see what's so great about prepared-UTF-8 versus ACE. Well, that's another argument for another day. The data has to be cleansed before it can reasonably and safely be used by any process, so its not a big deal to have the application do this. At that point, the question is whether or not direct UTF-8 access offers the application and/or protocol any benefits, which it does. >>>If you only care about the end applications, which know the special >>>semantics of the special labels, then just use a different prefix >>>to go with your different Stringprep profile. Then you can be sure >>>that entities that know IDNA but don't know about your special >>>labels won't accidentally muck with them. >> >>No, that won't work. > > I don't see why not. At some point, someone needs to perform Stringprep > with some profile. Why can't that entity go ahead and do the whole > transformation at the same time (Unicode to ASCII, prepend the prefix)? > What's the advantage of doing only the Stringprep part? Because EDNS->ACE conversion by some cache in the middle will require that the cache have knowledge of the appropriate prefix tag. Everytime you roll out a new stringprep profile, you have to tell *everything* that *might* do conversion what the prefix is. This requires pgrades to the resolvers, the caches, the replication partners, everything. Nobody will do it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Jun 9 23:48:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12759 for ; Sun, 9 Jun 2002 23:48:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HFwS-000GES-00 for idn-data@psg.com; Sun, 09 Jun 2002 20:34:04 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HFwK-000GEG-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 20:33:56 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HFwJ-0005Qh-00 for ; Sun, 09 Jun 2002 20:33:55 -0700 Date: Mon, 10 Jun 2002 03:33:55 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020610033355.GA20722@nicemice.net> Reply-To: IETF idn working group References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D0417BC.5030900@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > Everything else discussed is irrelevant. We are there. Well, just because I'm finally starting to understand your vision doesn't mean I'm sold on it. :) > > At some point, someone needs to perform Stringprep with some > > profile. Why can't that entity go ahead and do the whole > > transformation at the same time (Unicode to ASCII, prepend the > > prefix)? What's the advantage of doing only the Stringprep part? > > Because EDNS->ACE conversion by some cache in the middle will > require that the cache have knowledge of the appropriate prefix tag. > Everytime you roll out a new stringprep profile, you have to tell > *everything* that *might* do conversion what the prefix is. What I'm suggesting is that whenever you apply Stringprep, you also apply Punycode and prepend the prefix. It's not really any extra effort. Whenever you roll out a new Stringprep profile, the things that need to get updated to know the new profile are exactly the same things that need to get updated to know the new prefix. Of course, my suggestion implies that there is no prepared-UTF-8 format, there's unprepared-UTF-8 and prepared-ACE. I don't see the point of using prepared-UTF-8 as an interchange format, when ACE works just as well, requires essentially the same effort from applications, and has the added benefit of backward compatibility. AMC From owner-idn@ops.ietf.org Mon Jun 10 01:11:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13943 for ; Mon, 10 Jun 2002 01:11:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HHCJ-000I1q-00 for idn-data@psg.com; Sun, 09 Jun 2002 21:54:31 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HHCG-000I1a-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 21:54:28 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140634 for idn@ops.ietf.org; Sun, 09 Jun 2002 23:52:26 -0500 Message-ID: <3D043101.1010106@ehsco.com> Date: Sun, 09 Jun 2002 23:54:25 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/9/2002 10:33 PM Adam M. Costello said the following: > What I'm suggesting is that whenever you apply Stringprep, you also > apply Punycode and prepend the prefix. Which is the replication master and the application. That's not a problem. > Whenever you roll out a new Stringprep profile, the things that > need to get updated to know the new profile are exactly the same things > that need to get updated to know the new prefix. Resolvers, middle-boxes and replication masters all need to be able to convert between EDNS and ACE as part of the fallback process. Distributing the profile-specific prefix to every point where conversion might occur is a massive problem. The only way it would work in your model would be for conversion to only occur at the application or at the replication master. But if the query made it to the replication master there's no reason to do conversion, so we are left with the application always performing conversion. That design blows up the architectural benefits from having the middle-boxes do it (in particular, having the caches learn the data so they can cache it). It will sometimes be necessary to have applications perform conversion but requiring it would blow up DNS. > Of course, my suggestion implies that there is no prepared-UTF-8 format, > there's unprepared-UTF-8 and prepared-ACE. I don't see the point of > using prepared-UTF-8 as an interchange format, when ACE works just as > well, requires essentially the same effort from applications, and has > the added benefit of backward compatibility. For generating names, ACE conversion is an extra step that comes after creating the structured UTF-8 domain name. Furthermore, it is an unnecessary step if the application and protocol are only using UTF-8 domain names. Meanwhile, there is nothing saved from using unstructured UTF-8 in DNS, since the applications have to use the rules anyway if they are specifically exchanging domain names. The only "extra" step is validating data which has been received, which isn't an extra step for any application with half a clue. It's a fundamental tenet of application design to validate the data you get from the network. Only an idiot would use complex strings without some kind of validation first. Besides, you would also need to do this as part of any decoding of ACE back into the canonical i18n domain name, so this extra step also applies to you (not to mention the extra step of conversion). On all counts, using structured domain names is the fastest of the safe routes, and is only step longer than the shortest route. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 03:02:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23990 for ; Mon, 10 Jun 2002 03:02:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HIxG-000KW4-00 for idn-data@psg.com; Sun, 09 Jun 2002 23:47:06 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HIx6-000KVo-00 for idn@ops.ietf.org; Sun, 09 Jun 2002 23:46:56 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id XAA14828; Sun, 9 Jun 2002 23:50:33 -0700 Message-Id: <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 09 Jun 2002 23:42:44 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group In-Reply-To: <3D043101.1010106@ehsco.com> References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Eric, You have posted 27 messages to this thread in 2 weeks. As nearly as I can tell, you have some concerns about changes to the existing DNS infrastructure. IDNA sits on top of the existing DNS infrastructure. It specifies a set of enhancements that live above the DNS protocol and data structures. It does not specify any changes to that existing DNS protocol or data structures. That includes no changes to RR records or other DNS record specifications. Only software that interfaces with applications needs to add IDNA. Consequently, your comments on this thread appear to pertain to concerns that have nothing at all to do with IDNA. As such, it cannot possibly be helpful to IDNA forward progress to continue this line of discussion in this context. d/ From owner-idn@ops.ietf.org Mon Jun 10 03:15:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24170 for ; Mon, 10 Jun 2002 03:15:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HJBV-000KsT-00 for idn-data@psg.com; Mon, 10 Jun 2002 00:01:49 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HJBS-000KsI-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 00:01:46 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140644; Mon, 10 Jun 2002 01:59:44 -0500 Message-ID: <3D044ED7.8060302@ehsco.com> Date: Mon, 10 Jun 2002 02:01:43 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 1:42 AM Dave Crocker said the following: > Consequently, your comments on this thread appear to pertain to concerns > that have nothing at all to do with IDNA. > > As such, it cannot possibly be helpful to IDNA forward progress to continue > this line of discussion in this context. If Adam and/or any of the other interested party wants to take the discussion off-list, I'll meet them anywhere. Otherwise, your attempt at squelching critical analysis of IDNA is duly noticed and ignored. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 03:19:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24264 for ; Mon, 10 Jun 2002 03:19:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HJAz-000Kri-00 for idn-data@psg.com; Mon, 10 Jun 2002 00:01:17 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17HJAu-000KrQ-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 00:01:12 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5A70SkE016100; Mon, 10 Jun 2002 09:00:28 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 10 Jun 2002 09:01:07 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Jun 2002 09:01:06 +0200 Date: Mon, 10 Jun 2002 08:52:11 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Eric A. Hall" , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <13231052.1023699131@localhost> In-Reply-To: <3D03DB02.10602@ehsco.com> References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 10 Jun 2002 07:01:07.0645 (UTC) FILETIME=[982D26D0:01C2104C] X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-06-09 17.47 -0500 "Eric A. Hall" wrote: > on 6/9/2002 3:51 PM Adam M. Costello said the following: > >> To say that a text string is >> "case-sensitive" is to say that changing characters from upper to lower >> case or vice-versa does change the identity of the string; in other >> words, case differences are not ignored when the string is compared. > > That's right. Well, when working with Unicode, you need more specific text. Two strings, X and Y, are said to be case insensitive if f(X) = f(Y) where f() is either map to lower case or map to upper case. In nameprep we choose to map to lower case. Further, we have added special mappings so f(f(X)) = f(X). Together with normalization this is a little bit tricker, and, because of this complexity and given how DNS software work today, we chose to make the mapping (nameprep) before the strings are used in DNS. I.e. the heavy computation is when doing the mapping, and we optimize for lookups, not storage. Lookup algorithm is exactly the same (given that the input has passed ToASCII in IDNA of course). paf From owner-idn@ops.ietf.org Mon Jun 10 03:21:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24351 for ; Mon, 10 Jun 2002 03:21:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HJB8-000Krt-00 for idn-data@psg.com; Mon, 10 Jun 2002 00:01:26 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17HJAw-000KrZ-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 00:01:14 -0700 Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5A70VOT016103; Mon, 10 Jun 2002 09:00:32 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 10 Jun 2002 09:01:11 +0200 Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Jun 2002 09:01:10 +0200 Date: Mon, 10 Jun 2002 08:58:57 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Eric A. Hall" , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <13255404.1023699537@localhost> In-Reply-To: <3D03DB02.10602@ehsco.com> References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 10 Jun 2002 07:01:11.0208 (UTC) FILETIME=[9A4CD280:01C2104C] X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-06-09 17.47 -0500 "Eric A. Hall" wrote: >> I'm not sure what you mean by "encoding form". The ACE form (which >> involves both Nameprep and Punycode) is not guaranteed to be reversible >> to the original capitalization. > > Okay, that's a problem. May have to use something else entirely. The problem is not capitalization. If you ask for preservation, you should ask for preservation of the original string. Just looking at case preservation is a very very tiny issue. In the beginning (eons ago) we looked at the ability to keep the original string, and the conclusion was that that was not possible without doing a lot of changes to how DNS works, or at least, create new RR types which include both the string one do comparison on, and the one which is given back. Question is then how to see that the relationsship between them stays the same etc etc. But, DNS doesn't work that way _today_. It uses one string to match on, and that is also the string which is given back. If a different string is given back, many resolvers reject the strings due to risk of cache-poisoning. And, caches will have issues with it, and the compression algorithm and... The list is long, very long. So, the result was that at the end, we always to conversion of strings when they go "into the system" of application and DNS protocols. Within that world, that f(X) is what is used. Period. paf From owner-idn@ops.ietf.org Mon Jun 10 03:39:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24721 for ; Mon, 10 Jun 2002 03:39:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HJgr-000Lcr-00 for idn-data@psg.com; Mon, 10 Jun 2002 00:34:13 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HJgo-000Lcg-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 00:34:10 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140649; Mon, 10 Jun 2002 02:32:08 -0500 Message-ID: <3D045670.5030609@ehsco.com> Date: Mon, 10 Jun 2002 02:34:08 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020605210638.GA17962@nicemice.net> <3CFEA854.2BD9574@ehsco.com> <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <13255404.1023699537@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [thanks paf] on 6/10/2002 1:58 AM Patrik Fältström said the following: > The problem is not capitalization. If you ask for preservation, you should > ask for preservation of the original string. Just looking at case > preservation is a very very tiny issue. Yeah, can I have preservation? Normalization will also vary. > And, caches will have issues with it, and the compression algorithm and... Some of these issues are showing up in the conversion work too, as you can imagine. They give me headaches. EG, when you change an owner name from UTF-8 to ACE, the converting system needs to find all of the compression pointers which refer to that owner name and then expand/relocate them. This can be handled through a mix of features -- compression-specific EDNS label types for one -- and this can work without the converter having intimate knowledge of the record structure (only the owner names will be converted). If I can solve that, then I have also solved one of the big problems with STD13 domain names at the same time. I am planning to minimize the risk of collisions by prohibiting sister owner names from being entered which would collapse to the same domain name. Although this isn't technically required, better safe than sorry. The rule can be relaxed later if it proves unnecessary. > So, the result was that at the end, we always to conversion of strings when > they go "into the system" of application and DNS protocols. Within that > world, that f(X) is what is used. Period. Yeah, I understand the need for it, and I support it for the common scenario. But we also need to offer this capability if we want people to not invent STD13 octet interpretations. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 10:00:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04622 for ; Mon, 10 Jun 2002 10:00:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HPSX-0002WD-00 for idn-data@psg.com; Mon, 10 Jun 2002 06:43:49 -0700 Received: from [151.99.229.67] (helo=pmsv0001.saritel.it) by psg.com with esmtp (Exim 3.36 #1) id 17HPST-0002VB-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 06:43:45 -0700 Received: from butch.pm.saritel.it ([172.16.20.127]) by pmsv0001.saritel.it with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 15:47:24 +0200 Received: by butch.pm.saritel.it with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 15:36:49 +0200 Message-ID: <013D3552A4BCD411AF6000508BDE8DEC712F29@misv0002.mi.saritel.it> From: "Codogno Maurizio (Rozzano)" To: "'idn@ops.ietf.org'" Subject: [idn] some comments about draft-ietf-idn-idna-08.txt Date: Mon, 10 Jun 2002 15:39:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Jun 2002 13:47:24.0828 (UTC) FILETIME=[5A1C15C0:01C21085] X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Hi all, I read the drafts about IDNA, nameprep and Punycode, and I have some doubt about the first one, from the point of view of a dumb reader. Ok, you may say that I am dumb, but nevertheless I think that some of those doubts may affect other people too. Could you please look at them? Sect 3, req. 2). "An equivalent domain name". It is a *unique* equivalent domain name, right? Sect. 4.1., para 4. I think that ToASCII may for example fail if I have a sequence of code points like "ascii? yes", which contains "?" and " ". In that case, I think that an explicit failure condition should be added at the various steps of the algorithm (3, 5, 8) Sect. 6.1, para 2. I am wondering if we SHOULD present both forms, if the ACE label is presented. It could be useful for developers, who may see at a glance what it's happening. Moreover, if some character may not be displayed, you have a visual hint that the string you see is not the whole of the story. Sect. 8. Why EDNS has not been included in the specifications? As a side issue, I'd like to be pointed at some heuristic data about Punycode. I may imagine that its algorithms are geared towards efficient handling of non-ideographic languages, like Devanagari, and single "intrusive" characters, but I would like to know more. Ciao, .mau. From owner-idn@ops.ietf.org Mon Jun 10 11:31:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08763 for ; Mon, 10 Jun 2002 11:30:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HQvq-0004vq-00 for idn-data@psg.com; Mon, 10 Jun 2002 08:18:10 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HQvg-0004vS-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 08:18:00 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA24573; Mon, 10 Jun 2002 08:21:39 -0700 Message-Id: <5.1.1.2.2.20020610081102.026a6820@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 10 Jun 2002 08:14:31 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group In-Reply-To: <3D044ED7.8060302@ehsco.com> References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:01 AM 6/10/2002 -0500, Eric A. Hall wrote: >Otherwise, your attempt at squelching critical analysis of IDNA is duly >noticed and ignored. Eric, My note made specific observation that this thread appears to have nothing to do with IDNA. Since you think it IS relevant, I'll ask how it is relevant. I've read the thread and all I see is discussion about things entirely outside the scope of the IDNA specification. If a discussion goes on actively for 2 weeks and results in this sort of confusion, it is generally useful to try to re-synchronize things. So, please clarify. What aspects of IDNA does this thread pertain to? d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Jun 10 13:45:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15867 for ; Mon, 10 Jun 2002 13:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HT2h-0007h2-00 for idn-data@psg.com; Mon, 10 Jun 2002 10:33:23 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HT2c-0007gr-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 10:33:19 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140769; Mon, 10 Jun 2002 12:31:13 -0500 Message-ID: <3D04E2D8.2010708@ehsco.com> Date: Mon, 10 Jun 2002 12:33:12 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> <5.1.1.2.2.20020610081102.026a6820@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 10:14 AM Dave Crocker said the following: > Since you think it IS relevant, I'll ask how it is relevant. > So, please clarify. What aspects of IDNA does this thread pertain to? A lowercase-only idn namespace is not particularly compelling in comparison with STD13 octets which can provide that feature over the existing namespace, I am arguing to get this restriction lifted before it is embedded in stone. Some things about IDNA can be changed after-the-fact, this is not one of them. Specifically, I am trying to get IDNA decoupled from mandatory use of nameprep so that the applications will be able to use domain names which are not lowercased and normalized, if those applications have such a need. This will not affect normal operations, as the majority of the resource records will still need to use nameprep anyway. It's a pretty simple request: make the profile selection separate from the codec. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 14:01:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16576 for ; Mon, 10 Jun 2002 14:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HTPT-0008AM-00 for idn-data@psg.com; Mon, 10 Jun 2002 10:56:55 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HTPK-0008A7-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 10:56:47 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA30440; Mon, 10 Jun 2002 11:00:25 -0700 Message-Id: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 10 Jun 2002 10:54:01 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group In-Reply-To: <3D04E2D8.2010708@ehsco.com> References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> <5.1.1.2.2.20020610081102.026a6820@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:33 PM 6/10/2002 -0500, Eric A. Hall wrote: >Specifically, I am trying to get IDNA decoupled from mandatory use of >nameprep so that the applications will be able to use domain names which >are not lowercased and normalized, if those applications have such a need. >This will not affect normal operations, as the majority of the resource >records will still need to use nameprep anyway. It's a pretty simple >request: make the profile selection separate from the codec. The interpretation of domain name strings is not subject to application-specific choice. The DNS is a single, unified, global service and it defines its own strings. Interpretation (comparison) of strings must work the same in all cases. For everyone. Everywhere. At all times. What you are seeking is in fundamental opposition to global interoperability of the DNS. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Jun 10 14:05:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16752 for ; Mon, 10 Jun 2002 14:05:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HTTv-0008HP-00 for idn-data@psg.com; Mon, 10 Jun 2002 11:01:31 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HTTs-0008H4-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 11:01:28 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140770; Mon, 10 Jun 2002 12:59:26 -0500 Message-ID: <3D04E975.5080407@ehsco.com> Date: Mon, 10 Jun 2002 13:01:25 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> <5.1.1.2.2.20020610081102.026a6820@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 12:54 PM Dave Crocker said the following: > The interpretation of domain name strings is not subject to > application-specific choice. Not in the current design it isn't. > The DNS is a single, unified, global service and it defines its own > strings. Interpretation (comparison) of strings must work the same in all > cases. That is historically and technically erroneous. Applications can and do define their own formatting rules and interpretations. > What you are seeking is in fundamental opposition to global > interoperability of the DNS. Reread the thread. What I seek is already offered in STD13 labels. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 14:38:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18289 for ; Mon, 10 Jun 2002 14:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HTvK-0008qj-00 for idn-data@psg.com; Mon, 10 Jun 2002 11:29:50 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HTvE-0008qA-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 11:29:44 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HTux-000GY5-00; Mon, 10 Jun 2002 18:29:27 +0000 Date: Mon, 10 Jun 2002 14:29:25 -0400 From: John C Klensin To: Dave Crocker , "Eric A. Hall" cc: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <126711235.1023719365@localhost> In-Reply-To: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.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=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 10 June, 2002 10:54 -0700 Dave Crocker wrote: > At 12:33 PM 6/10/2002 -0500, Eric A. Hall wrote: >> Specifically, I am trying to get IDNA decoupled from >> mandatory use of nameprep so that the applications will be >> able to use domain names which are not lowercased and >> normalized, if those applications have such a need. This will >> not affect normal operations, as the majority of the resource >> records will still need to use nameprep anyway. It's a pretty >> simple request: make the profile selection separate from the >> codec. > > The interpretation of domain name strings is not subject to > application-specific choice. > > The DNS is a single, unified, global service and it defines > its own strings. Interpretation (comparison) of strings must > work the same in all cases. > > For everyone. Everywhere. At all times. > > What you are seeking is in fundamental opposition to global > interoperability of the DNS. Dave, I'm neither supporting nor opposing Eric's proposal (intent) at this stage, largely because I have yet to get my mind completely around enough of the detail of what he is really suggesting to understand its implications. But let me suggest something slightly narrower, which I think is consistent with global interoperability, in the hope of clarifying the conversation. At least in principle, we have traditionally been able to have three types of neatly hierarchical rules about the content and interpretation of a DNS label: (i) Rules that apply DNS-wide, to all Classes and RR types, now and in the future. (ii) Rules that apply to all RRs within a particular Class. (iii) Rules that apply to a particular RR (by definition, within a particular Class). One way of looking at the difference of opinion some of us have had about octet interpretation and mapping is that some of the documents have historically not been clear enough as to whether they are expressing rules about a semi-enumerated set of RRs, about all RRs in a Class, or about the DNS generally, but that is a separate conversation that I don't want to restart here. Nothing above provides for an application-dependent interpretation, so you and I are in agreement about that and, if that is what Eric really intends, we presumably jointly disagree with him. Now IDNA (and friends) add a new class of rule, which is to permit giving different semantic interpretation to a label based on the _content_ of that label, e.g., whether applications are expected to map it to or from Unicode based on the presence of a prefix. Suppose Eric said, consistent with the typology above, that we should specify that IDNA (and that prefix-interpretation, nameprep, etc.) are to be applied only to particular RR types within Class=IN, or to all of Class=IN but not to Classes as yet undefined. I'd be sympathetic to that: I think tighter and more conservative definitions (that can be expanded in the future if needed) tend to serve us well in the long term. And, to the degree to which this discussion is really about getting us to a clear statement about where IDNA (and nameprep) should and should not be applied, it seems to be to be a legitimate, and necessary, part of the IETF discussion on IDNA, nameprep, and the current set of documents. One could even argue that, to the extent to which the range of applicability is not precisely defined today, or has not been discussed sufficiently for a legitimate claim of WG consensus to be made, it could be taken as evidence that the documents are not ready for prime time. john From owner-idn@ops.ietf.org Mon Jun 10 14:46:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18549 for ; Mon, 10 Jun 2002 14:46:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HU1P-0008yn-00 for idn-data@psg.com; Mon, 10 Jun 2002 11:36:07 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HU1G-0008yS-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 11:35:58 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA32172; Mon, 10 Jun 2002 11:39:38 -0700 Message-Id: <5.1.1.2.2.20020610112559.01eb1360@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 10 Jun 2002 11:33:09 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group In-Reply-To: <3D04E975.5080407@ehsco.com> References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> <5.1.1.2.2.20020610081102.026a6820@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 01:01 PM 6/10/2002 -0500, Eric A. Hall wrote: >on 6/10/2002 12:54 PM Dave Crocker said the following: > > > The interpretation of domain name strings is not subject to > > application-specific choice. > >Not in the current design it isn't. oh. well, that certainly clarifies things well. You want a different DNS than the world has been using for 15 years. That is considerably beyond the scope of IDN. > > The DNS is a single, unified, global service and it defines its own > > strings. Interpretation (comparison) of strings must work the same in all > > cases. > >That is historically and technically erroneous. Applications can and do >define their own formatting rules and interpretations. That's pretty cool. You think that the interpretation of a DNS string depends on which application is interpreting it. The interoperability impact of that idea is quite impressive. > > What you are seeking is in fundamental opposition to global > > interoperability of the DNS. > >Reread the thread. What I seek is already offered in STD13 labels. So, let's keep this simple. Please describe two scenarios -- in the current, global Internet -- in which the same domain name string is interpreted differently by different applications. In particular, your concern is about comparisons, so the example needs to demonstrate differential comparison results, according to which application is doing the comparing. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Jun 10 14:54:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19018 for ; Mon, 10 Jun 2002 14:54:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HUDJ-0009F2-00 for idn-data@psg.com; Mon, 10 Jun 2002 11:48:25 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HUDF-0009Er-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 11:48:22 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140797; Mon, 10 Jun 2002 13:46:20 -0500 Message-ID: <3D04F471.1030101@ehsco.com> Date: Mon, 10 Jun 2002 13:48:17 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020606004827.GE17511@nicemice.net> <3CFEF5A4.2B5BF162@ehsco.com> <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <5.1.1.2.2.20020609233717.03435400@jay.songbird.com> <5.1.1.2.2.20020610081102.026a6820@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610112559.01eb1360@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 1:33 PM Dave Crocker said the following: > You want a different DNS than the world has been using for 15 years. This kind of facile argument is pointless to respond to. The simple fact is that a lowercase-only i18n namespace is pretty useless as a global database of named objects. > That's pretty cool. You think that the interpretation of a DNS string > depends on which application is interpreting it. The interpretation of the eight-bit codes in STD13 labels is entirely left to local interpretation. If you disagree with this, you need to reread the thread again. > Please describe two scenarios -- in the current, global Internet -- in > which the same domain name string is interpreted differently by different > applications. Any application which uses eight-bit values applies local interpretation to those codes. Reread the thread. > In particular, your concern is about comparisons No, my concern is with limiting the usefulness of the i18n namespace. I will give you a test question now: tell me anybody should be prohibited from storing application-specific domain names as RR data without kneeling at the lowercase alter. What is the exact problem you foresee with allowing an external application to put whatever they want into the RRs which suit their needs? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 15:07:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19815 for ; Mon, 10 Jun 2002 15:07:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HUPi-0009Xq-00 for idn-data@psg.com; Mon, 10 Jun 2002 12:01:14 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HUPf-0009XV-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 12:01:12 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140793; Mon, 10 Jun 2002 13:59:09 -0500 Message-ID: <3D04F775.4020105@ehsco.com> Date: Mon, 10 Jun 2002 14:01:09 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: Dave Crocker , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <126711235.1023719365@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 1:29 PM John C Klensin said the following: > Now IDNA (and friends) add a new class of rule, which is to > permit giving different semantic interpretation to a label based > on the _content_ of that label, e.g., whether applications are > expected to map it to or from Unicode based on the presence of a > prefix. Actually what it does is require that all domain names be converted into a lowercase and normalized form, even if the domain name is only supplied as data in the resource record. > Suppose Eric said, consistent with the typology above, > that we should specify that IDNA (and that > prefix-interpretation, nameprep, etc.) are to be applied only to > particular RR types within Class=IN, or to all of Class=IN but > not to Classes as yet undefined. I'd be sympathetic to that: I > think tighter and more conservative definitions (that can be > expanded in the future if needed) tend to serve us well in the > long term. What I want to do is define this on a per-name/per-RR basis: A
NS MX Those rules result in exactly the same usage as the current IDNA model. I'm not asking to turn everything upside down. What I'm asking for is that if an application needs to use an uppercase or non-normalized domain name for some reason, that they be allowed to do so, but only after defining a strong profile. Eg: FOO This doesn't hurt anybody and puts the i18n namespace on equal footing with the STD13 namespace. Nobody has yet told me why this won't work. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 16:11:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23113 for ; Mon, 10 Jun 2002 16:11:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HVPl-000Apo-00 for idn-data@psg.com; Mon, 10 Jun 2002 13:05:21 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HVPg-000ApZ-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 13:05:16 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HVPc-000GpH-00; Mon, 10 Jun 2002 20:05:12 +0000 Date: Mon, 10 Jun 2002 16:05:11 -0400 From: John C Klensin To: "Eric A. Hall" cc: Dave Crocker , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <132457513.1023725111@localhost> In-Reply-To: <3D04F775.4020105@ehsco.com> References: <3D04F775.4020105@ehsco.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=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 10 June, 2002 14:01 -0500 "Eric A. Hall" wrote: > on 6/10/2002 1:29 PM John C Klensin said the following: > >> Now IDNA (and friends) add a new class of rule, which is to >> permit giving different semantic interpretation to a label >> based on the _content_ of that label, e.g., whether >> applications are expected to map it to or from Unicode based >> on the presence of a prefix. > > Actually what it does is require that all domain names be > converted into a lowercase and normalized form, even if the > domain name is only supplied as data in the resource record. I think it does both of those things, and that they are independent issues. In a perfect world, they would be independent of each other, but it isn't a perfect world. >> Suppose Eric said, consistent with the typology above, >> that we should specify that IDNA (and that >> prefix-interpretation, nameprep, etc.) are to be applied only >> to particular RR types within Class=IN, or to all of Class=IN >> but not to Classes as yet undefined. I'd be sympathetic to >> that: I think tighter and more conservative definitions (that >> can be expanded in the future if needed) tend to serve us >> well in the long term. > > What I want to do is define this on a per-name/per-RR basis: > > A
> > NS > > MX > > Those rules result in exactly the same usage as the current > IDNA model. I'm not asking to turn everything upside down. > What I'm asking for is that if an application needs to use an > uppercase or non-normalized domain name for some reason, that > they be allowed to do so, but only after defining a strong > profile. Eg: > > FOO > > This doesn't hurt anybody and puts the i18n namespace on equal > footing with the STD13 namespace. Well, if you want to define it on a "per-name/ per-RR" basis, which is what both your statement and your examples seem to say, I think we are 95% there. We already have per-RR rules (e.g., different name-formation rules for SRV than for A RRs) and, at least wrt what to do if one gets back a name that contains an ACE prefix, per-name rules. > Nobody has yet told me why this won't work. It seems to be that "work" has little to do with it -- this can be seen as a precision of definition problem. In that regard, it seems to me to be useful to avoid talking about "equal... to STD13 names", or "hostnames versus domain names" here, as those references are more likely to cause more confusion than to shed light. Instead, what is needed is one very clear paragraph in the IDNA document (I think). That paragraph should say that IDNA is to be used (with nameprep, etc.) for the representation of non-ASCII domain names in labels associated with RRs of type in Class=IN, that it MUST NOT (?) be used with RRs of type in Class=IN, and that it SHOULD NOT be used with RRs of type in Class=IN until and unless a standards-track specification is produced that specifies otherwise. It should say similar things about data fields (for MX, NS, CNAME, etc (?)) using similar lists. It should, I think, go on to specify that any future RR definition (in Class=IN or otherwise) needs to specify whether or not IDNA is to be applied and, preferably, should specify what happens if that statement is left out. I am assuming that , , and are disjoint, that they together include all Class=IN RRs that have been defined and not formally deprecated, and that it is possible that and/or might be null. Would that meet your needs? Is that what we are really talking about? If so, this is just a "more specification and clarity, less hand-waving and ambiguity" issue, and it is hard to be opposed to that. I think. john From owner-idn@ops.ietf.org Mon Jun 10 16:33:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24090 for ; Mon, 10 Jun 2002 16:33:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HVky-000BJ7-00 for idn-data@psg.com; Mon, 10 Jun 2002 13:27:16 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HVkv-000BIs-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 13:27:13 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140827; Mon, 10 Jun 2002 15:25:10 -0500 Message-ID: <3D050B9C.2050307@ehsco.com> Date: Mon, 10 Jun 2002 15:27:08 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: Dave Crocker , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3D04F775.4020105@ehsco.com> <132457513.1023725111@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 3:05 PM John C Klensin said the following: >>This doesn't hurt anybody and puts the i18n namespace on equal >>footing with the STD13 namespace. > > Well, if you want to define it on a "per-name/ per-RR" basis, > which is what both your statement and your examples seem to say, > I think we are 95% there. We already have per-RR rules (e.g., > different name-formation rules for SRV than for A RRs) Exactly. We already have: SRV <...> RP TXT <...> SOA <...> Allowing FOO isn't any different. [snip] > Would that meet your needs? Is that what we are really talking > about? I'm not sure I understand the suggestion. Can you rephrase it? I'm not sure that itemizing the RRs which IDNA can/cannot be used with (as is your suggestion, I think) will accomplish the ultimate goal, since the whole idea is to be able to use IDNA for any owner name which requires conversion, regardless of the profile used with that owner name. The only change that I think needs to be made is the existing ~"must be used with nameprep" statement be replaced with ~"this specification is specifically intended to be used with domain names which have processed through nameprep, but it may be used with any profile of stringprep which specifies a domain name". The specific usage rules for profiles and their IDNA interaction can be detailed in the RR-specific declarations. AMC and paf seem to be intimating that the IDNA labels may not be reversible, which may require an additional fixup if so, and if it is possible. If it isn't possible then the discussion is moot. We might as well stick with STD13 labels for i18n domain names at that point. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 18:30:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28227 for ; Mon, 10 Jun 2002 18:30:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HXRn-000EOx-00 for idn-data@psg.com; Mon, 10 Jun 2002 15:15:35 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HXRb-000EOg-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 15:15:23 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HXRX-0007Y7-00; Mon, 10 Jun 2002 15:15:19 -0700 Date: Mon, 10 Jun 2002 22:15:19 +0000 From: "Adam M. Costello" To: "Codogno Maurizio (Rozzano)" , IETF idn working group Subject: Re: [idn] some comments about draft-ietf-idn-idna-08.txt Message-ID: <20020610221519.GB27680@nicemice.net> Reply-To: IETF idn working group References: <013D3552A4BCD411AF6000508BDE8DEC712F29@misv0002.mi.saritel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013D3552A4BCD411AF6000508BDE8DEC712F29@misv0002.mi.saritel.it> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,DIFFERENT_REPLY_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Codogno Maurizio (Rozzano)" wrote: > Sect. 4.1., para 4. I think that an explicit failure condition should > be added at the various steps of the algorithm (3, 5, 8) Oh dear, we lost some crucial text between drafts 7 and 8. Draft 7 said: ToASCII fails if any step of it fails. If any step fails, the original sequence MUST NOT be used as a label in an IDN. In draft 8, this was changed to: It is important to note that the ToASCII operation can fail. If 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. Paul, we need to restore the original statement. We can also retain the new advice (the last sentence of the draft-8 version). The result would be: ToASCII fails if any step of it fails. If any step fails, the original sequence MUST NOT be used as a label in an IDN. The application needs to have some method of dealing with this failure. (Another instance of the draft-8 version still appears in section 1.1, so we don't lose anything by doing this.) > Sect 3, req. 2). "An equivalent domain name". It is a *unique* > equivalent domain name, right? Not necessarily. Punycode and ToASCII don't say whether uppercase or lowercase ASCII letters will be used in ACE labels. For example, xx--4m4a and XX--5M4A are both possible outputs of ToASCII, and both are equally valid. Among a number of equivalent labels, it doesn't matter which one you use, so we don't require any particular one of them. It's the implementor's choice. By the way, an editing error in this paragraph was fixed between idna-08 and idna-09. > Sect. 6.1, para 2. I am wondering if we SHOULD present both forms, if > the ACE label is presented. That sounds like a good option for an application to provide, but I don't think the IDNA spec ought to get into the details of user interface design; I'd rather leave it up to the application developers. We make one general recommendation regarding user interfaces: try not to show ACE to users unless they ask for it. I don't think it's our place to get into the specifics of how the user asks or how the ACE is shown. > Sect. 8. Why EDNS has not been included in the specifications? The whole point of IDNA is that it doesn't depend on any changes to the infrastructure, neither the DNS infrastructure nor any other infrastructure (like mail relays and web caches). The STD-13 DNS service is entirely sufficient for IDNA; EDNS is not needed. > As a side issue, I'd like to be pointed at some heuristic data about > Punycode. I compared Punycode (back when it was called AMC-ACE-Z) against some other algorithms: http://www.cs.berkeley.edu/~amc/idn/ace-eval.gz I didn't have a large set of test data to work with, but Punycode appears to do well for a wide variety of inputs, including ideographic, non-Latin alphabetic, Latin-based, and mixtures of those. It's very adaptive to the distribution of the input code points. I think Soobok Lee has more data (or at least, he did at one time). > Ok, you may say that I am dumb Not at all! Thank you for reviewing the drafts. AMC From owner-idn@ops.ietf.org Mon Jun 10 18:56:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28694 for ; Mon, 10 Jun 2002 18:56:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HXxd-000FKv-00 for idn-data@psg.com; Mon, 10 Jun 2002 15:48:29 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17HXxa-000FKi-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 15:48:26 -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 g5AMmLn19704; Mon, 10 Jun 2002 15:48:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20020610221519.GB27680@nicemice.net> References: <013D3552A4BCD411AF6000508BDE8DEC712F29@misv0002.mi.saritel.it> <20020610221519.GB27680@nicemice.net> Date: Mon, 10 Jun 2002 15:48:20 -0700 To: IETF idn working group From: Paul Hoffman / IMC Subject: Re: [idn] some comments about draft-ietf-idn-idna-08.txt Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk >"Codogno Maurizio (Rozzano)" wrote: > >> Sect. 4.1., para 4. I think that an explicit failure condition should >> be added at the various steps of the algorithm (3, 5, 8) > >Oh dear, we lost some crucial text between drafts 7 and 8. Draft 7 >said: > > ToASCII fails if any step of it fails. If any step fails, the > original sequence MUST NOT be used as a label in an IDN. > >In draft 8, this was changed to: > > It is important to note that the ToASCII operation can fail. If 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. > >Paul, we need to restore the original statement. We can also retain the >new advice (the last sentence of the draft-8 version). The result would >be: > > ToASCII fails if any step of it fails. If any step fails, the > original sequence MUST NOT be used as a label in an IDN. The > application needs to have some method of dealing with this failure. > >(Another instance of the draft-8 version still appears in section 1.1, >so we don't lose anything by doing this.) Adam: my first request is that you clear this kind of thing with your co-authors before you post them to the mailing list. We made that change after a lot of discussion with lots of parties, and it looks bad if one of the authors says "we need to change this" without all of us having thought about it. My second request is that you explain to me how your proposed text would work in the real world. If any step fails for one label, your text says that the original sequence must not be used, but it does not say what should be used. I think the text in -08 is clearer than what you have. Why do you want the change? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jun 10 21:04:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00396 for ; Mon, 10 Jun 2002 21:04:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HZsJ-000IkZ-00 for idn-data@psg.com; Mon, 10 Jun 2002 17:51:07 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HZsF-000IkO-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 17:51:03 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HZs7-000Heh-00; Tue, 11 Jun 2002 00:50:55 +0000 Date: Mon, 10 Jun 2002 20:50:54 -0400 From: John C Klensin To: "Eric A. Hall" cc: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <4207046.1023742254@localhost> In-Reply-To: <3D050B9C.2050307@ehsco.com> References: <3D050B9C.2050307@ehsco.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=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 10 June, 2002 15:27 -0500 "Eric A. Hall" wrote: >... > Allowing FOO isn't any different. >> Would that meet your needs? Is that what we are really >> talking about? > > I'm not sure I understand the suggestion. Can you rephrase it? > I'm not sure that itemizing the RRs which IDNA can/cannot be > used with (as is your suggestion, I think) will accomplish the > ultimate goal, since the whole idea is to be able to use IDNA > for any owner name which requires conversion, regardless of > the profile used with that owner name. Sorry, right idea (probably), wrong focus and point of attachment. The rephrase, much abbreviated, would be a list of RRs for which IDNA is applied, with the prep method used for each. I think I would do that as a small table, e.g., RR IDNA yes/no Prep method where the third column could be "n/a" or some-prep. Actually, I presume that we would either need more columns or something like RR LOC IDNA y/n Prep A label y nameprep TXT label y nameprep TXT data y ??? foo label y fooprep foo data y barprep baz label n n/a And, again, we need to be explicit that anything new, anything out of Class=IN, and anything not in the table, requires explicit standards-track action to be used with IDNA. If you don't do that, we recycle in the recent interactions, in which people insist that "undefined" has some very specific (i.e., defined) meaning for processing. Is that more clear? > The only change that I think needs to be made is the existing > ~"must be used with nameprep" statement be replaced with > ~"this specification is specifically intended to be used with > domain names which have processed through nameprep, but it may > be used with any profile of stringprep which specifies a > domain name". But I'm not sure that will be true for all time. And pretending that we know that, now, doesn't really buy us any marginal future value (which I can see, at least) and invites trouble. That said, I'm not sure the table suggested above needs to be part of the nameprep or IDNA documents. But I do think that document, if separate, needs to exist, and that the IDNA and/or nameprep docs need to normatively reference it. > The specific usage rules for profiles and their > IDNA interaction can be detailed in the RR-specific > declarations. You are proposing to put those declarations where? Certainly we should not claim that 1035, by some stretch of prescient magic, specifies application of nameprep to the legacy RRs. In case it isn't obvious, that is really a question -- I don't have a strong opinion as to where the specification goes, as long as it is written down very clearly. > AMC and paf seem to be intimating that the IDNA labels may not > be reversible, which may require an additional fixup if so, > and if it is possible. If it isn't possible then the > discussion is moot. We might as well stick with STD13 labels > for i18n domain names at that point. I don't think this changes that answer above, nor do I know what you mean by "reversible". Certainly, to the extent to which nameprep discards case, information is lost in getting to those labels. john From owner-idn@ops.ietf.org Mon Jun 10 21:19:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00800 for ; Mon, 10 Jun 2002 21:19:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HaDA-000JMu-00 for idn-data@psg.com; Mon, 10 Jun 2002 18:12:40 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HaD1-000JMb-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 18:12:31 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA11406; Mon, 10 Jun 2002 18:16:12 -0700 Message-Id: <5.1.1.2.2.20020610180835.00c3aa98@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 10 Jun 2002 18:12:23 -0700 To: John C Klensin From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: "Eric A. Hall" , IETF idn working group In-Reply-To: <126711235.1023719365@localhost> References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:29 PM 6/10/2002 -0400, John C Klensin wrote: >I'm neither supporting nor opposing Eric's proposal (intent) at >this stage, largely because I have yet to get my mind completely >around enough of the detail of what he is really suggesting to >understand its implications. But let me suggest something >slightly narrower, which I think is consistent with global >interoperability, in the hope of clarifying the conversation. Unfortunately, I am remaining highly confused. The IDNA effort is about domain NAMES. As nearly as I can tell, this thread is about domain name PARAMETERS, such as non-name fields in RRs. Although this makes for a clearly important topic, it is not relevant to IDNA. As a follow-on effort, to increase the "internationalization" of strings used for Internet standards, worrying about non-nameprep issues sounds like a dandy topic. But how, oh how, does it relate to the current set of specifications that are seeking standardization. d/ ps. you profess to still lack some clarity about this thread. for a thread that has been quite active for 2 weeks, I hope the lack of clarity bothers you. ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Jun 10 21:32:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01026 for ; Mon, 10 Jun 2002 21:32:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HaPV-000Jlr-00 for idn-data@psg.com; Mon, 10 Jun 2002 18:25:25 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HaPQ-000JkU-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 18:25:20 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140863; Mon, 10 Jun 2002 20:23:18 -0500 Message-ID: <3D05517D.6050901@ehsco.com> Date: Mon, 10 Jun 2002 20:25:17 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3D050B9C.2050307@ehsco.com> <4207046.1023742254@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 7:50 PM John C Klensin said the following: > The rephrase, much abbreviated, would be a list of RRs for which > IDNA is applied, with the prep method used for each. I think I > would do that as a small table, e.g., > > RR IDNA yes/no Prep method I think we mean we're in agreement on this. I would definitely expect such a list to be the output from the effort to classify each of the current RRs, although such a list should not be a part of IDNA specifically, but instead would be part of the classification effort. Yes? > And, again, we need to be explicit that anything new, anything > out of Class=IN, and anything not in the table, requires > explicit standards-track action to be used with IDNA. If you > don't do that, we recycle in the recent interactions, in which > people insist that "undefined" has some very specific (i.e., > defined) meaning for processing. I agree with the CLASS=IN part but I'm not sure about the standards-track requirement. Letting Apple or Microsoft or whoever make use of this stuff without political interference from antis in the IETF seems like the best way to make sure it gets used. I really want to give MS a reason to stop using STD13 high-value codes and if that means they need to come up with an NBT-A4 addressing resource record then so be it. There are other requirements they will have to comply with such as maximum names and stringprep compliance and that should be enough. > You are proposing to put those declarations where? My plan is to define the valid i18n usage of the existing RRs in the DM-IDNS-01 spec, and to provide guidelines for the creation of new RRs there as well (use nameprep if possible, must define stringprep profile if otherwise, etc). > strong opinion as to where the specification goes, as long as it > is written down very clearly. Does the above suit your requirements? >>AMC and paf seem to be intimating that the IDNA labels may not >>be reversible, which may require an additional fixup if so, >>and if it is possible. If it isn't possible then the >>discussion is moot. We might as well stick with STD13 labels >>for i18n domain names at that point. > > I don't think this changes that answer above, nor do I know what > you mean by "reversible". Certainly, to the extent to which > nameprep discards case, information is lost in getting to those > labels. That's nameprep in particular, however. What I am asking about is the IDNA encoding output, once it is separated from nameprep. The profile in use should dictate the canonical label format, not the codec. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 22:13:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01893 for ; Mon, 10 Jun 2002 22:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hazz-000Ks6-00 for idn-data@psg.com; Mon, 10 Jun 2002 19:03:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Hazx-000Krv-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 19:03:05 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140866; Mon, 10 Jun 2002 21:01:03 -0500 Message-ID: <3D055A56.7050201@ehsco.com> Date: Mon, 10 Jun 2002 21:03:02 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dave Crocker CC: John C Klensin , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610180835.00c3aa98@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 8:12 PM Dave Crocker said the following: > The IDNA effort is about domain NAMES. Yes > As nearly as I can tell, this thread is about domain name PARAMETERS, such > as non-name fields in RRs. No RRs define the syntax of their owner name as well as the syntax of the RR data. New RRs often need new domain name syntaxes, either for the owner name, or for the RR data (although it's hard to imagine an RR data domain name which isn't subsequently used for an owner name at some point). The rules currently defined in IDNA impose restrictions on the syntax of every new RR invented from here on out. While these rules are appropriate for the owner names of legacy RRs which are queried through direct input, they impose unnecessary restrictions on every subsequent RR which could ever be defined, and regardless of where the input comes from. This is a fundamental architectural design decision which needs very serious evaluation. It seems to me that it is an easy problem to avoid: decouple nameprep from the codec and the problem goes away forever, instead of hanging around forever. Nobody has told me why this is undoable. Feel free to weigh in. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Mon Jun 10 22:13:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01894 for ; Mon, 10 Jun 2002 22:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hb37-000Kzv-00 for idn-data@psg.com; Mon, 10 Jun 2002 19:06:21 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Hb2y-000Kzd-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 19:06:12 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Hb2x-00082x-00 for ; Mon, 10 Jun 2002 19:06:11 -0700 Date: Tue, 11 Jun 2002 02:06:11 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020611020611.GD27680@nicemice.net> Reply-To: IETF idn working group References: <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <3D043101.1010106@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D050B9C.2050307@ehsco.com> <132457513.1023725111@localhost> <3D04F775.4020105@ehsco.com> <3D043101.1010106@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk John C Klensin wrote: > Instead, what is needed is one very clear paragraph in the IDNA > document (I think). That paragraph should say that IDNA is to be used > (with nameprep, etc.) for the representation of non-ASCII domain names > in labels associated with RRs of type in Class=IN, that it > MUST NOT (?) be used with RRs of type in Class=IN, and that > it SHOULD NOT be used with RRs of type in Class=IN until and > unless a standards-track specification is produced that specifies > otherwise. It should say similar things about data fields (for MX, > NS, CNAME, etc (?)) using similar lists. But IDNA has to work with more than just DNS, it has to work with the wide variety of other protocols that carry domain names. By logical extension, your proposed paragraph needs to list every field/argument of every protocol/interface where IDNA may/should-not/must-not be used. Isn't that too much trouble (or even impossible)? Isn't it simpler to design IDNA so that it can safely be used for any (textual) domain label anywhere? That was our intention. "Eric A. Hall" wrote: > Resolvers, middle-boxes and replication masters all need to be able > to convert between EDNS and ACE as part of the fallback process. > Distributing the profile-specific prefix to every point where > conversion might occur is a massive problem. I was suggesting that conversion between ASCII and non-ASCII never be done inside the infrastructure except possibly when it uses the well-known standard profile; for application-specific profiles, I was suggesting that conversion be done only at the edges. This model avoids profile-agnostic conversion; only entities that know the proper profile perform the conversion, which simplifies the security analysis. Your model is based on profile-agnostic conversion happening inside the infrastructure. Let's examine how that would benefit applications. Applications interact with the infrastructure in basically two ways: sending strings into the infrastructure, and receiving strings from the infrastructure. When sending strings that use an application-specific profile into the infrastructure, the application must perform Stringprep itself, because the infrastructure needs to compare the string but doesn't know the profile. Performing Punycode and prepending the prefix is not any extra effort for the application programmer; whether the program calls Stringprep(profile) or ToASCII(profile,prefix), it's one function call either way. So there's no benefit in this case. Now let's consider applications receiving strings that use an application-specific profile. If the infrastructure cannot do profile-agnostic conversion, then the application might receive an ACE, whereas if the infrastructure can do profile-agnostic conversion, then it can ensure that the application never receives an ACE. Whether this is a benefit depends on what the application does with the string. If it compares the string, then it needs to call Stringprep at least, and calling ToASCII is no more trouble, so there's no benefit. If the application passes the string along to a non-human, ACEs are not a problem, so there's no benefit. If the application displays the string to a user, then the ACE will need decoding, whereas a non-ACE wouldn't. That's the one case I can think of where applications could benefit from profile-agnostic conversion inside the infrastructure. Now let's consider the cost of your model. Profile-agnostic conversions and comparisons can return wrong answers if the inputs are not prepared using the proper profile (whether by accident or by malice). There is nothing in the label itself to indicate the proper profile; you want to use the same prefix regardless of which profile is needed. The entities that depend on correct conversions and comparisons need to know the proper profile, and you are assuming that will be implied by context, like the DNS RR type. But IDNA is useless if it only works for DNS, it also needs to work for mail headers and SMTP commands and URIs and SSL certificates and so on. So before IDNA could be used securely in a given protocol/interface/etc, one would need to wait for the proper profile to be specified for that particular protocol/interface/etc. I'm sure that would be fine with you Eric, but it would defeat one of the main design goals of IDNA, which is to allow applications to start using it without waiting for standards to be updated. I think it's simpler to have a single conversion and comparison rule for all domain labels everywhere. In the few cases where applications need to coerce other data types into domain names while preserving mixed-case or non-normalized strings, they can define their own mapping function (which does not use the IDNA prefix), and they'll just have to do the conversion themselves with no help from the infrastructure. > we are left with the application always performing conversion. > That design blows up the architectural benefits from having the > middle-boxes do it (in particular, having the caches learn the data so > they can cache it). I don't understand this. If the conversion to/from ACE is done only in applications, then the strings on the wire are all ASCII, and caches handle them just as they always have. > FOO > > Nobody has yet told me why this won't work. I'm very leary of allowing on the left. If does not include case-folding, then two queries for names that differ only in upper/lower case could return different data. That's a fundamental departure from the current model. As for on the right, the same argument could be made for reverse queries, though I admit that reverse queries are hardly ever used. My main concerns were give above. Would it work? Maybe it would. But is it a good idea? It still seems to me that allowing multiple profiles for domain labels is more complication than it's worth. > AMC and paf seem to be intimating that the IDNA labels may not be > reversible, which may require an additional fixup if so, and if it is > possible. Punycode is reversible. It can encode any sequence of integers, and the input sequence can always be recovered exactly. Nameprep is deliberately non-reversible. It does normalization and case-folding. ToASCII is non-reversible only because it calls Nameprep. If you were to define Eric's-ToASCII, which does not call Nameprep, then it would be reversible. AMC From owner-idn@ops.ietf.org Mon Jun 10 22:43:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02772 for ; Mon, 10 Jun 2002 22:43:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HbTb-000M8t-00 for idn-data@psg.com; Mon, 10 Jun 2002 19:33:43 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HbTT-000M8M-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 19:33:35 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HbTR-00087e-00 for ; Mon, 10 Jun 2002 19:33:33 -0700 Date: Tue, 11 Jun 2002 02:33:33 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] some comments about draft-ietf-idn-idna-08.txt Message-ID: <20020611023333.GE27680@nicemice.net> Reply-To: IETF idn working group References: <013D3552A4BCD411AF6000508BDE8DEC712F29@misv0002.mi.saritel.it> <20020610221519.GB27680@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC wrote: > it looks bad if one of the authors says "we need to change this" > without all of us having thought about it. You're right, sorry. Feel free to override the Reply-To field on this message. > Why do you want the change? The big problem is that this sentence got lost between drafts 7 and 8: ToASCII fails if any step of it fails. The new text doesn't say anything like that, but it's a crucial part of the definition of ToASCII. That's why the commentor was confused about what happens if step 3, 5, or 8 fails. A much much less important issue is the choice between these: If any step fails, the original sequence MUST NOT be used as a label in an IDN. If the ToASCII operation fails on any label in a domain name, that domain name MUST NOT be used as an internationalized domain name. I think they both amount to the same thing. Neither one suggests an alternative, and they both imply that the name you're working on is no good. I prefer the former wording because ToASCII operates on an individual label, oblivious of the other labels in the same name, so it's nice if the text in the ToASCII section likewise makes no mention of the other labels in the same name. The latter wording still appears in section 1.1. If you're not convinced about this sentence, it's no big deal, but the other sentence is important. AMC From owner-idn@ops.ietf.org Mon Jun 10 23:41:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03373 for ; Mon, 10 Jun 2002 23:41:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HcJL-000Noe-00 for idn-data@psg.com; Mon, 10 Jun 2002 20:27:11 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HcJH-000NoT-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 20:27:07 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HcJH-000I6O-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 03:27:07 +0000 Date: Mon, 10 Jun 2002 23:26:50 -0400 From: John C Klensin To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <13564057.1023751610@localhost> In-Reply-To: <20020611020611.GD27680@nicemice.net> References: <20020611020611.GD27680@nicemice.net> 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=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 11 June, 2002 02:06 +0000 "Adam M. Costello" wrote: > John C Klensin wrote: > >> Instead, what is needed is one very clear paragraph in the >> IDNA document (I think). That paragraph should say that IDNA >> is to be used (with nameprep, etc.) for the representation of >>... > But IDNA has to work with more than just DNS, it has to work > with the wide variety of other protocols that carry domain > names. By logical extension, your proposed paragraph needs to > list every field/argument of every protocol/interface where > IDNA may/should-not/must-not be used. > > Isn't that too much trouble (or even impossible)? Isn't it > simpler to design IDNA so that it can safely be used for any > (textual) domain label anywhere? That was our intention. In that instance (see other note(s)), the section should be put in another document, and the IDNA one should say something a bit closer to: This protocol is an isolated piece of work that only coincidentally has anything to do with domain names. Its use with the DNS, or elsewhere, requires that a standards-track specification be written and approved by the IESG that specifies that it may be used with that other protocol and specifies the profile of stringprep to be used with it. Now, that is further than I think it is useful to actually go (in addition to making IDNA outside the charter of the IDN WG), but maybe it illustrates the point. I think you can't have it both ways. Either this is a DNS protocol, in which case it needs to specify applicable RRs and fields and may reasonably specify a prep profile --even if it can also be used for names (domain and otherwise) in other contexts-- or it is a generic internationalization protocol, in which case applicability to the DNS and domain names needs to be specified somewhere else. It seems to me that there are huge advantages to the latter. However, if we adopt that approach, we haven't completed any work on domain name internationalization until that other document is written and moved through the system. john From owner-idn@ops.ietf.org Mon Jun 10 23:51:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03554 for ; Mon, 10 Jun 2002 23:51:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HcV4-000OBx-00 for idn-data@psg.com; Mon, 10 Jun 2002 20:39:18 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HcUv-000OBj-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 20:39:09 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA14594; Mon, 10 Jun 2002 20:42:51 -0700 Message-Id: <5.1.1.2.2.20020610202805.02b43ea8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 10 Jun 2002 20:31:08 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: John C Klensin , IETF idn working group In-Reply-To: <3D055A56.7050201@ehsco.com> References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610180835.00c3aa98@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:03 PM 6/10/2002 -0500, Eric A. Hall wrote: >New RRs often need new domain name syntaxes, either for the owner >name, or for the RR data (although it's hard to imagine an RR data domain >name which isn't subsequently used for an owner name at some point). Please humor me a bit further. What RR has a domain name syntax that is different from the one used for the web and email references? What RR data has a domain name using a syntax that is different from the ones used for web and email references? In other words, as I have asked before, please describe specific scenarios in which the same domain name is interpreted differently. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Jun 10 23:53:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03628 for ; Mon, 10 Jun 2002 23:53:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HcX9-000OH4-00 for idn-data@psg.com; Mon, 10 Jun 2002 20:41:27 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HcX6-000OGr-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 20:41:24 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140870 for idn@ops.ietf.org; Mon, 10 Jun 2002 22:39:21 -0500 Message-ID: <3D057161.1060808@ehsco.com> Date: Mon, 10 Jun 2002 22:41:21 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020607062726.GA1531@nicemice.net> <3D00E13B.5015FD0B@ehsco.com> <20020608044848.GD10913@nicemice.net> <3D01A436.4060708@ehsco.com> <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <3D043101.1010106@ehsco.com> <20020611020611.GD27680@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/10/2002 9:06 PM Adam M. Costello said the following: > But IDNA has to work with more than just DNS, it has to work with the > wide variety of other protocols that carry domain names. I agree that it makes more sense to do this definition as part of the RR classification effort. > I was suggesting that conversion between ASCII and non-ASCII never > be done inside the infrastructure except possibly when it uses the > well-known standard profile; for application-specific profiles, I was > suggesting that conversion be done only at the edges. This model avoids > profile-agnostic conversion; only entities that know the proper profile > perform the conversion, which simplifies the security analysis. However, this can cause significant amounts of requery traffic for applications that pull data from DNS frequently. If a pair of applications are able to exchange UTF-8 data directly and that data resides in DNS, then the cache needs to be able to handle any fallback conversion which may be required so that it can handle the next query for that data. If the query failed at some remote point in the infrastructure (like the authoritative zone for the owner name in question), then the infrastructure would get whacked twice every time the application went to ask for that data (once for the EDNS form, again for the ACE form). This is a very serious concern and must be prevented at all costs. Conversion in the middle is the essence of a dual-mode approach. > If the > application passes the string along to a non-human, ACEs are not a > problem, so there's no benefit. That's not a correct assumption. Consider a situation where the application uses UTF-8 for all protocol data. The future is not ASCII. I am not designing for legacy systems. Those systems could only use EDNS/UTF-8 for connections and logging (and some things like SMTP relays can't even use it for that), while newer applications can use it for all kinds of stuff. This is getting into the ACE-vs-UTF-8 argument that we've already had and it's not necessarily getting us further along on the current debate. Skipping to the next section. > Now let's consider the cost of your model. Profile-agnostic conversions > and comparisons can return wrong answers if the inputs are not prepared > using the proper profile (whether by accident or by malice). There is > nothing in the label itself to indicate the proper profile; you want to > use the same prefix regardless of which profile is needed. If an application got a hold of a non-nameprep ACE domain name, the lookup would fail whenever the name was acted upon. The ACE sequence for that domain name could not be used for any of the RRs that the legacy application was looking for (A, MX, whatever). EG, if zz--goop was linked to the FOO RR then it could not be linked with an A RR, since only nameprepped owner names could have been linked to A RRs. This is the exact same scenario as trying to use a domain that only has a TXT RR for SMTP, it ain't gonna work. While it's an unexpected failure, it certainly isn't an unforseen failure, and is quite common already. However, this is a good argument against letting sister owner names exist which collapse to the same domain name. > Would it work? Maybe it would. But is it a good idea? It still > seems to me that allowing multiple profiles for domain labels is more > complication than it's worth. The problem is that this is a permanent choice. Standards are measured by their use, not their intent. > Punycode is reversible. It can encode any sequence of integers, and the > input sequence can always be recovered exactly. > > Nameprep is deliberately non-reversible. It does normalization and > case-folding. That's the way it should be. > ToASCII is non-reversible only because it calls Nameprep. > > If you were to define Eric's-ToASCII, which does not call Nameprep, then > it would be reversible. How significant would the change be to have the application call the appropriate profile prior to calling ToASCII, rather than having ToASCII make the call itself? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 02:00:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05943 for ; Tue, 11 Jun 2002 02:00:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HeWJ-0002PF-00 for idn-data@psg.com; Mon, 10 Jun 2002 22:48:43 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HeWF-0002P4-00 for idn@ops.ietf.org; Mon, 10 Jun 2002 22:48:40 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140879 for idn@ops.ietf.org; Tue, 11 Jun 2002 00:46:38 -0500 Message-ID: <3D058F35.5010406@ehsco.com> Date: Tue, 11 Jun 2002 00:48:37 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610180835.00c3aa98@jay.songbird.com> <5.1.1.2.2.20020610202805.02b43ea8@jay.songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [missed the cc list, reposted] on 6/10/2002 10:31 PM Dave Crocker said the following: > At 09:03 PM 6/10/2002 -0500, Eric A. Hall wrote: > >>New RRs often need new domain name syntaxes, either for the owner >>name, or for the RR data (although it's hard to imagine an RR data domain >>name which isn't subsequently used for an owner name at some point). > > Please humor me a bit further. > > What RR has a domain name syntax that is different from the one used for > the web and email references? SRV specifically uses a different syntax > What RR data has a domain name using a syntax that is different from the > ones used for web and email references? RP and SOA both use localpart which has a different syntax > In other words, as I have asked before, please describe specific > scenarios in which the same domain name is interpreted differently. There is a difference between syntax and interpretation. I already answered the interpretation part, which is that any eight-bit code value will be interpreted differently by every application. Use DJB's Pi test to see this for yourself if you don't believe me. Now that I have answered your questions twice, perhaps you could answer mine. What is the exact problem you foresee with allowing an application to put whatever it needs into the RRs it uses? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 03:34:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15357 for ; Tue, 11 Jun 2002 03:34:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HfyV-0005Jv-00 for idn-data@psg.com; Tue, 11 Jun 2002 00:21:55 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HfyK-0005JD-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 00:21:44 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id AAA18540; Tue, 11 Jun 2002 00:25:26 -0700 Message-Id: <5.1.1.2.2.20020611001749.00c3b088@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 11 Jun 2002 00:19:40 -0700 To: "Eric A. Hall" From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: IETF idn working group In-Reply-To: <3D058F35.5010406@ehsco.com> References: <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610105141.02079988@jay.songbird.com> <5.1.1.2.2.20020610180835.00c3aa98@jay.songbird.com> <5.1.1.2.2.20020610202805.02b43ea8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:48 AM 6/11/2002 -0500, Eric A. Hall wrote: >Now that I have answered your questions twice, perhaps you could answer >mine. What is the exact problem you foresee with allowing an application >to put whatever it needs into the RRs it uses? The simplest answer is that IDNA has nothing to do with putting anything into RRs. IDNA is about a micro layer above DNS and below applications, as it says quite explicitly in the IDNA document. Any other concerns are secondary. You seem to be insisting on pursuing a very interesting topic but in the wrong forum. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Jun 11 10:10:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25133 for ; Tue, 11 Jun 2002 10:10:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HmAR-000DVX-00 for idn-data@psg.com; Tue, 11 Jun 2002 06:58:39 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17HmAL-000DVI-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 06:58:33 -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 HAA23563; Tue, 11 Jun 2002 07:58:32 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BDwUK18304; Tue, 11 Jun 2002 15:58:31 +0200 (MEST) Date: Tue, 11 Jun 2002 15:57:19 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt To: "Eric A. Hall" Cc: IETF idn working group In-Reply-To: "Your message with ID" <3D043101.1010106@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk > Resolvers, middle-boxes and replication masters all need to be able to > convert between EDNS and ACE as part of the fallback process. Distributing > the profile-specific prefix to every point where conversion might occur is > a massive problem. Eric, tell me again how this concersion would work with DNSSEC. Erik From owner-idn@ops.ietf.org Tue Jun 11 10:10:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25153 for ; Tue, 11 Jun 2002 10:10:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hm7K-000DQM-00 for idn-data@psg.com; Tue, 11 Jun 2002 06:55:26 -0700 Received: from [151.99.229.67] (helo=pmsv0001.saritel.it) by psg.com with esmtp (Exim 3.36 #1) id 17Hm76-000DQB-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 06:55:12 -0700 Received: from butch.pm.saritel.it ([172.16.20.127]) by pmsv0001.saritel.it with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 15:59:07 +0200 Received: by butch.pm.saritel.it with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 15:48:27 +0200 Message-ID: <013D3552A4BCD411AF6000508BDE8DEC712F2F@misv0002.mi.saritel.it> From: "Codogno Maurizio (Rozzano)" To: "'IETF idn working group'" Subject: RE: [idn] some comments about draft-ietf-idn-idna-08.txt Date: Tue, 11 Jun 2002 15:51:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 Jun 2002 13:59:07.0015 (UTC) FILETIME=[270F1170:01C21150] X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Adam: Well, I hope I did not cause too much of a feud! Actually I followed closely the first year of activity in the group, so at least I had a starting point. Some of the comments I made tried to be from the side of the casual implementor. [Sect. 4.1., para 4.] IMHO, adding the sentence "ToASCII fails if any step of it fails" is enough to clarify the algorithm. > > Sect 3, req. 2). "An equivalent domain name". It is a *unique* > > equivalent domain name, right? > > Not necessarily. Punycode and ToASCII don't say whether uppercase > or lowercase ASCII letters will be used in ACE labels. oops... I forgot that mixed case may happen. You are quite right, of course. I only wanted to point out (again, since the concept is stated elsewhere) that up to upper/lowercase the conversion is unique. > By the way, an editing error in this paragraph was fixed > between idna-08 > and idna-09. I just found it in the site for the group. Was it already officially issued? [ACE labels] > We make one general recommendation regarding user interfaces: > try not to > show ACE to users unless they ask for it. I don't think it's > our place > to get into the specifics of how the user asks or how the ACE > is shown. Ok, I think I understand it. My concerns were on the line of "if a Unicode character may not be displayed, it could be useful to show the original string so that the user could notice the difference", but you are right: it is an application issue and it does not belong here. > > Sect. 8. Why EDNS has not been included in the specifications? > > The whole point of IDNA is that it doesn't depend on any changes to > the infrastructure, neither the DNS infrastructure nor any other > infrastructure (like mail relays and web caches). The STD-13 DNS > service is entirely sufficient for IDNA; EDNS is not needed. Of course it is not *needed*, but I was thinking at something a bit different. EDNS could have been shown as an *example* of a possible solution to the lengthening of labels, without any endorsing. > > As a side issue, I'd like to be pointed at some heuristic > data about > > Punycode. > > I compared Punycode (back when it was called AMC-ACE-Z) against some > other algorithms: > > http://www.cs.berkeley.edu/~amc/idn/ace-eval.gz got it, thanks. Thank you again, .mau. From owner-idn@ops.ietf.org Tue Jun 11 10:29:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26125 for ; Tue, 11 Jun 2002 10:29:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HmRT-000E21-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:16:15 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17HmRQ-000E1m-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:16:12 -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 IAA17319; Tue, 11 Jun 2002 08:16: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 g5BEG7K20539; Tue, 11 Jun 2002 16:16:07 +0200 (MEST) Date: Tue, 11 Jun 2002 16:14:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt To: Erik Nordmark Cc: "Eric A. Hall" , IETF idn working group 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=-3.5 required=5.0 tests=IN_REP_TO,FROM_AND_TO_SAME version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk > tell me again how this concersion would work with DNSSEC. Can't type today. s/concersion/conversion/ Erik From owner-idn@ops.ietf.org Tue Jun 11 10:38:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26704 for ; Tue, 11 Jun 2002 10:38:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HmZh-000EFX-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:24:45 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HmZc-000EFK-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:24:40 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140938; Tue, 11 Jun 2002 09:22:38 -0500 Message-ID: <3D060825.6040905@ehsco.com> Date: Tue, 11 Jun 2002 09:24:37 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.5 required=5.0 tests=LINES_OF_YELLING version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/11/2002 8:57 AM Erik Nordmark said the following: >>Resolvers, middle-boxes and replication masters all need to be able to >>convert between EDNS and ACE as part of the fallback process. > tell me again how this concersion would work with DNSSEC. As a placeholder, I have an RCODE for "conversion failed" which tells the original application that the data was found but that it cannot be converted. The application then has to reissue the query which the cache can answer with whatever data it has received as part of the fallback process. If the original query was provided in UTF-8 and the UTF-8 data is provided with DNNSEC there is no need for this of course. I am hoping that the DNSSEC people can help make this more efficient, but this addresses the prima concern. ACE+DNSSEC NODE: App/Resolver Cache ACE-Zone getWide()--> getWide()--> <--NOTIMPL get()--> <-- <--FALLBACKFAIL (cache ACE+DNSSEC) get()--> <-- UTF-8+DNSSEC NODE, ACE PARENT: App/Resolver Cache ACE-Parent UTF8-Zone getWide()--> getWide()--> <--NOTIMPL get()--> <-- getWide()--------------------> <-------------------- <-- <-- -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 10:55:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27669 for ; Tue, 11 Jun 2002 10:55:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hmnp-000EeQ-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:39:21 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Hmnh-000EeC-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:39:13 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 140946; Tue, 11 Jun 2002 09:37:11 -0500 Message-ID: <3D060B8E.50206@ehsco.com> Date: Tue, 11 Jun 2002 09:39:10 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: Erik Nordmark , IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <3D060825.6040905@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/11/2002 9:24 AM Eric A. Hall said the following: my turn for a typo > <-------------------- > > <-- ^^^^^^^^^^^ erroneous -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 10:56:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27743 for ; Tue, 11 Jun 2002 10:56:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HmvU-000Esp-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:47:16 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HmvJ-000EsT-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:47:05 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HmvD-000JzG-01; Tue, 11 Jun 2002 14:46:59 +0000 Date: Tue, 11 Jun 2002 10:46:24 -0400 From: John C Klensin To: Dave Crocker , "Eric A. Hall" cc: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <54344441.1023792384@localhost> 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.1 required=5.0 tests=PORN_10 version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 11 June, 2002 00:19 -0700 Dave Crocker wrote: > At 12:48 AM 6/11/2002 -0500, Eric A. Hall wrote: >> Now that I have answered your questions twice, perhaps you >> could answer mine. What is the exact problem you foresee with >> allowing an application to put whatever it needs into the RRs >> it uses? > > The simplest answer is that IDNA has nothing to do with > putting anything into RRs. > > IDNA is about a micro layer above DNS and below applications, > as it says quite explicitly in the IDNA document. > > Any other concerns are secondary. > > You seem to be insisting on pursuing a very interesting topic > but in the wrong forum. Dave, I started a much longer note yesterday in response to some of your questions, then concluded that the detail, and perhaps the whole note, was a waste of people's time. But, since the questions seem important, let me try to summarize the questions and then try to address the issues. (I believe Eric has identified all of these issues and that I am just presenting them in a different way, but that may not be correct -- I may have misunderstood some of his remarks in a way that has inspired other thoughts.) To dispose of the last question first, yes, I find that close variants of this discussion have been going on for two weeks, and we still aren't sure what the question is, to be very troubling. Given the possibility that there might be an important topic for the committee to deal with, I sat out most of those two weeks, listening and trying to understand the issues. I think that is a responsible approach, although you could (and I think have) argue that, at this late date, anything that shows up is sufficiently likely to be irrelevant that shutting down the discussion is more efficient. One result of the confusion is, I think, that we have managed to get four separate topics intertwined and conflated. That is never a good way to make progress, so I want to try to separate them back out. In semi-random order, they appear to be: (1) Is IDNA properly and adequately specified for the uses to which it will be put and is it designed appropriately for that range of uses? It seems to me that this question is relevant to any specification that IETF is considering standardizing. The answer may depend somewhat on the answer to the next question. (2) Is IDNA closely bound to internationalization of the DNS or, as you note above, is it really "about a micro layer above DNS and below applications" and hence "has nothing to do with putting anything into RRs"? And are Eric's concerns properly addressed to the IDNA specification or should they be focused somewhere else? (3) Should the applicability of IDNA in the DNS context, and the xxx-prep procedures to be used with it, be specified on a per-RR (and per-Class) basis? (4) To what extent should out-of-band communications between applications, which utilize strings which the applications might construe as internationalized domain names, influence the design of IDNA and, if so, what should the impact be? I have problems with this one, because I think it leads us straight into a rathole, especially when character sets and representations used in applications (or on particular systems) get into the mix. But, especially if IDNA is a micro layer for applications use, rather than a DNS adjunct, it seems to me that questions about the implementability, usability, and efficiency of a proposed protocol have always been fair game for discussion wherever the protocol is discussed. I'm addressing the first three of these in separate notes. I'll leave the fourth to others, but ask that they separate it into another thread so that people who don't care can more easily ignore it. john From owner-idn@ops.ietf.org Tue Jun 11 10:56:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27760 for ; Tue, 11 Jun 2002 10:56:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hmvg-000Et8-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:47:28 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HmvD-000Es9-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:46:59 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HmvD-000JzG-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 14:46:59 +0000 Date: Tue, 11 Jun 2002 10:38:15 -0400 From: John C Klensin To: idn@ops.ietf.org Subject: [idn] IDNA applicability: per RR/Class or DNS-wide (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <53855516.1023791895@localhost> 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.1 required=5.0 tests=PORN_10 version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My third issue was: Should the applicability of IDNA in the DNS context, and the xxx-prep procedures to be used with it, be specified on a per-RR (and per-Class) basis? This is the core of the substantive part of the discussion Eric and I have been having (at least to me: Eric has, I think, a slightly different focus). It has two parts: (i) The DNS now has different rules for valid label forms and parameters for different RR types (e.g., "A", "MX", etc., are recommended to contain only LDH names, while "SRV" uses names that are in ASCII but violation LDN norms) and the core DNS specification clearly anticipates an even broader range of names/ labels. IDNA should recognize this and anticipate the use of different "foo-prep" profiles of stringprep with different RR types and/or classes, rather than forcing everything into a "nameprep" model. (ii) It is unreasonable and undesirable for IDNA to specify behavior for Classes and RRs not yet invented. Constraints like that are nothing but an invitation to trouble. Suggested remedies: (1) The IDNA document should be somewhat restructured. See the "is the specification proper..." note. (2) The specification should be changed to prohibit the use of IDNA in conjunction with the DNS in the absence of a document that specifies its applicability to a specific RR type and Class. As an intermediate position between an earlier suggestion of mine and one of Eric's, those documents should be required to be standards-track for any standards-track RR; it is possible to be more flexible about others. (3) The protocol should be modified to either require that the preparation function be invoked before other IDNA steps and separate from them (Eric's preference, as I understand it), or that the preparation function be specified as a parameter to IDNA (my preference). The documents described in (2) will therefore be required to specify, for each RR type and Class to be processed with IDNA, and for labels and any relevant data (parameters) separately, the preparation function to be used. And, of course, if those documents are standards-track, then the relevant preparation function would constitute a normative reference and hence would also be required to be standards-track. Of course, such documents need not be a big deal. The type of table I anticipated in an earlier note could easily sweep in a large number of RRs and I would hope that all existing standards-track RRs could be covered by a single document. This model is just much cleaner. It makes IDNA more flexible for other uses and protocols. And it doesn't prevent the use of non-ACE systems (and binary labels generally) for RRs and Classes that are yet to be specified. This work is long overdue. It is a major and important change for the Internet and it is risky for the DNS-as-used and as perceived by users. It is, IMO, worth a bit of extra effort to get it right if we are going to do it at all. john From owner-idn@ops.ietf.org Tue Jun 11 10:56:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27788 for ; Tue, 11 Jun 2002 10:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HmvO-000Esh-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:47:10 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HmvD-000Es8-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:46:59 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HmvC-000JzG-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 14:46:58 +0000 Date: Tue, 11 Jun 2002 08:39:52 -0400 From: John C Klensin To: idn@ops.ietf.org Subject: [idn] IDNA: a micro layer above DNS or DNS internationalization ? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <46752036.1023784792@localhost> 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.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The second issue of my attempted dissection really has two parts. The first one was: Is IDNA closely bound to internationalization of the DNS or, as you note above, is it really "about a micro layer above DNS and below applications" and hence "has nothing to do with putting anything into RRs"? I have long read the charter of this WG more broadly than Dave has, but I see nothing that authorizes the WG to develop general internationalization tools or new micro layers. So, if we take the "nothing to do with the DNS" reading of what IDNA is about, then identifying IDNA documents as products of this WG was improper, the Last Call was procedurally improper since it claimed, I believe, that IDNA was a WG product, and any discussion of IDNA itself in this WG is out of charter and improper. Of course, the introduction and abstract of the IDNA specification claim just the opposite -- that it is a [proposal for a] "standard method for domain names to use characters outside the ASCII repertoire" and that it is "only meant for processing domain names, not free text". I don't believe that the community would be well served by hairsplitting about charter boundaries in this case. But, if we are flexible in that regard, and accept IDNA as DNS-related enough to be within this WG's scope, it seems to me that the DNS implications of IDNA, including whether it is properly specified for DNS use, become part of the WG mainstream. Logically, the alternative would be for the Last Call to be withdrawn and repeated as a "not a WG product" one and for this WG to start work on a DNS internationalization profile for IDNA that normatively references the "micro layer" IDNA specification. The second part of this issue flows from the above: [And] are Eric's concerns properly addressed to the IDNA specification or should they be focused somewhere else? I am increasingly convinced that most of them do not belong in the IDNA specification, but that (i) The WG has not completed its work to the extent that anything is appropriate for interoperable use with the DNS until the complementary specification is written and placed on the Standards Track. (ii) Separating them may require a substantive change to the way the IDNA specification is written, but not necessarily the way that IDNA operates. In either case, that new specification is definitely part of the necessary subject matter for this WG, even if IDNA is not. john From owner-idn@ops.ietf.org Tue Jun 11 10:57:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27842 for ; Tue, 11 Jun 2002 10:57:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hmvq-000EtO-00 for idn-data@psg.com; Tue, 11 Jun 2002 07:47:38 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HmvD-000EsA-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 07:46:59 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HmvC-000JzG-01 for idn@ops.ietf.org; Tue, 11 Jun 2002 14:46:59 +0000 Date: Tue, 11 Jun 2002 09:59:36 -0400 From: John C Klensin To: idn@ops.ietf.org Subject: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <51536347.1023789576@localhost> 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=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The first of my four separated issues was: Is IDNA properly and adequately specified for the uses to which it will be put and is it designed appropriately for that range of uses? One thing that Dave and I (among many others) have generally agreed on over the years is that the primary goal of IETF specification work is to enable and promote interoperability. Without interoperability, we have nothing. So a different version of the above question is "is the IDNA specification, including all normatively referenced and referencing documents in addition to draft-ietf-idna-09, sufficient to enable interoperability, or are additional or different specifications needed". I think the answer is probably that more specification, tightly bound to IDNA, is needed. In terms of the sequencing of things, I believe that the beginning of serious work on those specifications will expose specification problems with the current IDNA spec. To the degree to which that is true (and I give some examples below), I believe that IETF procedures and precedents dictate that IDNA should either be published as Experimental or held as an I-D until there is adequate proof of concept that the specification meets the needs of at least a sample of the standards that will utilize it. Examples of issues with the specification (few, if any, of these are issues with the protocol): (i) The specification now appears to say that applications can decide to use IDNA or not. Presumably, they can decide to use something else instead. It is also not clear whether "an application", as used in the spec, refers to a standard protocol and expectations about how all conforming implementations will behave or to particular implementations and implementation choices. That is not how to get interoperability, since a reading/receiving application will have no idea how to interpret a string it receives. And "receives" is key: if an implementation issues a query in a form that appears to be an ACE, it presumably knows what it intends, although there may be "cut and paste" scenarios to the contrary. But, if an application does a DNS lookup for an LDH name (with no prefix) with, say, an MX Qtype, and some of the result data are returned with IDNA-appearing prefixes, then the application needs additional clues as to how to present error messages to the user, how to continue processing in other areas, etc. While it is not necessary (or possible) for the IDNA specification to detail how it is used by all applications, setting traps for applications without advice as to how they can be avoided does not seem to me to be acceptable -- or promoting of interoperability. (ii) The specification seems inconsistent about what it about and who needs to understand it. It implies in several places that it is not about the DNS and has no impact on the DNS. But it then makes and imposes normative DNS operational statements. E.g., "Non-ACE labels that begin with the ACE prefix will confuse users and SHOULD NOT be allowed in DNS zones" is certainly a requirement about DNS and DNS zone population. (iii) Despite the "applications can choose to do this, or not do it" language, section 6.4 effectively implies a requirement that any application that uses the DNS be upgraded. That is a fairly sweeping requirement given that we lack documents that tell applications about other implications of doing that and that the introductory material of the document imply that no such recommendations will appear. This sort of thing creates a full-employment situation for protocol lawyers, which is something else we usually try to avoid. (iv) Section 7 imposes several normative requirements on name servers and zone populations. Again, these requirements are buried in a document that elsewhere appears to claim that it doesn't impact the DNS. The third paragraph of section 7 seems to contradict or repeal the statements of RFC 2181 that non-ASCII strings are permitted in labels and to do so broadly enough that it would prohibit uses favored by those who believe that the language in 2181 is a mistake. (v) In particular, several of the statements in the draft go beyond almost anything we have about the DNS in trying to narrowly constrain the behavior of RR labels and data that are not yet defined, even in Classes that are not yet defined. This seems overreaching and unwise as well as confrontational with RFC 2181 (which it, interestingly, does not cite). (vi) I suggest that it is a useful general principle to design service ("micro layer" to use Dave's term) protocols to be as general as feasible without making them overly complex. Doing so facilitates reuse and reduces opportunities for non-interoperability by making it explicit where variations can occur. It was, I believe, more or less this principle that led to the reformulation of the nameprep/stringprep boundary. IDNA, by specifying nameprep profiling as part of the procedure, violates this principle by effectively requiring a one-off protocol for situations in which nameprep is inappropriate but other IDNA steps would be reasonable. My conclusions from the above are: The IDNA specification has rolled together a collection of an intermediate layer protocol, advice to applications, and normative requirements on DNS use and operations (and, if a requirement that a name server MUST NOT serve particular forms that are permitted by RFC 1034/1035 and 2181 is intended, a DNS protocol change). At the same time, it handwaves about applications adoption and does not adequately distinguish between "application" and "implementation of an application". Parts of it are also much broader that is required for its purposes and are clearly beyond the scope of IDN WG competence as a primary reviewer/approver. The most striking example of this is the apparent restriction to ASCII in labels and data/parameter strings for all name servers, all RRs, and all Classes. It should be revised and some of that material should be pulled out and into separate documents. As an alternative, that material should be highlighted: the abstract and introductory material should indicate that these normative DNS requirements are present, that 2181 is explicitly updated, and so on. Finally, the apparent reach of the protocol should be narrowed and specified, either in this document or elsewhere. And the protocol should recognize the reason for, and implications of, the nameprep/stringprep split and be remodularized to permit the IDNA _sequence_ to be used with other profiles when appropriate. That topic is discussed in more detail in another message. john From owner-idn@ops.ietf.org Tue Jun 11 13:15:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03700 for ; Tue, 11 Jun 2002 13:15:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hp6t-000JEB-00 for idn-data@psg.com; Tue, 11 Jun 2002 10:07:11 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Hp6j-000JDt-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 10:07:01 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA01328; Tue, 11 Jun 2002 10:10:44 -0700 Message-Id: <5.1.1.2.2.20020611095420.020118e8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 11 Jun 2002 10:05:02 -0700 To: John C Klensin From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: "Eric A. Hall" , IETF idn working group In-Reply-To: <54344441.1023792384@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,PORN_10,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Looking forward to your detailed notes, I'll offer some sound bites: At 10:46 AM 6/11/2002 -0400, John C Klensin wrote: >(1) Is IDNA properly and adequately specified for the uses to >which it will be put and is it designed appropriately for that >range of uses? Basically, IDNA replicates the model of MIME. If there are problems with it, they are in the category of the usual, initial specification detail bugs that will be fixed as the document moves to Draft. I haven't noticed any such detail bugs being cited yet. It does not appear that there are any problems with the model. The model has been incrementally improved and strikes me as having gotten quite clean at this point, for the purpose it is designed to serve. >(2) Is IDNA closely bound to internationalization of the DNS or, >as you note above, is it really "about a micro layer above DNS >and below applications" and hence "has nothing to do with >putting anything into RRs"? Is MIME closely bound to multi-media email or is it a micro-layer above email? The answer is yes to both parts, rather than representing mutually exclusive conditions, as the question implies. That the general topic of internationalization is difficult and multifaceted will come as no surprise to folks who work on that challenging arena. That it can benefit from divide and conquer should come as no surprise to folks experienced with IETF work. To repeat: Messing with RRs, for FURTHER internationalization sounds like a dandy idea. Messing with RRs as part of IDNA will only have the effect of adding another couple of years of delay. >(3) Should the applicability of IDNA in the DNS context, and the >xxx-prep procedures to be used with it, be specified on a per-RR >(and per-Class) basis? An excellent starting question, for a separate, follow-on effort for FURTHER internationalization of the DNS. >(4) To what extent should out-of-band communications between >applications, which utilize strings which the applications might >construe as internationalized domain names, influence the design >of IDNA and, if so, what should the impact be? I think your question nicely captures a source of confusion that is currently present. My own answer is that a) making the scope of such an effort too large is a good way to ensure that it never gets done; however it is often easy to have that larger scope as a background agenda that is serviced along the way. b) we are some years too late for visiting that question upon this effort. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Tue Jun 11 14:55:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08230 for ; Tue, 11 Jun 2002 14:55:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HqbX-000Lvv-00 for idn-data@psg.com; Tue, 11 Jun 2002 11:42:55 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17HqbQ-000Lvg-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 11:42:48 -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 MAA29606; Tue, 11 Jun 2002 12:42:47 -0600 (MDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BIggK16887; Tue, 11 Jun 2002 20:42:43 +0200 (MEST) Date: Tue, 11 Jun 2002 20:39:37 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] dual mode To: "Eric A. Hall" Cc: Erik Nordmark , IETF idn working group In-Reply-To: "Your message with ID" <3D060825.6040905@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk [I changed the subject line] > > tell me again how this concersion would work with DNSSEC. > > As a placeholder, I have an RCODE for "conversion failed" which tells the > original application that the data was found but that it cannot be > converted. The application then has to reissue the query which the cache > can answer with whatever data it has received as part of the fallback > process. If the original query was provided in UTF-8 and the UTF-8 data is > provided with DNNSEC there is no need for this of course. > > I am hoping that the DNSSEC people can help make this more efficient, but > this addresses the prima concern. Yes, the examples you provided make the RRset go end-to-end so the signatures would work. Presumably the benefits of this scheme is that that caching resolver can cache both the FALLBACKFAIL RCODE for the QNAME and the actual RRsets for the QNAME, so that other queries immediately get the FALLBACKFAIL error and retry using the ACE form. I'm not an expert in DNS (I haven't even read RFC 2308) so I don't know what the issues is with negative caching in general, thus I can't tell if this scheme introduces new issues. Also, it isn't clear to me if the caching resolver needs to ensure that the negative cache for the and the RRsets for the expire in concert (or there are some other constraints on how they expire). It would make sense to consult with folks on namedroppers for this. Erik From owner-idn@ops.ietf.org Tue Jun 11 15:42:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09551 for ; Tue, 11 Jun 2002 15:42:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HrRo-000NS3-00 for idn-data@psg.com; Tue, 11 Jun 2002 12:36:56 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 17HrRk-000NRr-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 12:36:52 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/5JQSzxVqG14W5SpBdDyoyg=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G42ZRGDQ; Tue, 11 Jun 2002 15:33:59 EDT To: dhc@dcrocker.net Cc: idn@ops.ietf.org Date: Tue, 11 Jun 2002 12:32:44 -0700 Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020611.123244.1072.1.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye X-Spam-Status: No, hits=2.1 required=5.0 tests=PORN_10,FORGED_JUNO_RCVD version=2.20 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John has a good separation of the issues and I'd like to offer a different view point from yours following the topics. > At 10:46 AM 6/11/2002 -0400, John C Klensin wrote: > >(1) Is IDNA properly and adequately specified for the uses to > >which it will be put and is it designed appropriately for that > >range of uses? > > Basically, IDNA replicates the model of MIME. If there are problems > with > it, they are in the category of the usual, initial specification > detail > bugs that will be fixed as the document moves to Draft. I haven't > noticed > any such detail bugs being cited yet. > > It does not appear that there are any problems with the model. The > model > has been incrementally improved and strikes me as having gotten > quite clean > at this point, for the purpose it is designed to serve. No, IDNA does not replicate the model of MIME. MIME deals with programmer-defined data types: multi-media. These are well defined data types, and all MIME does is to provide multiple channels - in sequence or in parallel to accommodate them. IDNA has to consider charsets which can be an analogy to multi-media, or I shall call them multi-charset in term of LDH, Utf8, Utf16, GB, BIG5... IDNA has to consider UCS too, which reflexes the history of character sets 1) used by user groups and 2) existed for thousands of years and 3) no update limit can be called upon. Assume we can define how many user groups in terms of charset can be handled in IDNA, IDNA still has to deal with two infinity problems: a) the long history brought to us by different groups use the same character set, such as Arabic, CJK, and Latin. I would call this multi-culture problem. b) USC has to stay open for more update on new glyphs to be allowed into the set, this is pointing to trademark problem, which we at IETF are supposed to provide a feasible solution for. I call this open-glyph problem. In one word, IDNA at least is two folds more complex then MIME. > >(2) Is IDNA closely bound to internationalization of the DNS or, > >as you note above, is it really "about a micro layer above DNS > >and below applications" and hence "has nothing to do with > >putting anything into RRs"? > > Is MIME closely bound to multi-media email or is it a micro-layer > above > email? > > The answer is yes to both parts, rather than representing mutually > exclusive conditions, as the question implies. > > That the general topic of internationalization is difficult and > multifaceted will come as no surprise to folks who work on that > challenging > arena. That it can benefit from divide and conquer should come as > no > surprise to folks experienced with IETF work. > > To repeat: Messing with RRs, for FURTHER internationalization > sounds like > a dandy idea. Messing with RRs as part of IDNA will only have the > effect > of adding another couple of years of delay. So, I agree, existing RRs are well defined to handle charsets, there is no room to messing around with them. > >(3) Should the applicability of IDNA in the DNS context, and the > >xxx-prep procedures to be used with it, be specified on a per-RR > >(and per-Class) basis? > > An excellent starting question, for a separate, follow-on effort for > FURTHER internationalization of the DNS. This is the question we are facing and due to be dealt with. This is the essence of CDNC Final Comments on Last call of IDN drafts. The WG at IETF has to provide an infinitly-many solution to deal with the two infinity problems: multi-culture and open-glyph. > >(4) To what extent should out-of-band communications between > >applications, which utilize strings which the applications might > >construe as internationalized domain names, influence the design > >of IDNA and, if so, what should the impact be? > > I think your question nicely captures a source of confusion that is > currently present. > > My own answer is that > > a) making the scope of such an effort too large is a good > way to ensure that it never gets done; however it is often easy > to have that larger scope as a background agenda that is > serviced along the way. > > b) we are some years too late for visiting that question > upon this effort. This question has been looked at many times in the past, and every time we have decided to postpone the issue. If you say it is too late to visit this issue again, then you are definitly repeating the past. It is certainly true, we have made progress in understanding the problem :-) Liana Ye From owner-idn@ops.ietf.org Tue Jun 11 16:20:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10854 for ; Tue, 11 Jun 2002 16:20:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hs1L-000OYz-00 for idn-data@psg.com; Tue, 11 Jun 2002 13:13:39 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Hs19-000OYg-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 13:13:27 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Hs15-0001dn-00; Tue, 11 Jun 2002 13:13:23 -0700 Date: Tue, 11 Jun 2002 20:13:23 +0000 From: "Adam M. Costello" To: "Codogno Maurizio (Rozzano)" , IETF idn working group Subject: Re: [idn] some comments about draft-ietf-idn-idna-08.txt Message-ID: <20020611201323.GA6147@nicemice.net> Reply-To: IETF idn working group References: <013D3552A4BCD411AF6000508BDE8DEC712F2F@misv0002.mi.saritel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013D3552A4BCD411AF6000508BDE8DEC712F2F@misv0002.mi.saritel.it> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,DIFFERENT_REPLY_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Codogno Maurizio (Rozzano)" wrote: > > By the way, an editing error in this paragraph was fixed between > > idna-08 and idna-09. > > I just found it in the site for the group. Was it already officially > issued? I think so. > EDNS could have been shown as an *example* of a possible solution to > the lengthening of labels, without any endorsing. If EDNS is used to create labels that are too long for IDNA, then there will be incompatibility between the old infrastructure and the new applications. The issue of how or whether to use EDNS for IDNs is still too controversial. AMC From owner-idn@ops.ietf.org Tue Jun 11 17:58:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14381 for ; Tue, 11 Jun 2002 17:58:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HtWj-0001tA-00 for idn-data@psg.com; Tue, 11 Jun 2002 14:50:09 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17HtWf-0001sz-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 14:50:05 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141049; Tue, 11 Jun 2002 16:48:04 -0500 Message-ID: <3D06708B.4010002@ehsco.com> Date: Tue, 11 Jun 2002 16:50:03 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: IETF idn working group Subject: [idn] Re: dual mode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/11/2002 1:39 PM Erik Nordmark said the following: > Presumably the benefits of this scheme is that that caching resolver > can cache both the FALLBACKFAIL RCODE for the QNAME and the > actual RRsets for the QNAME, so that other queries > immediately get the FALLBACKFAIL error and retry using the ACE form. The primary benefit is that DNSSEC works at all. For subsequent queries, the application has explicitly stated interest in UTF-8 data, so it needs to be told that the data isn't available, and that the data that *is* available can't be converted. The resolver probably won't enter into any decisions that the application makes as to what to do next. I'm sure the DNSSEC brains can find a dozen ways to streamline and simplify this. This is only presented to make it work. > I'm not an expert in DNS (I haven't even read RFC 2308) so I don't know > what the issues is with negative caching in general, thus I can't tell > if this scheme introduces new issues. Not this scheme in particular, although there are negative caching issues in general. A "negative cache" works by getting a negative response and some supporting data from a server (such as an SOA for the zone). In the case of a NOTIMPL response to an EDNS question, however, there is no supporting information (the server couldn't read the question section, so it can't provide an SOA). There are simple ways to deal with the problem, such as using TTL information from the resulting STD13 query (the NS and/or SOA RRs in the authority section). For the most part, the existing negative caching knowledge work without any difficulies, and only a couple of new landmines. Some of these have resulted from changes in the fallback model itself (DM-IDNS-00 did not have servers performing fallback more than once on the first query, but this is necessary change to support DNSSEC, and has introduced other issues). > Also, it isn't clear to me if the caching resolver needs to ensure that > the negative cache for the and the RRsets for the > expire in concert (or there are some other constraints on how they > expire). Domain names in general are supposed to be stored as UCS strings, not as views of a string. This model allows the cache to construct a view based on the incoming message format, without having to track 2x the data. In that design, all expirations occur whenever the base entry expires. For the most part, the well-known and understood negative caching rules can apply without any additional effort, although there are some peculiar issues (as with NOTIMPL described above). The biggest difficulties are in managing the RR data. > It would make sense to consult with folks on namedroppers for this. Yeah, DM-IDNS-01 will be brought to them for discussion. I need to find out what kind of architectural ramifications will be imposed by the IDNA spec before I can finish writing this up, however. Contrary to certain commentary, the current rules wrt nameprep being mandatory impose multiple considerations on the design, as well as on the future use of RRs within DNS in general. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 17:59:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14413 for ; Tue, 11 Jun 2002 17:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HtXr-0001vS-00 for idn-data@psg.com; Tue, 11 Jun 2002 14:51:19 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HtXh-0001up-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 14:51:09 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HtXf-0001rn-00 for ; Tue, 11 Jun 2002 14:51:07 -0700 Date: Tue, 11 Jun 2002 21:51:07 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Message-ID: <20020611215107.GC6147@nicemice.net> Reply-To: IETF idn working group References: <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <3D043101.1010106@ehsco.com> <20020611020611.GD27680@nicemice.net> <3D057161.1060808@ehsco.com> <20020611020611.GD27680@nicemice.net> <13564057.1023751610@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.2.2.20020611095420.020118e8@jay.songbird.com> <54344441.1023792384@localhost> <3D057161.1060808@ehsco.com> <13564057.1023751610@localhost> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SOCIAL_SEC_NUMBER,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk [This message replies to messages from both Eric Hall and John Klensin.] "Eric A. Hall" wrote: > > I was suggesting that conversion between ASCII and non-ASCII never > > be done inside the infrastructure except possibly when it uses the > > well-known standard profile; for application-specific profiles, I > > was suggesting that conversion be done only at the edges. This > > model avoids profile-agnostic conversion; only entities that know > > the proper profile perform the conversion, which simplifies the > > security analysis. > > If the query failed at some remote point in the infrastructure (like > the authoritative zone for the owner name in question), then the > infrastructure would get whacked twice every time the application went > to ask for that data (once for the EDNS form, again for the ACE form). I guess I still wasn't clear enough. For labels that use application-specific profiles, there would not be two forms inside the infrastructure, only one form. The application would always convert to/from that form at the edges as necessary. Inside the infrastructure, dual forms would be used only for labels that use the standard profile. This adds a small burden to applications that don't use the standard profile, but it significantly simplifies the model. > This is a very serious concern and must be prevented at all costs. I think that's an exaggeration. A factor-of-two increase in overhead (which I'm not proposing, but even if I were) would not bring down the network. It would be small compared to the exponential growth of the internet. > How significant would the change be to have the application call the > appropriate profile prior to calling ToASCII, rather than having > ToASCII make the call itself? Whether Stringprep is called inside ToASCII or before ToASCII is beside the point. The real question is "How significant would the change be to allow IDNA to use more than one profile?" It would be a fundamental change that greatly complicates the model. Here are some more examples of the complications: What happens when two labels that use different profiles are compared? They might be identical in their UTF-8 forms but different in their ASCII forms, so you might get a different answer depending on which form they're in. Do we need to prohibit the comparison of labels that use different profiles? Old software cannot possibly be aware of such a prohibition. What are the security implications? How can we prohibit such comparisons and still allow DNS ANY queries, which by their nature need to compare the same query string against many names associated with many different RR types? The same issue arises when a domain label is copied from one slot to another, and the two slots call for different profiles. Does that need to be prohibited? Old software cannot be aware of the prohibition. What are the security implications? What if someone wants to associate multiple RR types with the same name, and those RR types call for different profiles? What profile should the owner name of a CNAME record use? Should there be a single profile for all CNAME records? If so, which profile? Or should the owner of a CNAME record use the same profile as the name it refers to? If so, what happens when the latter name is in another zone and its RR type gets changed without notice? What are the security implications? Is it possible to create subdomains of domains that use non-standard profiles? If so, a single domain name might need a different profile for each label. But each name is associated with only one RR type. The RR type might imply which profile to use for the first label (or the first k labels), but what about the rest? Eric, you are obviously a smart guy, and it wouldn't surprise me if you could solve all these issues, but I think the multi-profile model is too complex and too subtle to be worth its modest benefits. The single-profile model covers the common case, and applications that can't use the standard profile can still do what they need to do, as long as they do it outside the infrastructure (before converting their data types into domain names, and after converting domain names back into their data types). An analogy might help clarify that model. Each U.S. citizen typically has a social security number, which is nine digits. It is possible (and in fact trivial) to map social security numbers onto domain labels; for example, 123456789.nicemice.net. Domain labels can contain letters, but that doesn't mean social security numbers can contain letters. Domain labels and social security numbers are two entirely distinct data types. Similarly, data types like email address local parts are not domain labels, even if they are sometimes mapped onto domain labels. Just because domain labels can (soon) contain non-ASCII characters, that doesn't mean email address local parts can. RFC 2822 says they are ASCII, so they can't contain non-ASCII characters until someone defines internationalized email address local parts. IDN labels do not preserve case or non-normalized forms. If an application needs to map a data type onto a domain label, and the data type contains non-ASCII text for which mixed-case forms or non-normalized forms must be preserved, then the trivial mapping simply won't work. The application will need to design a more complex mapping to suit its needs. For example, when internationalized email address local parts are defined, that specification will have the opportunity to say how they get mapped onto domain labels. Whenever you try to use one data type to represent another data type, you might get lucky and find that it's trivial, or there might be a mismatch and you might have to do more complex mapping/encoding. That's just the way it goes. John C Klensin wrote: > Either this is a DNS protocol, in which case it needs to specify > applicable RRs and fields and may reasonably specify a prep > profile --even if it can also be used for names (domain and otherwise) > in other contexts-- or it is a generic internationalization protocol, > in which case applicability to the DNS and domain names needs to be > specified somewhere else. It is neither. Domain name is a data type that is used in many many protocols, and DNS is just one of them. IDNA is a technique for enabling applications to use non-ASCII characters in domain names, regardless of which protocol/interface those domain names are traversing. IDNA is not a generic internationalization protocol; it applies only to domain names. IDNA is not an extension of DNS; it is not specific to any particular protocol. [In another note you point out several places where the IDNA spec seems to get too far into the guts of DNS. I agree with a lot of that. I personally have kept a closer watch on sections 2 through 4 (which I wrote the first draft of, and which say nothing about DNS) than on the other sections (which existed before I got here).] > (4) To what extent should out-of-band communications between > applications, which utilize strings which the applications might > construe as internationalized domain names, influence the design of > IDNA and, if so, what should the impact be? I'm not sure what you mean as "out-of-band" and "might construe". The domain names that appear in SMTP MAIL and RCPT commands are, I would say, very much in-band, and there's no "construing", they are unmistakably domain names. If we are going to enable non-ASCII characters in domain names in DNS, but not in other protocols, what's the point? AMC From owner-idn@ops.ietf.org Tue Jun 11 18:06:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14652 for ; Tue, 11 Jun 2002 18:06:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Htgv-0002HD-00 for idn-data@psg.com; Tue, 11 Jun 2002 15:00:41 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Htgn-0002Gw-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 15:00:33 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Htgn-0001tV-00 for ; Tue, 11 Jun 2002 15:00:33 -0700 Date: Tue, 11 Jun 2002 22:00:32 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] IDNA applicability: per RR/Class or DNS-wide Message-ID: <20020611220032.GD6147@nicemice.net> Reply-To: IETF idn working group References: <53855516.1023791895@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53855516.1023791895@localhost> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk John C Klensin wrote: > (i) The DNS now has different rules for valid label forms and > parameters for different RR types (e.g., "A", "MX", etc., are > recommended to contain only LDH names, while "SRV" uses names that > are in ASCII but violation LDN norms) and the core DNS specification > clearly anticipates an even broader range of names/ labels. IDNA > should recognize this and anticipate the use of different "foo-prep" > profiles of stringprep with different RR types and/or classes, rather > than forcing everything into a "nameprep" model. Different validity rules is not at all the same thing as different profiles. The profile is mainly about how labels are compared. In DNS now, the same comparison rules apply to all labels. If we allow multiple profiles, that's the same as allowing different comparison rules for different labels. I have no problem with different RR types imposing additional restrictions on what is valid. IDNA already anticipates restrictions in addition to (not instead of) Nameprep: It is expected that some name-handling bodies, such as large zone administrators and groups of affiliated zone administrators, will want to limit the characters allowed in IDNs further than what is specified in this document, such as to prohibit additional characters that they feel are unneeded or harmful in registered domain names. AMC From owner-idn@ops.ietf.org Tue Jun 11 18:27:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15105 for ; Tue, 11 Jun 2002 18:27:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hu0w-00037M-00 for idn-data@psg.com; Tue, 11 Jun 2002 15:21:22 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Hu0t-000374-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 15:21:19 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141059 for idn@ops.ietf.org; Tue, 11 Jun 2002 17:19:18 -0500 Message-ID: <3D0677DC.7050705@ehsco.com> Date: Tue, 11 Jun 2002 17:21:16 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] IDNA applicability: per RR/Class or DNS-wide References: <53855516.1023791895@localhost> <20020611220032.GD6147@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/11/2002 5:00 PM Adam M. Costello said the following: > John C Klensin wrote: > Different validity rules is not at all the same thing as different > profiles. The profile is mainly about how labels are compared. In > DNS now, the same comparison rules apply to all labels. If we allow > multiple profiles, that's the same as allowing different comparison > rules for different labels. I have to disagree with this again. The comparison rules will be identical for all profiles -- each of them comparing exact sequences of octets -- with the only difference being the capitalization and normalization rules that get used to generate the question. That's it. The question formation differs, comparison is identical. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 19:45:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16706 for ; Tue, 11 Jun 2002 19:45:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hv6w-0005dU-00 for idn-data@psg.com; Tue, 11 Jun 2002 16:31:38 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Hv6s-0005dJ-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 16:31:34 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141068 for idn@ops.ietf.org; Tue, 11 Jun 2002 18:29:32 -0500 Message-ID: <3D068853.6010600@ehsco.com> Date: Tue, 11 Jun 2002 18:31:31 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt References: <20020609205101.GC28757@nicemice.net> <3D03DB02.10602@ehsco.com> <20020610021643.GA31046@nicemice.net> <3D0417BC.5030900@ehsco.com> <20020610033355.GA20722@nicemice.net> <3D043101.1010106@ehsco.com> <20020611020611.GD27680@nicemice.net> <3D057161.1060808@ehsco.com> <20020611020611.GD27680@nicemice.net> <13564057.1023751610@localhost> <20020611215107.GC6147@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/11/2002 4:51 PM Adam M. Costello said the following: > [This message replies to messages from both Eric Hall and John Klensin.] >>If the query failed at some remote point in the infrastructure (like >>the authoritative zone for the owner name in question), then the >>infrastructure would get whacked twice every time the application went >>to ask for that data (once for the EDNS form, again for the ACE form). > > I guess I still wasn't clear enough. For labels that use > application-specific profiles, there would not be two forms inside the > infrastructure, only one form. The application would always convert > to/from that form at the edges as necessary. Inside the infrastructure, > dual forms would be used only for labels that use the standard profile. > This adds a small burden to applications that don't use the standard > profile, but it significantly simplifies the model. You are essentially arguing for maintaining two different DNS networks: one for nameprep and one for "other". I don't see how that simplifies anything. One DNS network where the servers store raw UCS sequences and provide answers based on the query message is much simpler than using one model for some RRs and another model for other RRs. >>This is a very serious concern and must be prevented at all costs. > > I think that's an exaggeration. A factor-of-two increase in overhead > (which I'm not proposing, but even if I were) would not bring down the > network. It would be small compared to the exponential growth of the > internet. The problem is that it's all cumulative. There are three potential threats to DNS growth: query rate, server cache sizes and bandwidth. Bandwidth utilization is pretty low even for the .com TLD (less than a T3, last time I looked). Cache sizes aren't threatened yet either. However, the query-per-second rate is already very high. Add to that the other efforts underway -- ENUM wants to give every phone number a domain name and multiple RRs to play with, people want to put certificates in DNS and "only" add a few million TCP connections to the load -- and you see how it all adds up. Worse, you can't just add servers because the message size is limited (well you can do stuff with anycast hacks and people are looking at that stuff, but you can't just add more servers). Query rate is a very, very serious matter as it is the most likely source of any short-term usage cap, especially if everybody gets everything they want. >>How significant would the change be to have the application call the >>appropriate profile prior to calling ToASCII, rather than having >>ToASCII make the call itself? > > Whether Stringprep is called inside ToASCII or before ToASCII is beside > the point. I think it is the essence of the question. An application which is calling ToASCII at all has an i18n domain name they have to work with, so they have to validate the domain name anyway. If they have to do this anyway, why does IDNA even need to do it at all? Surely you weren't planning on people offloading basic integrity checks to IDNA? > What happens when two labels that use different profiles are compared? > They might be identical in their UTF-8 forms but different in their > ASCII forms, so you might get a different answer depending on which form > they're in. I've already said twice that two domain names should not be allowed to exist if they collapse to the same sequence (if they normalize to the same string). As such, there is zero danger of this happening. Looking at this hypertechnically, I don't personally believe that this is necessary (what happens when anybody provides a typo domain name? they get the right answer to the wrong question), but I believe that it is better to prevent confusion and I've already advocated this restriction twice. No argument here, move along. > Do we need to prohibit the comparison of labels that use different > profiles? No, because different profiles should result in different octet sequences. If two domain names share the same sequence, they have violated the rule above about collapsing to the same domain name. > Old software cannot possibly be aware of such a > prohibition. What are the security implications? How can we prohibit > such comparisons and still allow DNS ANY queries, which by their nature > need to compare the same query string against many names associated with > many different RR types? See above. You are working under the impression that the profiles will be treated differently during comparison -- and you stated as much in your not to John -- while this is absolutely wrong. All i18n zone data will be stored as octet sequences. All comparison will be for octet strings. The only time a server would need to do anything active with the data is when it was piped from one format to another, and even that one step should not require any knowledge of the preparation rules; just run it through the codec and voila. > What if someone wants to associate multiple RR types with the same name, > and those RR types call for different profiles? Prohibited. If an RR needs to reuse existing domain names then it will have to use the profile for that RR. In the common case, new RRs will always use nameprep since they many of them will want to take advantage of zone domain names. But if one of these RRs needs to store data in some other domain name then it can certainly reference that other (non-nameprp) domain name in the RRdata. > What profile should the owner name of a CNAME record use? I've said multiple times (check the archives) that the owner name of a CNAME will inherit the stringprep rules associated with the domain name in the RRdata target. > If so, what happens when the latter name is in another zone and its RR > type gets changed without notice? Presumably the owner name of the target will also change to suit the profile of the new RR, thus invalidating the CNAME RR. If by some chance the two profiles use the exact same syntax rules then the CNAME will still fail because the RR type of the target has also changed. I mean, if a custom RR of type FOO is changed to custom RR of type BAR, any application that is looking for FOO at CNAME won't find it. > Is it possible to create subdomains of domains that use non-standard > profiles? I'm not sure I understand your question but if you are asking if it is possible to create a subdomain delegation without using nameprep the answer is no. Zone delegation requires NS RRs which uses nameprep for the owner and data. If you are asking if it is possible to create a multilabel owner name within a current zone then sure. If you are asking if these can be confused, the answer is no, zone authority goes to the delegation not to the sister owner names in the parent. > Eric, you are obviously a smart guy, and it wouldn't surprise me if > you could solve all these issues, but I think the multi-profile model > is too complex and too subtle to be worth its modest benefits. Thanks for the compliment, but these aren't problems that need to be solved. They are all handled through existing DNS rules (including the no-variations rule, which is also stated in STD13 but for a different scope naturally). > Whenever you try to use one data type to represent another data type, > you might get lucky and find that it's trivial, or there might be a > mismatch and you might have to do more complex mapping/encoding. That's > just the way it goes. The concern is to make the storage, transfer and comparison rules consistent. That is still there. The only parts that are different are at the applications which generate and interpret the octet-streams they get as a result of the storage, transfer and comparison pass-thru rules. There is zero additional complexity introduced in this part of the model. All of the functions remain and still have to be executed by the same agents, the only difference is that this model allows a larger number of agents to play in the octet-stream pool. > traversing. IDNA is not a generic internationalization protocol; it > applies only to domain names. IDNA is not an extension of DNS; it is > not specific to any particular protocol. It is an extension to DNS in multiple regards, not the least of which is that it implicitly and explicitly dictates the format of every future resource record which can ever be invented. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 19:53:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16924 for ; Tue, 11 Jun 2002 19:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HvGm-00061o-00 for idn-data@psg.com; Tue, 11 Jun 2002 16:41:48 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HvGd-00061Q-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 16:41:40 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HvGd-00029Y-00 for ; Tue, 11 Jun 2002 16:41:39 -0700 Date: Tue, 11 Jun 2002 23:41:39 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] IDNA applicability: per RR/Class or DNS-wide Message-ID: <20020611234138.GG6147@nicemice.net> Reply-To: IETF idn working group References: <53855516.1023791895@localhost> <20020611220032.GD6147@nicemice.net> <3D0677DC.7050705@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D0677DC.7050705@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > > If we allow multiple profiles, that's the same as allowing different > > comparison rules for different labels. > > The question formation differs, comparison is identical. We're just using different terminology. When I say "comparison", I'm refering to everything involved in the comparison, including the preparation, even if it's done at a different time. Consider this scenario: One user types a domain label containing an uppercase letter O-umlaut, another user types a domain label containing a lowercase letter o followed by a combining umlaut. Do these two labels match? Yes, no, or "well maybe, it depends"? For ASCII domain names, the answer has never been (and never will be) "maybe", there is always a yes or no answer that is apparent to anyone, without any additional information. That simple model underlies everything that has been built on top of domain names. I think trying to work out the implications of throwing "maybe" into the mix is more trouble than it's worth. AMC From owner-idn@ops.ietf.org Tue Jun 11 20:26:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17616 for ; Tue, 11 Jun 2002 20:26:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hvrq-0007RF-00 for idn-data@psg.com; Tue, 11 Jun 2002 17:20:06 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Hvrk-0007Ps-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 17:20:00 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141072 for idn@ops.ietf.org; Tue, 11 Jun 2002 19:17:58 -0500 Message-ID: <3D0693AD.10105@ehsco.com> Date: Tue, 11 Jun 2002 19:19:57 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] IDNA applicability: per RR/Class or DNS-wide References: <53855516.1023791895@localhost> <20020611220032.GD6147@nicemice.net> <3D0677DC.7050705@ehsco.com> <20020611234138.GG6147@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/11/2002 6:41 PM Adam M. Costello said the following: > "Eric A. Hall" wrote: >>The question formation differs, comparison is identical. > > We're just using different terminology. You're arguments have made it quite clear that you think this change affects server behavior in some way, when it does not. > Consider this scenario: One user types a domain label containing an > uppercase letter O-umlaut, another user types a domain label containing > a lowercase letter o followed by a combining umlaut. Do these two > labels match? How they are stored is all that matters. If they are stored as typed then they will be represented by different octet sequences and will therefore match as different sequences. If they are normalized to the same sequence as part of a stringprep profile before they are stored then they can only be represented by the resulting octet sequence. > I think trying to work out the implications of throwing "maybe" into > the mix is more trouble than it's worth. There is no "maybe" here either. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jun 11 20:51:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18223 for ; Tue, 11 Jun 2002 20:51:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HwCQ-0008DC-00 for idn-data@psg.com; Tue, 11 Jun 2002 17:41:22 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17HwCK-0008Cz-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 17:41:16 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17HwCK-000LYO-00; Wed, 12 Jun 2002 00:41:16 +0000 Date: Tue, 11 Jun 2002 20:41:15 -0400 From: John C Klensin To: IETF idn working group , "Paul Hoffman / IMC" cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <90041264.1023828075@localhost> In-Reply-To: <20020611230407.GE6147@nicemice.net> References: <20020611230407.GE6147@nicemice.net> 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=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 11 June, 2002 23:04 +0000 "Adam M. Costello" wrote: > John C Klensin wrote: > >> (i) The specification now appears to say that applications can >> decide to use IDNA or not. Presumably, they can decide to use >> something else instead. > > Paul Hoffman / IMC replied: > >> If either sentence is at all true, we need to fix it. I >> don't see any place that says that an application doesn't >> need to use IDNA for non-LDH domain names. > > You're both right. John must be referring to this sentence in > section 1: > > This document does not require any applications to conform > to IDNA, but applications can elect to use IDNA in order > to support IDN while maintaining interoperability with > existing infrastructure. yes > So applications can indeed decide not to use IDNA, in which > case they can't use non-ASCII characters in domain names. If > you want to use non-ASCII characters in domain names, IDNA is > your only option. IMO, that needs to be said, and said right there and very, very, explicitly. >> And I certainly don't see anything that would indicate that >> the second sentence is true. > > Agreed. We can't stop applications from using custom mappings > from non-ASCII text onto domain names, but the rest of the > world would never see the non-ASCII characters. The rest of > the world would simply see RFC 1035 domain names, which > contain only ASCII characters (and possibly octets 80..FF, > which are not defined to represent any characters at all). But we can say, clearly, that any such applications or activities are non-conforming to IETF standards. And I believe we should do so. > John wrote: > >> It is also not clear whether "an application", as used in the >> spec, refers to a standard protocol and expectations about how >> all conforming implementations will behave or to particular >> implementations and implementation choices. > > Both, I think. An individual application can unilaterally > decide to support IDNA, and a spec can opt to require IDNA > support. Ok. I think it should be more clear. And I need to think through the cases on this. >> But, if an application does a DNS lookup for an LDH name >> (with no prefix) with, say, an MX Qtype, and some of the >> result data are returned with IDNA-appearing prefixes, then >> the application needs additional clues as to how to present >> error messages to the user, how to continue processing in >> other areas, etc. > > I don't see why. If the application conforms to IDNA, it will > work. If it ignores IDNA and treats the name like any other > traditional ASCII name, it will work. True as long as it doesn't support a prefix-based interpretation, or a different prefix, with a different interpretation than IDNA. I took the text to imply that you were willing to tolerate such things. If you don't intend to, the text has to both make clear that they are non-conforming and, preferably, to damn them roundly and explain why. >> (ii) The specification seems inconsistent about what it about >> and who needs to understand it. It implies in several places >> that it is not about the DNS and has no impact on the DNS. > > Paul replied: > >> I can't find any place that makes it not about the DNS. > > Perhaps John is referring to this: > > IDNA does not require any changes to DNS servers, > resolvers, or protocol elements For starters, yes. I'll try to go back and find the rest of the text that set me off. Or have a look at some of Dave's "not related to the DNS, just 'micro layer'" comments of the last few days. > John wrote: > >> But it then makes and imposes normative DNS operational >> statements. E.g., "Non-ACE labels that begin with the ACE >> prefix will confuse users and SHOULD NOT be allowed in DNS >> zones" is certainly a requirement about DNS and DNS zone >> population. > > You are quite right. When we wrote "IDNA does not require any > changes to DNS servers", the word "require" was intended in > the sense of "depend on". I have already suggested changing > it to "depend on" (here and in similar places in the spec). That would be _much_ better, IMO. > Although IDNA does impose this new recommendation on DNS > servers, it would still work if it didn't. > >> (iii) Despite the "applications can choose to do this, or not >> do it" language, section 6.4 effectively implies a >> requirement that any application that uses the DNS be >> upgraded. > > Paul replied: > >> Every application of DNS should be upgraded for every >> extension or improvement of the DNS protocols. Nothing in >> 6.4 requires this, as far as I can see. > > I think John must be referring to this: > > All applications that might show the user a domain name > obtained from a domain name slot, such as from > gethostbyaddr or part of a mail header, SHOULD be updated > as soon as possible in order to prevent users from seeing > the ACE. yes > "SHOULD" is fairly strong, perhaps strong enough that this > paragraph might be considered inconsistent with this one: > > This document does not require any applications to conform > to IDNA, but applications can elect to use IDNA in order > to support IDN while maintaining interoperability with > existing infrastructure. yes > Maybe it would be less contentious if 6.4 merely stated the > benefits of upgrading applications, leaving the reader > conclude that doing so is a good idea. Personally, I would actually prefer that this whole IDN package come with a plan about how we are going to deprecate the non-conforming. The trick we tried to use with ESMTP was to invent the notion of a "contemporary implementation" and then talk about what "contemporary" (or "modern", or...) did and how they behaved. "Legacy" (or "older", or ...) implementations could still be said to conform to the old standards, but the strong implication was that they were not up-to-date if they weren't prepared to deal with the new stuff. I think something like that might help here although, regardless of my other points and issues, this whole situation feels more and more as if we ought to try to get an AS out that addresses relationships among protocols, expectations, and quality of implementation issues. I wouldn't mind just stuffing all of that into IDNA, but it probably isn't the right thing to do (or fair to you guys). >> (iv) Section 7 imposes several normative requirements on name >> servers and zone populations. Again, these requirements are >> buried in a document that elsewhere appears to claim that it >> doesn't impact the DNS. > > First requirement: > > Internationalized domain name data in zone files (as > specified by section 5 of RFC 1035) MUST be processed with > ToASCII before it is entered in the zone files. > > This follows directly from section 3 requirement 2. It is not > a special requirement on DNS, it is a general requirement on > any application that elects to use IDNs. Section 7 is simply > telling how it applies to DNS. It's still true that IDNA is > optional; if you don't want to support it, then don't, but > then you have no way to enter non-ASCII names into zones. This is, to put it mildly, not clear. Or not clear enough. At least to someone who hasn't been immersed in the document. > Second requirement: > > a primary master name server MUST NOT contain an > ACE-encoded label that decodes to an ASCII label. > > This is a vacuous requirement. There is no such thing as an > ACE label that decodes to an ASCII label, because of the > design of the ToASCII operation. Therefore, this is not > really requiring anything. I think I once asked for it's > removal, but since it's harmless, I didn't press it. Recommendation: Leave it there, since it is harmless and may be helpful to someone. But rephrase it, not as a "MUST" (or any other form of requirement), but as an observation. E.g., "note that, since the design of the ToASCII operation prevents any ACE label from decoding to an ASCII label (i.e., one without any non-ASCII characters), a primary master name server will never...". Or something like that. > Third requirement: > >> The third paragraph of section 7 seems to contradict or >> repeal the statements of RFC 2181 that non-ASCII strings are >> permitted in labels > > Good catch. We'll have to do something about that. Yes. Or Randy and kre will kill you. :-) >> (v) In particular, several of the statements in the draft go >> beyond almost anything we have about the DNS in trying to >> narrowly constrain the behavior of RR labels and data that >> are not yet defined, even in Classes that are not yet defined. > > You found one such statement, please feel free (and > encouraged) to enumerate the others. :) I'll go back and look. I think other comments above identify places where I simply reached different conclusions about what you meant than you intended. I think those things are worth clarifying -- others won't read the thing even as carefully as I have, must less be as familiar with it as you are. But I'd still prefer to see either enumerations of where IDNA can be used, or some much more clear language about its applicability. That gets back to the "applications" issue and the very broad "all labels" and its implications. See below. >> IDNA, by specifying nameprep profiling as part of the >> procedure, violates this principle by effectively requiring a >> one-off protocol for situations in which nameprep is >> inappropriate but other IDNA steps would be reasonable. > > Currently, all domain labels are compared the same way. This is exactly where I get hung up. Leaving the more subtle issue that Eric is trying to explore and some of its close relatives aside for the moment, let's assume that it is rational to apply IDNA to all domain labels and associated parameters are all _current_ RRs. That may be completely reasonable. But suppose that, at some point, and just as an example, some proposal goes forward to use a different Class for some purpose, or to use the DNS for a different purpose entirely. Such transitions involve exactly the sorts of infrastructure pain and suffering that IDNA was designed to avoid, but it is legitimate for the community to conclude that they are necessary. If we do decide to accept that pain and suffering, then it would be good, IMO, to be able to use it as an opportunity to clean out, as much as possible, things that were done only to preserve compatibility. I'd like to give those future designers the opportunity to make choices about whether to use IDNA (or ACE generally) to handle internationalization, the ability to think through whether more of the normalization or matching processes should be moved to the server, rather than being handled exclusively in the client, etc. I don't want (or need) to predict what they will conclude, but I think it is unnecessary and dangerous for us, at this stage, to write what seems to be an "all internationalization uses IDNA, now and forever, including in RRs and Classes and uses of the DNS we have no way to anticipate" rule. So I think we all need to understand the points Eric is trying to make. But, even if they are totally irrelevant or we conclude that they aren't worth the trouble, I believe that we should confine IDNA application and interpretation to what we can reasonable claim we know about today and that we should _explicitly_ leave future use and applicability for decisions to be made in the future. > Allowing multiple profiles amounts to allowing multiple > comparison functions. Eric Hall disputes this, but if you > stumble across two labels, one containing uppercase Latin > letter O with umlaut, the other containing lowercase latin > letter o followed by combining umlaut, and you wonder whether > they match, what is the answer? Yes, no, or maybe? For ASCII > domain names, there is no maybe. We deliberately designed > IDNA so that the same is true for IDNs. Understood, but not the point. What follows is going to be long, and I apologize, but we have proof that this isn't easy to explain. I strongly suspect that the problems/ issues that are driving Eric are different from mine, so please don't take this as representing (or preempting) his concerns and cases. At the risk of exposing another philosophical problem, let me repeat (or paraphrase) what I said in Minneapolis: for me, the essence of a good engineering job is to understand _all_ of the constraints that define the solution space for a problem and then either find a solution that fits within that solution space or be very clear to identify solutions that may not quite fit and it issues that make up the tradeoffs. Conversely, I consider that saying "we will define the problem very narrowly so that we can solve it and then leave the mess that creates for the rest of the world to work out" is lousy engineering and worst standardization practice. Now, that is just my opinion, but it is the foundation for an explanation, so bear with me. My guess is that the whole notion of "the registries will have to figure this out" is going to fail miserably. I don't think that is a valid argument for not publishing IDNA (or any of the rest of these IDN WG things) -- I am speculating, and this is the reason we have proposed standards and multiple maturity levels. But, to the extent to which LDH has advantages, those advantages have "worked" because they have been enforced by code in applications, not just by registries. If we say "open season, anything can go in, but some names aren't going to resolve because the registries will prohibit them" we end up in a much weaker state. We also end up with increased load on servers and, unless the state of negative caching improves a lot, probably disproportionately more load on the root. So, I contend there are big advantages to being able to sanity-check names before going off to the DNS and that the advantages get larger in the very complex world in which nearly-arbitrary Unicode strings are permitted as names. Now, suppose someone comes along and invents a new RR type. And, in addition to learning from our trying to over-rely on registres, the nature of that RR type is that, while some internationalization is appropriate for its labels, performance --for both successful and unsuccessful queries-- is a really critical issue, even relative to DNS norms. And let's suppose that, after appropriate analysis, the conclusion is that the characters that should be permitted in labels for that RR type should be slightly more than the 63 (or 64) of LDH, but many fewer than "most of Unicode"... say a few hundreds or, at most, a few thousand, of select characters. And, whatever characters are chosen, they are unambiguous, for both technical and user-perception definitions of ambiguity. Now, to accomplish that goal (please let's not get started on whether it is reasonable or not -- this is both future and hypothetical and I don't know what would cause such an RR to be created), the best path, given our current framework, would be to modify stringprep to add a table of the characters permitted by that RR. _Then_ the right thing to do is to create a profile that uses that table instead of some of the maps and prohibitions of nameprep. I am suggesting that (i) it should still be possible to use IDNA, but with a different profile and (ii) we should not, as a side effect of the way we specify IDNA today, prevent that RR from being defined, regardless of whether it can use IDNA+different profile or whether it needs to use an entirely different protocol to set up, compare, and map names. john From owner-idn@ops.ietf.org Tue Jun 11 23:22:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21772 for ; Tue, 11 Jun 2002 23:22:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HyYv-000DQL-00 for idn-data@psg.com; Tue, 11 Jun 2002 20:12:45 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17HyYl-000DQ5-00 for idn@ops.ietf.org; Tue, 11 Jun 2002 20:12:35 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17HyYk-0002aX-00 for ; Tue, 11 Jun 2002 20:12:34 -0700 Date: Wed, 12 Jun 2002 03:12:34 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? Message-ID: <20020612031233.GA8925@nicemice.net> Reply-To: IETF idn working group References: <20020611230407.GE6147@nicemice.net> <90041264.1023828075@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90041264.1023828075@localhost> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,TO_BE_REMOVED_REPLY,NO_OBLIGATION,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Doh, I got bitten by my own Reply-To header, and accidentally advised John to send his reply to the mailing list (which he did), even though my message (which he was replying to) did not go to the list. Paul is surely laughing at me now. :) Sorry for the extra list traffic. Anyone who wants to move this thread back off the list should override the Reply-To field. [For anyone who's curious, I composed a single reply to two messages, one from the mailing list, and another (a response to that one) from off the list. Since the mailing list address initially appeared in the recipient list, the Reply-To field was auto-generated. When I manually removed the mailing list from the recipient list, I forgot to remove the Reply-To.] I wrote: > So applications can indeed decide not to use IDNA, in which case they > can't use non-ASCII characters in domain names. If you want to use > non-ASCII characters in domain names, IDNA is your only option. To clarify for the list readers: Applications have always been able to use 8-bit names, and still can, and IDNA will not change that. Applications might have their own private interpretation of bytes 80..FF as characters, but there is no standard interpretation of those bytes as characters; the only characters that can currently be used unambiguously in domain names are the ASCII characters. If IDNA (as currently written) is adopted, it will be the standard definition of internationalized domain names. The only way to use non-ASCII characters in domain names in a standard unambiguous way will be to observe the rules of IDNA (which do allow for non-ASCII representation in new protocols). I wrote: > We can't stop applications from using custom mappings from non-ASCII > text onto domain names, but the rest of the world would never see the > non-ASCII characters. The rest of the world would simply see RFC 1035 > domain names, which contain only ASCII characters (and possibly octets > 80..FF, which are not defined to represent any characters at all). John C Klensin responded: > But we can say, clearly, that any such applications or activities are > non-conforming to IETF standards. And I believe we should do so. I don't think they are non-conforming. Consider this analogous situation: For some reason I want to map geographic locations onto domain labels. There is no standard for using domain labels to represent geographic locations, but I make one up, for example n037d37m05s-w122d23m14s. No one else will understand that this is a geographic location, to them it's just a domain label, but it's a conformant domain label, and it doesn't hurt anyone. Now suppose my data type is something that contains non-ASCII characters, but it would get hopeless damaged by Nameprep, so I cannot use IDNA. Just as in the previous case, I can make up my own mapping and use it without bothering anyone else, they just won't understand it. I wrote: > It's still true that IDNA is optional; if you don't want to support > it, then don't, but then you have no way to enter non-ASCII names into > zones. As before, I meant "no standard unambiguous way". I wrote: > a primary master name server MUST NOT contain an ACE-encoded label > that decodes to an ASCII label. > > This is a vacuous requirement. There is no such thing as an ACE label > that decodes to an ASCII label, because of the design of the ToASCII > operation. Therefore, this is not really requiring anything. I think > I once asked for it's removal, but since it's harmless, I didn't press > it. John responded: > Recommendation: Leave it there, since it is harmless and may be > helpful to someone. But rephrase it, not as a "MUST" (or any other > form of requirement), but as an observation. E.g., "note that, > since the design of the ToASCII operation prevents any ACE label > from decoding to an ASCII label (i.e., one without any non-ASCII > characters), a primary master name server will never...". Or > something like that. I like that. Now that I think about it, I should have said "because of the design of ToASCII and ToUnicode", not just ToASCII. > But I'd still prefer to see either enumerations of where IDNA can be > used, or some much more clear language about its applicability. First sentence of section 1.1: Applications can use IDNA to support internationalized domain names anywhere that ASCII domain names are already supported > I believe that we should confine IDNA application and interpretation > to what we can reasonable claim we know about today and that we should > _explicitly_ leave future use and applicability for decisions to be > made in the future. I suppose future specs that define new places for domain names to appear could explicitly say "IDNA shall not apply to domain names appearing in these places". In the absence of such a statement, the first sentence of section 1.1 remains as a simple fact. > Now, suppose someone comes along and invents a new RR type. ...the > characters that should be permitted in labels for that RR type > should be... a few hundreds or, at most, a few thousand, of select > characters. > > Now, to accomplish that goal... the best path, given our current > framework, would be to modify stringprep to add a table of the > characters permitted by that RR. _Then_ the right thing to do is to > create a profile that uses that table instead of some of the maps and > prohibitions of nameprep. The specification does not require any particular implementation, it just defines the right answer. IDNA requires applications to convert non-ASCII labels to equivalent ASCII labels in certain situations, and "equivalent" is defined in terms of ToASCII, which is defined in terms of Nameprep. Applications are not prevented from imposing additional restrictions on labels. IDNA says that anything that doesn't survive ToASCII is not allowed, but it doesn't say that anything that does survive ToASCII must be allowed. The application is under no obligation to implement ToASCII exactly as it is shown in the spec, as long as it computes the right answer. If instead of performing Nameprep and then checking some additional restrictions, the application can use another Stringprep profile that always returns the same result as Nameprep-plus-additional-restrictions, it is welcome to do that. That would just be an optimization. AMC From owner-idn@ops.ietf.org Wed Jun 12 20:53:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18061 for ; Wed, 12 Jun 2002 20:52:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IITN-000GZG-00 for idn-data@psg.com; Wed, 12 Jun 2002 17:28:21 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17IITD-000GYj-00 for idn@ops.ietf.org; Wed, 12 Jun 2002 17:28:11 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17IITC-0004v9-00 for ; Wed, 12 Jun 2002 17:28:10 -0700 Date: Thu, 13 Jun 2002 00:28:10 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: [idn] One profile for domain names, or many? Message-ID: <20020613002810.GC17395@nicemice.net> Reply-To: IETF idn working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=1.8 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,PORN_10,NO_MX_FOR_FROM version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Let me try to sum up the issues in the ongoing debate over whether there should be a single standard Stringprep profile for all IDNs, or whether different profiles should be allowed for different contexts (like different DNS resource record types). [By the way, I think concerns that IDNA's definition of IDNs might be overly restrictive and might cause problems in the future is very much on-topic for this working group, and such concerns should be aired. I thank Eric for raising this issue and working hard to make us understand his side of it.] I'll start by recapping the two models. In the single-profile model (which is used by the IDNA draft), there is one standard profile (Nameprep) that is used for all comparisons between textual domain labels, and for all conversions of textual domain labels between their ASCII and non-ASCII forms. A textual domain label is one composed of specific well-defined characters, not an arbitrary sequence of bytes. The profile is intimately involved in the definitions of which labels are equivalent and which labels are valid. Additional restrictions can be imposed (some valid labels might still be disallowed for particular purposes). IDNA would govern all comparisons between textual domain labels, and all conversions of textual domain labels between ACSII and non-ASCII form, but it would have nothing to say about conversions between domain labels and other data types; those conversions are out of scope of IDNA, and would need to be defined by whatever specs define those other data types. The 8-bit labels contemplated by RFC 1035 would also be out of scope of IDNA, because there is no standard interpretation of the bytes 80..FF as characters. In the many-profile model (as I understand it), domain names are really sequences of bytes, and their interpretation as characters is merely a view created by applications for the benefit of human users. All comparisons are really exact comparisons except for ASCII letters; the illusion of case insensitivity for non-ASCII letters is created by applications applying case folding when they convert user-entered text into domain-names-which-are-byte-sequences. Different text-to-byte conversions, defined by different Stringprep profiles, can be applied in different contexts, and this will appear to users as different kinds of sensitivities. I think the single-profile model is inspired by the existing model of ASCII domain names as they appear to users. I think the many-profile model is inspired by the existing model of 8-bit domain names as they appear to DNS implementors. I've had my doubts about whether the many-profile model could really work, but Eric is confident that it would, and my doubts have lessened somewhat. I have no doubt that the single-profile model would work, and I don't remember anyone claiming that it wouldn't; Eric has argued that it would make some things less convenient or less efficient. Let's assume for the sake of argument that both models work, and we just have to decide which one we prefer. Now let's examine an implication of the many-profile model, using a concrete example scenario (please bear with me, the punchline will be interesting). Suppose there is an XXX resource record type, which uses xxxprep for the first label of its owner name, and there is a YYY resource record type, which uses yyyprep for the first label of its owner name. One registrant asks the administrator of a zone to create an XXX record with owner label x, and another registrant asks for a YYY record with owner label y, in the same zone. Now let's plug in the details: x = fullwidth Latin small letter a y = Latin capital letter A xxxprep = case-fold, then apply NFC yyyprep = apply NFKC, then prohibit all lowercase letters What does the zone administrator do? First, verify that the labels are properly prepared: x == xxxprep(x) ? Yes. y == yyyprep(y) ? Yes. Next, check for any collisions: xxxprep(x) == x == fullwidth Latin small letter a yyyprep(y) == y == Latin capital letter A xxxprep(y) == Latin small letter a yyyprep(x) == error That's all combinations, and they yield all different answers, so there are no collisions here in the prepared space where DNS servers live. The two domains are created for the two registrants. What we failed to detect, and what in general could be extremely difficult to detect (because Stringprep is not reversible), is the existence of a collision in the unprepared space where users live and think and type. Consider: z = fullwidth Latin capital letter A A user could use this same string z to refer to both of these domains. If the user asks for an XXX record, z will match one domain; if the user asks for a YYY record, the very same string z will match the other domain. In other words, from the point of view of users, there is not a single domain name space in which all domain names live, there are multiple domain name spaces (one corresponding to each profile), and the same name can refer to different domains in different spaces. This is unlike ASCII domain names, which all occupy a single name space. An ASCII name always refers to the same domain regardless of the context in which it is typed. The single-profile model retains this single name space characteristic, while the many-profile model introduces a new concept of multiple name spaces. In this sense, the many-profile model is a more radical departure from the existing ASCII domain name model, while the single-profile model is more conservative. (By the way, it's not at all clear to me what should happen if the user asks for ANY records matching z.) A simple/conservative approach has both advantages and disadvantages compared to a more complex/flexible approach. Let's look at a couple of those. Suppose an application has some non-domain-label data type that it wants to map onto domain labels. It would be convenient if the trivial mapping could be used (that is, do nothing, just call the thing a domain label). This is easier in the many-profile model, because the application can define a Stringprep profile well suited to its data type. In the single-profile model, the trivial mapping works only if the original data can tolerate being nameprepped. If it can't, the application will have to use a non-trivial mapping from its data type to domain labels. IDNA is no help there (remember that IDNA applies only to conversions of domain labels between their ASCII and non-ASCII forms, not to conversions between domain labels and other data types), so the application will always have to do the conversion at both ends; it cannot benefit from any automatic IDNA conversions built into the infrastructure (like a new resolver interface). So that's an example of something that's more difficult (but not impossible) in the single-profile model. Now suppose an application simply wants to start using IDNA to allow users to enter and see non-ASCII characters. In the many-profile model, you cannot put a user-entered name into a domain name slot unless you know the profile to be used for that slot. Eric has been talking about resource record types, but DNS is not the only protocol with domain name slots; we also need to assign profiles to domain name slots in other protocols, and until we do, IDNs cannot be used in those slots. For example, before an email application can add IDN support, it needs to wait for profiles to be assigned to header fields, SMTP commands, POP commands, and IMAP commands. Before a web browser can add IDN support, it needs to wait for profiles to be assigned to the various URL schemes, cookies, and SSL certificates. With the single-profile model, there is no question of which profile to use, so applications can add IDN support the day after IDNA is published. So that's an example of something that's less convenient (but not impossible) in the many-profile model. In conclusion, there may very well be more than one right way to define IDNs, with tradeoffs among the options. Based on my current understanding of the issues (which I think is better now than ever), I would still choose the single-profile model. I can understand that other people might choose differently. AMC From owner-idn@ops.ietf.org Thu Jun 13 00:10:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21722 for ; Thu, 13 Jun 2002 00:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ILkh-000K2H-00 for idn-data@psg.com; Wed, 12 Jun 2002 20:58:27 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17ILkc-000K26-00 for idn@ops.ietf.org; Wed, 12 Jun 2002 20:58:22 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141435 for idn@ops.ietf.org; Wed, 12 Jun 2002 22:56:21 -0500 Message-ID: <3D08185B.5080002@ehsco.com> Date: Wed, 12 Jun 2002 22:58:19 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,PORN_10 version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/12/2002 7:28 PM Adam M. Costello wrote: > In the many-profile model (as I understand it), domain names are really > sequences of bytes, and their interpretation as characters is merely > a view created by applications for the benefit of human users. All > comparisons are really exact comparisons except for ASCII letters; the > illusion of case insensitivity for non-ASCII letters is created by > applications applying case folding when they convert user-entered text > into domain-names-which-are-byte-sequences. You are correct. The ASCII part is confusing but you are correct in that if an application wants to provide case-mapping it will have to do so in the profile. There is no lowercase storage in the i18n namespace so the codes must match precisely. This is a direct result of AMC-Z encoding. One clarification is that it isn't expectated that other profiles will be used for human input, although it's not a negative expectation either. The principle intention is to facilitate the storage of application-specific domain names, that is all. Although I've typed network names into NetBIOS applications, I've never actually typed a NetBIOS name (including all of the markers and codes). I've typed SRV owner names into dig for debugging purposes, but never for user purposes. I've certainly never typed the domain names needed to tunnel IP through DNS messages [1]. And so forth. The principle intention is to allow applications to make use of the domain names they need to function in the namespace, and that these names probably won't be entered by users directly. Human input must certainly be considered, but its not the primary expectation. Moreover, these examples work with the existing STD13 octets. In that regard, the intention is to facilitate the migration of STD13 octets. This is especially important if that usage is going to be prohibited. > Next, check for any collisions: > > xxxprep(x) == x == fullwidth Latin small letter a > yyyprep(y) == y == Latin capital letter A > xxxprep(y) == Latin small letter a > yyyprep(x) == error and then nameprep for feelgood purposes, as stated three times now. But let's assume they didn't. > z = fullwidth Latin capital letter A > > A user could use this same string z to refer to both of these domains. > If the user asks for an XXX record, z will match one domain; if the > user asks for a YYY record, the very same string z will match the other > domain. Queries contain three elements: qname, qtype and qclass. If all three match then the query succeeds. If any of them don't match, then the query will fail. If the applications (not the user) issue these queries as you have described them then they will ask for: qname=FF21 qtype=XXX qclass=IN and qname=FF21 qtype=YYY qclass=IN Does an owner name exist at FF21? Does it have the queried RRtype? Does it have the queried class? Although I'm more than happy to have duplicates omitted, you can see from the above why it isn't necessary. The domain name octets have to match AND there has to be a RRtype as well. If the name is wrong (either in the query or in the zone) then the names which do match probably don't have the right RR. If the RR matches then they got what they asked for. If they got something that they didn't want but some other similar name which also happens to have the RR bound to it then the profile is flacid and the developer needs to be shot for writing a profile that allows these errors. > (By the way, it's not at all clear to me what should happen if the user > asks for ANY records matching z.) They MUST get all of the matches that fit in the message. Note that it is specifically qtype ALL (not ANY). This may appear semantic but its not. Also note the opposite for qclass ANY (not ALL). What the application does with those two RRs is up to the application. Sendmail uses qtype=* to find all of the RRs associated with a mail domain. What does it do with the RP and TXT RRs that it gets (hint: what do those RRs have to do with routing mail?). Really, this is making mountains from molehills. DNS already works this way today, and the planet has yet to fall off its axis. > In conclusion, there may very well be more than one right way to > define IDNs, with tradeoffs among the options. Based on my current > understanding of the issues (which I think is better now than ever), > I would still choose the single-profile model. I can understand that > other people might choose differently. Where will the existing users of eight-bit domain names go if: 1) they can't stay in STD13 because it has been prohibited 2) the profile-centric i18n namespace forbids the applications from defining their own profiles? I got news, one of those two changes will be ignored. Standards are measured by their use, not their intent. [1] http://slashdot.org/article.pl?sid=00/09/10/2230242&mode=thread&tid=95 -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 02:03:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27623 for ; Thu, 13 Jun 2002 02:03:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17INTz-000Luv-00 for idn-data@psg.com; Wed, 12 Jun 2002 22:49:19 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17INTn-000Lug-00 for idn@ops.ietf.org; Wed, 12 Jun 2002 22:49:08 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17INTm-0005h5-00 for ; Wed, 12 Jun 2002 22:49:06 -0700 Date: Thu, 13 Jun 2002 05:49:06 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <20020613054905.GC20196@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D08185B.5080002@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > One clarification is that it isn't expectated that other profiles > will be used for human input... The principle intention is to allow > applications to make use of the domain names they need to function in > the namespace, and that these names probably won't be entered by users > directly. > > Moreover, these examples work with the existing STD13 octets. In that > regard, the intention is to facilitate the migration of STD13 octets. > This is especially important if that usage is going to be prohibited. That's very interesting. Maybe there's a middle ground here. Suppose the IETF were to issue a clarification of the DNS spec stating in no uncertain terms that bytes 80..FF in domain names must match exactly, and that there is no standard interpretation of those bytes as characters (not for any existing DNS services anyway). Then I wouldn't object if applications that don't like Nameprep were encouraged to use 8-bit names in DNS for non-human-oriented purposes. IDNA with its single profile would govern the universe of textual domain labels (labels composed entirely of well-defined characters, not just opaque bytes). These labels are intended for human users and are used in a wide variety of protocols, not just DNS. Applications that want to use human-accessible domain names containing non-ASCII characters in a standard representation would use IDNA (they would have nowhere else to turn). Outside the universe of textual domain labels are the STD-13 domain labels that contain at least one byte in the range 80..FF. I call such labels non-textual because there is no standard interpretation of 80..FF as characters (although applications can locally map them to characters, at their own risk). These labels are specifically DNS-things (I've never heard of them being used in other protocols). These labels are already outside the scope of IDNA, because IDNA can only cope with well-defined textual labels. Applications that don't like Nameprep and don't care whether their domain labels are easily accessible to humans can ignore IDNA and stick with STD-13 and their own local interpretation of the bytes, and prepare their labels in any way they like. Eric, would you be satisfied with that? What do other people think of that idea? Note that we can't stop applications from using 8-bit STD-13 domain names. The only question is under what circumstances we encourage or discourage it. > Where will the existing users of eight-bit domain names go if: > > 1) they can't stay in STD13 because it has been prohibited We are not going to try to overturn STD-13. Language in the IDNA spec that appeared to be doing that was a mistake, and will be fixed. AMC From owner-idn@ops.ietf.org Thu Jun 13 04:24:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04594 for ; Thu, 13 Jun 2002 04:24:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IPjU-000ODQ-00 for idn-data@psg.com; Thu, 13 Jun 2002 01:13:28 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IPjQ-000ODF-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 01:13:24 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141451 for idn@ops.ietf.org; Thu, 13 Jun 2002 03:11:23 -0500 Message-ID: <3D085422.1060608@ehsco.com> Date: Thu, 13 Jun 2002 03:13:22 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/13/2002 12:49 AM Adam M. Costello wrote: > Suppose the IETF were to issue a clarification of the DNS spec stating > in no uncertain terms that bytes 80..FF in domain names must match > exactly, and that there is no standard interpretation of those bytes as > characters (not for any existing DNS services anyway). Then I wouldn't > object if applications that don't like Nameprep were encouraged to use > 8-bit names in DNS for non-human-oriented purposes. > Eric, would you be satisfied with that? What do other people think of > that idea? I've given this some thought, and I think it's a creative approach. But I don't think it's the right approach, since it only ingrains some of the problems. I know you don't want to hear this but it would actually make much more sense to do the exact opposite, which is to prohibit eight-bit for the standard RRs (which is also what John was saying I think) and to embrace and encourage the use of multiple profiles in the i18n namespace. Profiles present a great opportunity to enforce strong and consistent data-typing with the different domain names. Part of the problem with the legacy domain names is that they are so malleable with different interpretations depending on the spec you read. Look at STD19, which was written to provide an encoding for NetBIOS names, but which MS no longer uses due (partly) to i18n issues. Meanwhile, they use RFC 2181 as justification for storing UTF-8 characters in A RRs. I'd much rather see DNSEXT prohibit eight-bit codes in A RRs and encourage MS to use the same A RRs as everybody else so that subsequent future uses of A RRs were consistent. But I'd ALSO encourage them to define a structured syntax for i18n NetBIOS names as well. Leaving the eight-bit codespace there just means they don't have to do either of those things, meaning that different networks will look for i18n A RRs in different ways and places. In short, encouraging the use of profiles for all domain names encourages strong data-typing across all applications which use all domain names, which benefits interoperability tremendously. This favortism towards strong data-typing also benefits applications which pass i18n domain names as in-band protocol data. Obviously, nameprep allows an i18n version of Finger (as an example) to know precisely what the rules are for the domain names that it exchanges, as would an i18n profile of mailbox names. Along the same lines, a profile for Kerberos also provides a way for participating applications to be able to create and verify those domain names when they need the protocol information, even if this data never goes into DNS. But if it does go into DNS they can use the profile there as well. draft-ietf-krb-wg-krb-dns-locate-02.txt described a way to provide DNS->Realm mappings using TXT RRdata to store the Kerberos realm name, but a profile would allow a kerberos-specific RR to be creeated for the same purpose and with greater efficiency and accuracy (note that Kerberos' use of uppercase for realm names prohibits nameprep). There is another reason for going this route, which is that the presence of eight-bit codes in the STD13 namespace makes managing UCS names in dual-mode servers extremely difficult. It essentially requires that servers flag eight-bit domain names as NOT UCS so that the names don't get looked at when an EDNS/deACE'd query comes in. Part of the original motivation for going to a profile centric world was to resolve this specific problem. I don't want it back in after all this. Anyway, those are my reasons for arguing that DNSEXT clarify the interpretation of RRs in the legacy namespace at the same time the new namespace is defined. Leaving those in there wouldn't really solve any of the problems we are trying to fix in the long run. I will post a discussion of the i18n namespace with multiple profiles tomorrow which will hopefully remove your remaining doubts about its viability. It is really fairly simple and straightforward, and it yields many benefits, some of which are outlined above. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 06:14:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06167 for ; Thu, 13 Jun 2002 06:14:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IRSy-000Ps4-00 for idn-data@psg.com; Thu, 13 Jun 2002 03:04:32 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17IRSt-000Prr-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 03:04:27 -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 DAA01835; Thu, 13 Jun 2002 03:03:55 -0700 (PDT) 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 g5DA3rK24785; Thu, 13 Jun 2002 12:03:53 +0200 (MEST) Date: Thu, 13 Jun 2002 12:02:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) To: John C Klensin Cc: IETF idn working group , Paul Hoffman / IMC , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: "Your message with ID" <90041264.1023828075@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk > I'd like to give those future designers the > opportunity to make choices about whether to use IDNA (or ACE > generally) to handle internationalization, the ability to think > through whether more of the normalization or matching processes > should be moved to the server, rather than being handled > exclusively in the client, etc. I don't want (or need) to > predict what they will conclude, but I think it is unnecessary > and dangerous for us, at this stage, to write what seems to be > an "all internationalization uses IDNA, now and forever, > including in RRs and Classes and uses of the DNS we have no way > to anticipate" rule. John, I'm trying to understand why, if e.g. the community goes down the path of doing a new class, why such a specification can't update the IDNA RFC to e.g. say that IDNA now only applies to class=IN (or whatever is approiate). That specification will need to also specify how QCLASS=ANY is handled, etc, etc. If we declare that IDNA needs to restrict itself (e.g. to class=IN) then it seems like we need to solve the QCLASS=ANY issue now. This seems suboptimal both because the work might be wasted (if a new class protocol isn't pursued) but worse, the solution might be broken since we have no way of predicting what the new class proposal might need with respect to QCLASS=ANY. I think there is a separate issue whether the rules for QNAME and RDATA domain name slots should be the same, or e.g. whether the RDATA slots in SOA, CNAME(?), etc should use different nameprep (e.g. to allow different case, or to allow any codepoints). I think that issue can be decided without having to be able to predict the future. > I am suggesting that (i) it should still be possible to use > IDNA, but with a different profile and (ii) we should not, as a > side effect of the way we specify IDNA today, prevent that RR > from being defined, regardless of whether it can use > IDNA+different profile or whether it needs to use an entirely > different protocol to set up, compare, and map names. I don't think there is anything that prevents this, but it might be a bit cumbersom. For instance, a new definition could say "apply ToAscii with step 2 replaced by foo" where "foo" is something different than nameprep. (And similarely for ToUnicode). As part of my review I explored if there could be a better separation between nameprep and the other parts of IDNA, but that seems to result in different handling of case for all-ASCII labels. If nameprep was separable from ToASCII it would need to be the first step. This would mean that all-ASCII labels would be case-folded, which they are not as ToASCII is specified. Hence an application using IDNA would potentially display different case for non-IDNs to users. Erik From owner-idn@ops.ietf.org Thu Jun 13 06:14:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06180 for ; Thu, 13 Jun 2002 06:14:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IRT7-000PsI-00 for idn-data@psg.com; Thu, 13 Jun 2002 03:04:41 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17IRT4-000Ps7-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 03:04:38 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13776; Thu, 13 Jun 2002 03:04:36 -0700 (PDT) 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 g5DA4ZK25113; Thu, 13 Jun 2002 12:04:35 +0200 (MEST) Date: Thu, 13 Jun 2002 12:03:20 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] One profile for domain names, or many? To: "Eric A. Hall" Cc: IETF idn working group In-Reply-To: "Your message with ID" <3D08185B.5080002@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,PORN_10 version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk > If the applications (not the user) issue these queries as you have > described them then they will ask for: > > qname=FF21 qtype=XXX qclass=IN > and > qname=FF21 qtype=YYY qclass=IN > > Does an owner name exist at FF21? > Does it have the queried RRtype? > Does it have the queried class? Eric, How does this work for non-terminal labels i.e. when there is a zone cut? I think DNS server just look at qname (and not qtype) to determine that they need to do a referral (or perform recursion). Having the interpretation of the owner name be type specific provides the opportunity (however misguided it might be) to try to delegate the two name/type pairs differently. As far as I can tell using different profiles for QNAME and RDATA domain name slots doesn't have this issue. And in the future there is the option to carefully define a new class that uses a different profile for QNAME. Erik From owner-idn@ops.ietf.org Thu Jun 13 09:42:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12010 for ; Thu, 13 Jun 2002 09:42:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IUgf-0003hL-00 for idn-data@psg.com; Thu, 13 Jun 2002 06:30:53 -0700 Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com) by psg.com with esmtp (Exim 3.36 #1) id 17IUgb-0003h8-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 06:30:49 -0700 Received: from [64.108.76.167] (adsl-64-108-76-167.dsl.lgnnmi.ameritech.net [64.108.76.167]) by www.wordnic.com (8.9.3/8.9.3) with ESMTP id IAA13432 for ; Thu, 13 Jun 2002 08:30:40 -0500 Mime-Version: 1.0 X-Sender: tedd1@sperling.com Message-Id: In-Reply-To: References: Date: Thu, 13 Jun 2002 09:30:43 -0400 To: idn working group From: tedd Subject: [idn] Comments??? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Hi: Any comments about what VeriSign is doing? tedd -- http://sperling.com From owner-idn@ops.ietf.org Thu Jun 13 11:14:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16942 for ; Thu, 13 Jun 2002 11:14:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IW2A-0005S2-00 for idn-data@psg.com; Thu, 13 Jun 2002 07:57:10 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17IW22-0005Rm-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 07:57:02 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17IW1y-0001qA-00; Thu, 13 Jun 2002 14:56:58 +0000 Date: Thu, 13 Jun 2002 10:56:58 -0400 From: John C Klensin To: Erik Nordmark cc: IETF idn working group , "Paul Hoffman / IMC" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <127445574.1023965818@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 13 June, 2002 12:02 +0200 Erik Nordmark wrote: >> I'd like to give those future designers the >> opportunity to make choices about whether to use IDNA (or ACE >> generally) to handle internationalization, the ability to >> think through whether more of the normalization or matching >> processes should be moved to the server, rather than being >> handled exclusively in the client, etc. I don't want (or >> need) to predict what they will conclude, but I think it is >> unnecessary and dangerous for us, at this stage, to write >> what seems to be an "all internationalization uses IDNA, now >> and forever, including in RRs and Classes and uses of the DNS >> we have no way to anticipate" rule. > > John, > > I'm trying to understand why, if e.g. the community goes down > the path of doing a new class, why such a specification can't > update the IDNA RFC to e.g. say that IDNA now only applies to > class=IN (or whatever is approiate). Because we have tried that approach, mostly inadvertently, many times before, and it has always gotten us into trouble. "You are not permitted to do this" leaves us in a position where we can later make it permissible and give it an interpretation at the same time. "It is undefined" seems to invariably create a community of people who are sure what "undefined" means --i.e., who assign a meaning to it-- and who then become a serious, installed-base, impediment to any other interpretation. And "this applies globally" will be taken as the basis for a claim that we are making a seriously incompatible change if we try to do something else in some other name space. Some examples, in the event that this still isn't clear: * RFC821 specified Internet email transport in terms of ASCII. It didn't explicitly (enough) prohibit sending non-ASCII ("8bit") characters. So, when the desire to send, e.g., ISO 8859-1 chacters, arose, a community sprung up that, since the specification left 8bit characters undefined, they were free to define them as 8859-1. Another community sprung up that said that, since they were undefined, they were prohibited, and zeroed the high-order bits (or rejected the messages) in MTAs. The combination led to the "just send 8" movement and huge problems in getting MIME, content character set tagging, and the SMTP extension model agreed to and deployed. The aftereffects of those problems persist to this day. * RFC 1034 and 1035 define labels in terms of ASCII characters, but contains more or less vague language about how labels containing octet values that cannot be ASCII are to be interpreted. That has touched off a debate within this WG (and I wouldn't expect the debate to be much different within namedroppers, but would encourage you to try that experiment) as to whether this means "octets above 0x7F are undefined and their use is prohibited until they are defined" or "octets above 0x7F are to be compared exactly, while _all_ octets of 0x7F and below are to be compared case-insensitively (assuming ASCII interpretation of those bytes). We have either got to be sure that we can predict the future, or we need to explicitly bar the cases we don't (and don't need to) understand. The other cases just lead to confusion and non-interoperability... and our track record for future-predicting is not good. * There is actually a substantive (in addition to philosophical) reason why I have been pushing back on the "you can use a binary label anywhere" interpretation of 1035 (as represented in 2181 and elsewhere). While I'm unhappy about treating characters from case-differentiating scripts differently depending on whether the octets of their codings happen to fall in the 0x00-0x7F or 0x8F-0xFF ranges for existing character-based RR types, it isn't my main concern. My concern is that this interpretation requires that all labels for all RRs, in all Classes, present and future, be treated as character strings using those rules. As just one example of this, suppose we come along later and want to put Unicode more directly into the DNS. We know that UTF-8 isn't a particularly efficient encoding -- its design is strongly influenced by the need to be compatible with octet-based systems. We also know that UCS-4 (UTF-32) isn't very efficient either. But we know a good deal about compression, and could do some elegant things about compressing a string written in Unicode characters. But, to do that, we need _binary_ labels (not just binary octets), i.e., a length-encoded bit string of up to 63 octets in length and with no variant interpretations based on whether the stored value of a given octet falls in the 0x00-0xFF range. That is pretty easy to do in the DNS structure, but it requires per-RR or per-Class definitions of how the label string is interpreted/ matched. If we read 1034/1035 as "it is all characters" then either this is hopeless or we will need to invent another kludge (fortunately, the obvious one is still more efficient than UTF-8). If we read 1034/1035 as "only the existing RRs and Classes are specfied, new ones get to specify their own rules" then the range of options remains open. There is even a question about today's installed base. Has anyone who is competent to do so taken a careful look about what the implications would be if IDNA were applied to Hesiod-Class data? I'm not very worried about chaosnet, but we usually try to avoid blowing away know installed applications without careful consideration. Now, one could argue that case would be covered by the language that says use of IDNA is an application-choice, but that would call for a piece of a security considerations section (or elsewhere) that explains issues an application should consider before deciding to use IDNA. And that section isn't present. It would also, I think, be hard to write and get right -- why look for trouble by making sweeping statements about where IDNA applies when they don't appear necessary. > That specification will > need to also specify how QCLASS=ANY is handled, etc, etc. Maybe. We have successfully dodged this issue with the three classes that are in use so far. And I would argue that we are more likely to be forced to define it if we make IDNA apply across everything than if we say "IDNA applies here, to cases we can list and enumerate, and applying it elsewhere requires specific action". > If we declare that IDNA needs to restrict itself (e.g. to > class=IN) then it seems like we need to solve the QCLASS=ANY > issue now. This seems suboptimal both because the work might > be wasted (if a new class protocol isn't pursued) but worse, > the solution might be broken since we have no way of > predicting what the new class proposal might need with respect > to QCLASS=ANY. See above. It is my belief that we need to address the QClass=ANY question only when a class comes along that requires it. We have gotten away without it for a long time. My own hunch is that it doesn't have a solution without imposing the "look everywhere in case someone has data" property of X.500 DSP on the DNS, which would be a really bad idea and that, instead, if someone really needs "look in this Class and then in that one" capability, they are going to have to invent, e.g., a "QTYPE=INorUC" arrangement and try to make it work. I wish them luck. Aside: at a procedural level, I think a persuasive argument can be made that the majority of the IDN WG participants don't understand the details of this discussion or why it is important, even after it is called to their attention. If that is true, a document that makes "applies everywhere" statements about DNS use is inappropriate to be treated as a product of this WG. > I think there is a separate issue whether the rules for QNAME > and RDATA domain name slots should be the same, or e.g. > whether the RDATA slots in SOA, CNAME(?), etc should use > different nameprep (e.g. to allow different case, or to allow > any codepoints). I think that issue can be decided without > having to be able to predict the future. Absolutely. My only concern is that it should be decided explicitly and not by either handwaving (which the current document appears to me to do) or the hope that the definitions will appear in some future document which we have no current plan to get written (which I think at least some of the authors might argue was the solution). If we can't decide, and can't get that document, then I believe that the uses need to be prohibited until we have clear definitions. Otherwise, people will make up their own answers while pointing to the IDNA standard, and we will have non-interoperability chaos. >> I am suggesting that (i) it should still be possible to use >> IDNA, but with a different profile and (ii) we should not, as >> a side effect of the way we specify IDNA today, prevent that >> RR from being defined, regardless of whether it can use >> IDNA+different profile or whether it needs to use an entirely >> different protocol to set up, compare, and map names. > > I don't think there is anything that prevents this, but it > might be a bit cumbersom. For instance, a new definition could > say "apply ToAscii with step 2 replaced by foo" where "foo" is > something different than nameprep. (And similarely for > ToUnicode). In practical terms, if anyone actually decides to do this in an implementation, the burden of demonstrating how to do it in a non-cumbersome way lies on them. I think Eric and I have described how to _define_ it fairly easily. I note that, from a definitional standpoint, the whole notion of Classes and RRs in the DNS ought to be a matter of tables but that the predominant implementations have ended up requiring code changes each time one is added and with a lot of that code being special-purpose. The implementer's life is hard sometimes. But, while I firmly believe in making it easy when possible, hardness (or cumbersomeness) shouldn't be a bar to our doing the right thing. And, again, where Eric and I _may_ differ is that, while I'd rather see this opened up if we can figure out how to do it (in the interest of modularity and increased likelihood of future interoperability), my bottom line is simply that we define IDNA as applying in areas that we have studied and understand that it applies reasonably, that we ban it elsewhere and leave those other cases for the future. > As part of my review I explored if there could be a better > separation between nameprep and the other parts of IDNA, but > that seems to result in different handling of case for > all-ASCII labels. > If nameprep was separable from ToASCII it would need to be the > first step. This would mean that all-ASCII labels would be > case-folded, which they are not as ToASCII is specified. Hence > an application using IDNA would potentially display different > case for non-IDNs to users. Or nameprep would have to special-case those characters and push them down a code branch it doesn't now have. I admit that isn't attractive, but... john From owner-idn@ops.ietf.org Thu Jun 13 11:19:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17225 for ; Thu, 13 Jun 2002 11:19:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IWGc-0005r0-00 for idn-data@psg.com; Thu, 13 Jun 2002 08:12:06 -0700 Received: from host-111.innovation.t1.primus.ca ([216.254.145.111] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17IWGZ-0005qe-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 08:12:03 -0700 Message-ID: <033101c212e2$93dba730$6601a8c0@neteka.inc> From: "Edmon Chung" To: "IETF idn working group" References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> Subject: [idn] Preserve case for IDNs during transportation Date: Thu, 13 Jun 2002 09:59:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.20 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps we should preserve case for IDNs during transportation, as we do today with English only names. Nameprep can be done at the server as well as the client, but is optional for the client during request and mandatory for the client if DNSSEC is required. That is: 1. Application ToACE multilingual domain name 2. Send ACE domain to server without doing Nameprep 3. If fail go to 5. If successful go to 4. 4. Authenticate and match response by first Namepreping both and comparing. 5. Send again with Namepreping, if successful go to 4, if fail then NX domain This way, case can be preserved during transportation just as it is today. Also, some browsers do the same with English domain names right now anyway: first send case preserved name, if fails, lowercase (or uppercase) and send again. Edmon From owner-idn@ops.ietf.org Thu Jun 13 12:29:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20625 for ; Thu, 13 Jun 2002 12:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IXKh-0007Sx-00 for idn-data@psg.com; Thu, 13 Jun 2002 09:20:23 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IXKd-0007Sm-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 09:20:19 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141559; Thu, 13 Jun 2002 11:18:19 -0500 Message-ID: <3D08C641.9050708@ehsco.com> Date: Thu, 13 Jun 2002 11:20:17 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/13/2002 5:03 AM Erik Nordmark wrote: >> Does an owner name exist at FF21? Does it have the queried RRtype? >> Does it have the queried class? > How does this work for non-terminal labels i.e. when there is a zone > cut? If there is a cut, then the zone has delegated away the responsibility for that portion of its namespace to the servers listed in the NS RRs associated with the owner name of the new child zone. If there is another RR associated with the owner name, that RR should be ignored, since the current zone is not authoritative for that portion of the namespace anymore (it has delegated the responsibility away). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 14:09:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24385 for ; Thu, 13 Jun 2002 14:09:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IYsP-0009RR-00 for idn-data@psg.com; Thu, 13 Jun 2002 10:59:17 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17IYsK-0009R8-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 10:59:12 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17IYsB-0002I2-00; Thu, 13 Jun 2002 17:59:03 +0000 Date: Thu, 13 Jun 2002 13:59:03 -0400 From: John C Klensin To: "Eric A. Hall" , IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <138372519.1023976743@localhost> In-Reply-To: <3D085422.1060608@ehsco.com> References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> X-Mailer: Mulberry/3.0.0a2 (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.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me add one bit of clarification to this (again, I don't think Eric and I are in complete agreement, but we seem to see some of the same requirements and solutions)... --On Thursday, 13 June, 2002 03:13 -0500 "Eric A. Hall" wrote: > on 6/13/2002 12:49 AM Adam M. Costello wrote: > >> Suppose the IETF were to issue a clarification of the DNS >> spec stating in no uncertain terms that bytes 80..FF in >> domain names must match exactly, and that there is no >> standard interpretation of those bytes as characters (not for >> any existing DNS services anyway). Then I wouldn't object if >> applications that don't like Nameprep were encouraged to use >> 8-bit names in DNS for non-human-oriented purposes. > >> Eric, would you be satisfied with that? What do other people >> think of that idea? > > I've given this some thought, and I think it's a creative > approach. But I don't think it's the right approach, since it > only ingrains some of the problems. I know you don't want to > hear this but it would actually make much more sense to do the > exact opposite, which is to prohibit eight-bit for the > standard RRs (which is also what John was saying I think) and > to embrace and encourage the use of multiple profiles in the > i18n namespace. As I indicated in one of my recent long notes, I'd like to make sure we can define new stuff (certainly Classes and probably RRs), with different rules. Examples: -- All upper case, with other characters being prohibited. -- Case-dependent matching of ASCII (i.e., lower and upper case are different) as well as everything else. -- True binary labels, with no per-octet interpretation (needed for compressed UCS-4 as well as for numeric labels). Now, I'm not sure that we will ever need or want any of these things (although some of Eric's examples point strongly in that direction. But I think anything that we do now --whether an overbroad statement about IDNA applicability or the (I believe misguided) text in 2181-- that permanently eliminates our doing any of the above except by an incompatible change, has few of no advantages and many disadvantages. And, yes, I share Eric's belief that strong data-typing and data type identification leads to better protocols and more interoperability when it is most important. john From owner-idn@ops.ietf.org Thu Jun 13 14:24:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24916 for ; Thu, 13 Jun 2002 14:24:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IZ8Y-0009nM-00 for idn-data@psg.com; Thu, 13 Jun 2002 11:15:58 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IZ8U-0009n2-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 11:15:54 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141585 for idn@ops.ietf.org; Thu, 13 Jun 2002 13:13:53 -0500 Message-ID: <3D08E157.5090609@ehsco.com> Date: Thu, 13 Jun 2002 13:15:51 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IDN Subject: [idn] profiles and the i18n namespace Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Herewith are a couple of examples of the way that profiles within the i18n namespace could/should work. These are entirely invented. One potential usage would be AppleTalk Name Binding Protocol (NBP) entries which were stored in the DNS. If I were to design such a beast, I might want to use multiple RRs which would facilitate easy registration via Dynamic DNS and which would also support easy browsing of a zone. Thus I might create a mutant of the SRV RR specifically for determining the local atalk zone, an RR for finding all of the registered NBP names within the atalk zone, and an RR for finding the IP address of a specific node: _nbp._atalk.domain ATSRV .domain _nbp._atalk..domain ATNBP ..domain ATNBP ..domain ATNBP ..domain ..domain ATA4 ..domain ATA4 ..domain 4ATA In order to use this I would need two profiles. I would need a profile for defining the valid syntax for the owner domain name of the ATSRV mutant, although the existing SRVprofile would work fine for the naming shown. I would also need a new profile for the domain name elements (owner names and RRdata) which explicitly referenced the NBP nodes. Note that _Inside AppleTalk_ already provides normalization rules and whatnot which suits their needs, so those would presumably be mapped into the new profile directly (ass-u-me, this is just for example purposes). This approach would mean that NBP clients would be able to easily predict the naming they needed to register a node within the atalk zone for the network they were on, and could pass a pre-structured name and RR to dynamic DNS without DDNS needing to know anything about the name (a gateway could also do this easily). Meanwhile, the structured profile also makes it easy for applications to work with the names they get back from the DNS when browsing the atalk zone. Clearly a structured profile would be needed even if this model were slapped onto STD13 octets, but it would also be necessary for the clients to make sense of the data from an i18n namespace too. The only real question at that point is whether or not the i18n namespace can handle the alternative profile. The nameprep-only camp is arguing against this on the grounds that it makes the namespace ambiguous, although there is no technical reason (IMO) that this won't work. First of all, a design as in the above avoids collisions through the use of service-specific owner names. This would be intelligent and reasonable design for anybody that wanted to avoid collisions. But let's assume they don't take such reasonable measures. Let's also asume that reasonable steps aren't taken to prevent collisions through nameprep comparisons. What the heck, let's assume a worst case scenario where the owner names are variants of a name and that they even reference each other through a service-specific alias: _nbp._atalk.example.com. ATNBP MyMãc.example.com. MyMãc.example.com. ATCNAME mymãc.example.com. mymãc.example.com. A 192.168.0.10 Assuming that the RR definitions and NBPprep profile allows for such behavior, an NBP browser would still use the input from the ATNBP RR to seed the original query. The user hasn't typed in the name. Insted the target of the query would be the octet sequence of "MyMãc.example.com." Note that this kind of mapping would even be required for a human to find a match in the zone. A human query for "mymãc" would not work, since there is no ATA4 or ATCNAME RR with that (octet-specific) owner name. Some kind of application-specific stringprepping MUST ALWAYS BE USED for that service to work at all. Similarly, queries by traditional applications would not collide either, since the queried names would have been fed through nameprep somewhere in the process and would have collapsed down to the normalized form before they were ever issued as DNS lookups. If the application is mangling the nameprep process so badly that it doesn't collapse the owner name, well, it's already broken. But even in that broken state NO ERRORS ARE PRODUCED since there is no A RR at MyMãc.example.com., nor can there ever be one since the nameprep rules associated with the A RR prohibit it. For all of those reasons, I think it is rather plain that there isn't any risk from cross-pollution, as long as the data-typing rules are adhered to by both parties (the application that created the name, and the application that is issuing a lookup for the name). Even if only one of the parties enforces the rules, there is no serious risk of casual collision (everyday queries for A and whatnot) since the application RRs won't exist at the queried labels. As for whether or not this makes the namespace confusing to users, I don't think so, since most users don't ever see the innards of the namespace. Even in the example above they would only see the NBP friendly name and would have no idea that there are DNS names involved there. Let the shredding begin. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 14:43:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25615 for ; Thu, 13 Jun 2002 14:43:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IZLK-000A4K-00 for idn-data@psg.com; Thu, 13 Jun 2002 11:29:10 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IZLG-000A3q-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 11:29:06 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141593; Thu, 13 Jun 2002 13:27:05 -0500 Message-ID: <3D08E46E.1020904@ehsco.com> Date: Thu, 13 Jun 2002 13:29:02 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: John C Klensin CC: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <138372519.1023976743@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/13/2002 12:59 PM John C Klensin wrote: > As I indicated in one of my recent long notes, I'd like to make > sure we can define new stuff (certainly Classes and probably > RRs), with different rules. Examples: I have no problem with class-specific rules. Servers reject queries for unknown classes so there is no conflict in the normal scenario. I would greatly prefer that new RRs in the IN class only use stringprep profiles and the i18n namespace if they need eight-bit data, simply because the data-typing provides benefits. However, if an application needs to store eight-bit RR-specific data -- and if the application is specifically willing to forego any ACE conversion -- then I see no reason to prohibit it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 15:42:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27931 for ; Thu, 13 Jun 2002 15:42:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IaLM-000BFu-00 for idn-data@psg.com; Thu, 13 Jun 2002 12:33:16 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IaLI-000BFj-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 12:33:13 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141615 for idn@ops.ietf.org; Thu, 13 Jun 2002 14:31:12 -0500 Message-ID: <3D08F375.6000609@ehsco.com> Date: Thu, 13 Jun 2002 14:33:09 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: IDN Subject: Re: [idn] profiles and the i18n namespace References: <3D08E157.5090609@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ps--appendix 1, RR definitions: ATSRV ATNBP ATA4 ATCNAME These formatting rules would be enforced whenever one of the associated RRs were created for storage or query-formation purposes. Transfer and comparison functions would use the resulting octet sequences. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 17:18:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00453 for ; Thu, 13 Jun 2002 17:18:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IbqK-000CxA-00 for idn-data@psg.com; Thu, 13 Jun 2002 14:09:20 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17IbqB-000Cwy-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 14:09:11 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Ibq9-0007Pz-00 for ; Thu, 13 Jun 2002 14:09:09 -0700 Date: Thu, 13 Jun 2002 21:09:09 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Preserve case for IDNs during transportation Message-ID: <20020613210908.GC27606@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <033101c212e2$93dba730$6601a8c0@neteka.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <033101c212e2$93dba730$6601a8c0@neteka.inc> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon Chung wrote: > 1. Application ToACE multilingual domain name > 2. Send ACE domain to server without doing Nameprep > 3. If fail go to 5. If successful go to 4. > 4. Authenticate and match response by first Namepreping both and comparing. > > 5. Send again with Namepreping, if successful go to 4, if fail then NX > domain Close, but not quite. I assume you intend to have the client detect whether the server performed nameprep on the query, and accept the response if so, otherwise re-issue the query in nameprepped form. To accomplish that, in step 4 you must not nameprep the response, instead you must compare the response against the nameprepped form of the query. But I can't imagine why anyone would care whether case is preserved on the way from the client to the server. I think it's in names coming the other direction that people might want to preserve case. AMC From owner-idn@ops.ietf.org Thu Jun 13 18:00:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01916 for ; Thu, 13 Jun 2002 18:00:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IcXf-0000Z5-00 for idn-data@psg.com; Thu, 13 Jun 2002 14:54:07 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17IcXV-0000RI-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 14:53:57 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17IcXU-0007Wf-00 for ; Thu, 13 Jun 2002 14:53:56 -0700 Date: Thu, 13 Jun 2002 21:53:56 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <20020613215356.GD27606@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D085422.1060608@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > Profiles present a great opportunity to enforce strong and consistent > data-typing with the different domain names. I can see that, but part of my concern is that you have tended to try to define the subtypes of domain names in terms of DNS resource record types. Domain names get used in protocols other than DNS, where they are not tagged with RR types. So the subtypes of domain names would have to be defined more abstractly, for example: host names mail domain names mailbox names service names kerberos realm names The RR types could then refer to these abstract subtypes, but other protocols could also refer to the abstract subtypes. The tricky part is that some of these subtypes are already in wide use in a wide variety of protocols without having ever been formalized. In my example list of subtypes, my intent is that the host field of a URI, the exchangers listed in an MX record, and the domain field of an HTTP cookie are all of type "host name", but no such connection has never been formally drawn between these various protocol elements. Similarly, my intent is that domain names in email addresses in mail headers, and domain names in email addresses in SMTP commands, are both of type "mail domain name", even though RFC 821 places tighter restrictions on the syntax than RFC 822 does. I suppose the way to attempt to accomodate your model in IDNA (but I'm not sure it could be done with sufficient rigor) would be something like this: ToASCII and ToUnicode would take a Stringprep profile as a parameter. This would be yet another thing that the application would have to select, along with the AllowUnassigned flag and the UseSTD3ASCIIRules flag. The IDNA spec would require that Nameprep and only Nameprep be used with host name labels and mail domain labels. Furthermore, applications would be forbidden from using IDNA with any other label types until profiles for them had been standardized. > There is another reason for going this route, which is that the > presence of eight-bit codes in the STD13 namespace makes managing > UCS names in dual-mode servers extremely difficult. It essentially > requires that servers flag eight-bit domain names as NOT UCS so that > the names don't get looked at when an EDNS/deACE'd query comes in. I came to that realization this morning. A hypothetical newDNS protocol that allowed text labels to be represented using UTF-8 while still supporting the RFC-1035 sequence-of-bytes labels would need an extra bit per label indicating whether byte values 80..FF are UTF-8 text, or opaque bytes like in DNS. A hypothetical new resolver interface would likewise need this extra bit per label if it wanted to support both text-labels and byte-labels. I don't know if I'd call that "extremely difficult". The only way to avoid the extra bit while adding native Unicode support is to drop support for RFC-1035 sequence-of-bytes labels. In fact, if I were designing a new resolver interface, I'd want it to have Nameprep built in (and maybe a few other common profiles, if there are such things), in which case I'd still need extra per-label meta-info, so the application could say "Please apply Nameprep for me" or "This label is already prepared, leave it alone" or maybe even "Please apply Fooprep for me". The application might also want to be able to say "Please return only prepared labels to me" or "Please feel free to return unprepared labels to me, and I'll be responsible for preparing them if needed". The latter option allows for the possibility of preserving case or non-normalized forms (which might or might not be possible depending on the underlying protocol). AMC From owner-idn@ops.ietf.org Thu Jun 13 18:43:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02958 for ; Thu, 13 Jun 2002 18:43:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Id7X-000JvR-00 for idn-data@psg.com; Thu, 13 Jun 2002 15:31:11 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Id7N-000JrG-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 15:31:01 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA10516; Thu, 13 Jun 2002 15:34:53 -0700 Message-Id: <5.1.0.14.2.20020613150809.03f204e8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 15:28:52 -0700 To: liana Ye From: Dave Crocker Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt Cc: idn@ops.ietf.org In-Reply-To: <20020611.123244.1072.1.liana.ydisg@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:32 PM 6/11/2002 -0700, liana Ye wrote: >No, IDNA does not replicate the model of MIME. MIME >deals with programmer-defined data types: multi-media. >These are well defined data types, and all MIME does >is to provide multiple channels - in sequence or in >parallel to accommodate them. MIME does several things. One of them is to permit use of extended character sets. Another is to provide a way of encoding non-ascii data onto an ascii "transport" environment. These are the parts of MIME that are relevant to IDN. The mechanisms of labeling different data types is a third MIME function, but it is not relevant to IDN. >IDNA has to consider charsets which can be an analogy >to multi-media, or I shall call them multi-charset in >term of LDH, Utf8, Utf16, GB, BIG5... IDN has chosen to use Unicode, rather than support an infinite range of alternative character sets. >IDNA has to consider UCS too, which reflexes the history IDNA is not intended as a general mechanism for supporting a wide range of historical character sets. It is intended to provide a single set of characters. >In one word, IDNA at least is two folds more complex >then MIME. IDNA is a subset of MIME capabilities, as described above. >The WG at IETF has to provide an infinitly-many solution >to deal with the two infinity problems: multi-culture and >open-glyph. Thank you. Your statement, here, underscores a fundamental difference in philosophy. When creating a standard, it is appealing to try to support a wide range of capabilities. This kind of support is flexible and it attempts to be friendly to a world of diversity. However experience shows that such flexibility often works against usefulness! Within the IETF world of standards, specifications tend to be far more successful when they LIMIT their flexibility. In particular, standards that choose a single capability, rather than supporting a wide range of alternatives, are simpler and easier to implement and simpler to use. These are very powerful benefits and they greatly increase the likelihood that a standard will succeed. > > a) making the scope of such an effort too large is a good > > way to ensure that it never gets done; however it is often easy > > to have that larger scope as a background agenda that is > > serviced along the way. > > > > b) we are some years too late for visiting that question > > upon this effort. > >This question has been looked at many times in the past, >and every time we have decided to postpone the issue. If >you say it is too late to visit this issue again, then you are >definitly repeating the past. It is certainly true, we have made >progress in understanding the problem :-) We could study the problem forever. However you might have noticed that registries are already selling proprietary IDN solutions today. If we wait longer, the proprietary solutions will lock out any opportunity for using an open standard. The market needs a standard today. In fact, it needed it several years ago. Your comments suggest a lack of urgency that I believe is very much at odds with the urgency felt by the market. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Thu Jun 13 18:50:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03082 for ; Thu, 13 Jun 2002 18:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IdFr-000MWX-00 for idn-data@psg.com; Thu, 13 Jun 2002 15:39:47 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IdFm-000MWJ-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 15:39:42 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141636 for idn@ops.ietf.org; Thu, 13 Jun 2002 17:37:42 -0500 Message-ID: <3D091F2B.1040703@ehsco.com> Date: Thu, 13 Jun 2002 17:39:39 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/13/2002 4:53 PM Adam M. Costello wrote: > The tricky part is that some of these subtypes are already in wide use > in a wide variety of protocols without having ever been formalized. > my example list of subtypes, my intent is that the host field of a URI, > the exchangers listed in an MX record, and the domain field of an HTTP > cookie are all of type "host name", but no such connection has never > been formally drawn between these various protocol elements. I think I can speak for John when I say that this is what he and I both want to see fixed. The vagaries and loose standardization has been more trouble than it is worth. If you look at the BNF for most of these protocols they are just LDH sequences already anyway. Also, the pre-2181 history has it that most systems only recognize LDH (I've even run across applications that couldn't parse 3com.com because it wasn't explicitly allowed until RFC 1123). If the i18n namespace is being invented for the sole purpose of standardized representation and interpretation of i18n domain names, there's really not any reason to go back and re-re-fix the standard RRtypes so that they are LDH hostnames. Finally, declaring a profile allows the other protocols to reuse that BNF in their syntax, rather than requiring them to define it for their own specific use. > I suppose the way to attempt to accomodate your model in IDNA (but I'm > not sure it could be done with sufficient rigor) would be something > like this: ToASCII and ToUnicode would take a Stringprep profile as > a parameter. This would be yet another thing that the application > would have to select, along with the AllowUnassigned flag and the > UseSTD3ASCIIRules flag. The IDNA spec would require that Nameprep and > only Nameprep be used with host name labels and mail domain labels. > Furthermore, applications would be forbidden from using IDNA with any > other label types until profiles for them had been standardized. Again, I would make the applications do the stingprep management, since they have to do so anyway for basic security measures. All IDNA needs to be is a simple codec that converts inputs and outputs (unless I completely misunderstand its inner workings). >>There is another reason for going this route, which is that the >>presence of eight-bit codes in the STD13 namespace makes managing >>UCS names in dual-mode servers extremely difficult. It essentially >>requires that servers flag eight-bit domain names as NOT UCS so that >>the names don't get looked at when an EDNS/deACE'd query comes in. > > I came to that realization this morning. A hypothetical newDNS protocol > that allowed text labels to be represented using UTF-8 while still > supporting the RFC-1035 sequence-of-bytes labels would need an extra > bit per label indicating whether byte values 80..FF are UTF-8 text, or > opaque bytes like in DNS. A hypothetical new resolver interface would > likewise need this extra bit per label if it wanted to support both > text-labels and byte-labels. > > I don't know if I'd call that "extremely difficult". The resolver doesn't have to keep track of this (it's just passing around octet sequences) but servers (including caches) have to. Otherwise an STD13 octet sequence which has been stored for future reference gets read as an ISO-8859-1 string and converted. Detecting the format of an incoming sequence is easy: the label is either STD13 or EDNS, and if it is STD13 with eight-bit codes then it is an STD13 eight-bit label. That's easy to deal with for comparison purposes at that particular moment but storing it and preventing comparison later isn't very simple. Also, somebody might expect the implementor to convert the eight-bit A RR into ACE or EDNS and scream if the implementor doesn't, which gets really ugly. However, if the default policy (and the existing standards-track RRs) is changed so that eight-bit codes aren't used by default -- and new RRs can only define STD13 octets if they are willing to forego conversion -- then storing these RRs means it is a little simpler with the flag because it becomes a distinct exception with clearcut logic and there can be no confusion that they are never subject to conversion. It also makes enforcing the policy change somewhat simple since violators are just rejected by the compliant server. Fix or die. The only remaining parties who are affected are those entities who have gone off and done their own thing, and managing the flag mapping becomes their problem rather than everybody's problem. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 18:50:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03105 for ; Thu, 13 Jun 2002 18:50:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IdIm-000Mbc-00 for idn-data@psg.com; Thu, 13 Jun 2002 15:42:48 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IdIh-000MaN-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 15:42:43 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141642 for idn@ops.ietf.org; Thu, 13 Jun 2002 17:40:28 -0500 Message-ID: <3D091FD2.5030000@ehsco.com> Date: Thu, 13 Jun 2002 17:42:26 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.8 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,MISSING_HEADERS version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mozilla has made my typo rate go through the roof for some reason. on 6/13/2002 5:39 PM Eric A. Hall wrote: > If the i18n namespace is being invented for the sole purpose of > standardized representation and interpretation of i18n domain names, > there's really not any reason to [NOT] go back and re-re-fix the > standard RRtypes so that they are LDH hostnames. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 19:12:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03488 for ; Thu, 13 Jun 2002 19:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Idce-000N1j-00 for idn-data@psg.com; Thu, 13 Jun 2002 16:03:20 -0700 Received: from host-111.innovation.t1.primus.ca ([216.254.145.111] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17Idcb-000N1S-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 16:03:17 -0700 Message-ID: <03d801c2132e$3d3063c0$6601a8c0@neteka.inc> From: "Edmon Chung" To: "IETF idn working group" References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <033101c212e2$93dba730$6601a8c0@neteka.inc> <20020613210908.GC27606@nicemice.net> Subject: Re: [idn] Preserve case for IDNs during transportation Date: Thu, 13 Jun 2002 19:01:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.20 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Adam M. Costello" > Edmon Chung wrote: > > > 1. Application ToACE multilingual domain name > > 2. Send ACE domain to server without doing Nameprep > > 3. If fail go to 5. If successful go to 4. > > 4. Authenticate and match response by first Namepreping both and comparing. > > > > 5. Send again with Namepreping, if successful go to 4, if fail then NX > > domain > > Close, but not quite. I assume you intend to have the client detect > whether the server performed nameprep on the query, and accept the > response if so, otherwise re-issue the query in nameprepped form. To > accomplish that, in step 4 you must not nameprep the response, instead > you must compare the response against the nameprepped form of the query. That is what I had in mind. > But I can't imagine why anyone would care whether case is preserved on > the way from the client to the server. I think it's in names coming the > other direction that people might want to preserve case. Of course there are lots of reasons why the name should not be tampered with before being sent out to the wire. For example to accomodate new codepoints or to use restricted codepoints in the DNS for internal purposes or experimentation, such as using the reserved characters for testing. These are all good reasons for not having the client blindly do nameprep before sending the request to the wire. Since the name is already ACEd there is no worry it would affect any other systems except for it being NX domain. Therefore I think it makes a lot of sense to not force nameprep on the application, but instead make it optional but mandatory on the server end. Just like what we have nowadays for English. Edmon From owner-idn@ops.ietf.org Thu Jun 13 20:05:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05149 for ; Thu, 13 Jun 2002 20:05:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IeQK-000OCi-00 for idn-data@psg.com; Thu, 13 Jun 2002 16:54:40 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17IeQA-000OBl-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 16:54:31 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17IeQ9-0007ox-00 for ; Thu, 13 Jun 2002 16:54:29 -0700 Date: Thu, 13 Jun 2002 23:54:29 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <20020613235428.GC29461@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D091F2B.1040703@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > > The tricky part is that some of these subtypes are already in > > wide use in a wide variety of protocols without having ever been > > formalized. > > > > my intent is that the host field of a URI, the exchangers listed in > > an MX record, and the domain field of an HTTP cookie are all of type > > "host name", but no such connection has never been formally drawn > > between these various protocol elements. > > I think I can speak for John when I say that this is what he and I > both want to see fixed. It would be great to have that fixed, but when will it happen? Can IDNA afford to wait for it? If not, should IDNA go ahead and limit the applicability of Nameprep to the still-vague concepts of "host name label" and "mail domain name label" in the hopes that those terms will become rigorous? I pose these questions to the working group--would this be comforting or disconcerting? In the past, any time Paul and Patrik and I have tried to talk about "what is a host name" it's been a mess. > Again, I would make the applications do the stringprep management, > since they have to do so anyway for basic security measures. All IDNA > needs to be is a simple codec that converts inputs and outputs (unless > I completely misunderstand its inner workings). We bundle Stringprep and Punycode and the prefix into a single operation for convenience of description, so we can say something simple like "for any text label X, ToASCII(X) is an equivalent ASCII label". We needed ToASCII and ToUnicode to serve as definitions of the correct results for *any* input, not just already-prepared input. If you have already-prepared input, you can optimize the Stringprep step down to nothing. IDNA never says that ToASCII needs to be performed all at once by a single entity. For example, an IDN-aware interface can require its non-ASCII input to be already prepared, in which case when it performs ToASCII the Stringprep step has no effect and can be optimized away. The thing calling the interface then has the burden of performing Stringprep, but not the rest of ToASCII. In this scenario the work of ToASCII has effectively been split across two entities. > > A hypothetical newDNS protocol that allowed text labels to be > > represented using UTF-8 while still supporting the RFC-1035 > > sequence-of-bytes labels would need an extra bit per label > > indicating whether byte values 80..FF are UTF-8 text, or opaque > > bytes like in DNS. A hypothetical new resolver interface would > > likewise need this extra bit per label if it wanted to support both > > text-labels and byte-labels. > > The resolver doesn't have to keep track of this Sure it does. If I pass an 8-bit label to a new-resolver, the resolver needs to know whether the 80..FF values are UTF-8 text or opaque bytes, so that it knows how to set that bit in the newDNS query, or so that it knows whether to convert to ACE before sending a DNS query. AMC From owner-idn@ops.ietf.org Thu Jun 13 20:16:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05414 for ; Thu, 13 Jun 2002 20:16:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iedk-000OZP-00 for idn-data@psg.com; Thu, 13 Jun 2002 17:08:32 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Iedb-000OYl-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 17:08:23 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Ieda-0007r7-00 for ; Thu, 13 Jun 2002 17:08:22 -0700 Date: Fri, 14 Jun 2002 00:08:22 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Preserve case for IDNs during transportation Message-ID: <20020614000821.GD29461@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <033101c212e2$93dba730$6601a8c0@neteka.inc> <20020613210908.GC27606@nicemice.net> <03d801c2132e$3d3063c0$6601a8c0@neteka.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03d801c2132e$3d3063c0$6601a8c0@neteka.inc> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon Chung wrote: > I think it makes a lot of sense to not force nameprep on the > application, but instead make it optional but mandatory on the server > end. Just like what we have nowadays for English. I would have no objection to a newDNS protocol allowing unprepared non-ASCII text in queries and requiring the server to perform the preparation. (Well, I might wonder about the computational load on the server.) But I don't like the idea of unprepared ACE forms. It would mean disagreement about whether two ACE labels match. Someone applying the traditional ASCII comparison might say they don't match, while someone applying your proposed decode-prepare-compare method might say they do match. The conversions were designed so that comparing the ACE forms always yields the same answer as comparing the non-ASCII forms. The conversions are designed so that "unprepared ACE forms" don't exist; if you think you have one, you will find that it doesn't decode, it's just an ASCII label that happens to begin with the ACE prefix, but it's not an ACE. AMC From owner-idn@ops.ietf.org Thu Jun 13 20:27:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05789 for ; Thu, 13 Jun 2002 20:27:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ier8-000OvX-00 for idn-data@psg.com; Thu, 13 Jun 2002 17:22:22 -0700 Received: from host-111.innovation.t1.primus.ca ([216.254.145.111] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17Ier3-000OvK-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 17:22:17 -0700 Message-ID: <041201c21339$2cd3d920$6601a8c0@neteka.inc> From: "Edmon Chung" To: References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <033101c212e2$93dba730$6601a8c0@neteka.inc> <20020613210908.GC27606@nicemice.net> <03d801c2132e$3d3063c0$6601a8c0@neteka.inc> <20020614000821.GD29461@nicemice.net> Subject: Re: [idn] Preserve case for IDNs during transportation Date: Thu, 13 Jun 2002 20:19:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.20 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit But is it not the same experience for the DNS today? Case is preserved during transport and matched by the server. If authentication is required, the client will match it correspondingly. There is no issue about non-resolution because the client should retry if the unpreped name is not found. This infact is what some of the current browsers already do for the casing in English. Edmon ----- Original Message ----- From: "Adam M. Costello" To: "IETF idn working group" Sent: Thursday, June 13, 2002 8:08 PM Subject: Re: [idn] Preserve case for IDNs during transportation > Edmon Chung wrote: > > > I think it makes a lot of sense to not force nameprep on the > > application, but instead make it optional but mandatory on the server > > end. Just like what we have nowadays for English. > > I would have no objection to a newDNS protocol allowing unprepared > non-ASCII text in queries and requiring the server to perform the > preparation. (Well, I might wonder about the computational load on the > server.) > > But I don't like the idea of unprepared ACE forms. It would mean > disagreement about whether two ACE labels match. Someone applying the > traditional ASCII comparison might say they don't match, while someone > applying your proposed decode-prepare-compare method might say they do > match. The conversions were designed so that comparing the ACE forms > always yields the same answer as comparing the non-ASCII forms. The > conversions are designed so that "unprepared ACE forms" don't exist; if > you think you have one, you will find that it doesn't decode, it's just > an ASCII label that happens to begin with the ACE prefix, but it's not > an ACE. > > AMC > > From owner-idn@ops.ietf.org Thu Jun 13 20:54:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06415 for ; Thu, 13 Jun 2002 20:54:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IfCq-000PUI-00 for idn-data@psg.com; Thu, 13 Jun 2002 17:44:48 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17IfCh-000PU1-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 17:44:39 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17IfCg-0007xZ-00 for ; Thu, 13 Jun 2002 17:44:38 -0700 Date: Fri, 14 Jun 2002 00:44:38 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Preserve case for IDNs during transportation Message-ID: <20020614004438.GE29461@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <033101c212e2$93dba730$6601a8c0@neteka.inc> <20020613210908.GC27606@nicemice.net> <03d801c2132e$3d3063c0$6601a8c0@neteka.inc> <20020614000821.GD29461@nicemice.net> <041201c21339$2cd3d920$6601a8c0@neteka.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <041201c21339$2cd3d920$6601a8c0@neteka.inc> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk > But is it not the same experience for the DNS today? Case is > preserved during transport and matched by the server. Yes, but existing servers don't know how to compare non-ASCII text case-insensitively, so that model doesn't work with the existing infrastructure. You are free to use that model in newDNS. Suppose ToASCII(X) == xx--foo, and ToASCII_without_Nameprep(X) == xx--bar. We are not going to say that xx--foo and xx--bar are equivalent, because the existing domain name standards already say they are not equivalent. AMC From owner-idn@ops.ietf.org Thu Jun 13 20:55:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06429 for ; Thu, 13 Jun 2002 20:55:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IfAP-000PQa-00 for idn-data@psg.com; Thu, 13 Jun 2002 17:42:17 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IfAJ-000PQM-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 17:42:11 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141664 for idn@ops.ietf.org; Thu, 13 Jun 2002 19:40:09 -0500 Message-ID: <3D093BDF.5080409@ehsco.com> Date: Thu, 13 Jun 2002 19:42:07 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> <20020613235428.GC29461@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/13/2002 6:54 PM Adam M. Costello wrote: > It would be great to have that fixed, but when will it happen? WILL it happen is the question since it would have to be done by DNSEXT. Between John, Erik and myself I think a compelling argument can be made for it. Other WGs need this too (the CRISP WG needs BNF for the RRs so that ASN.1 syntaxes can be defined so that WHOIS-like information can be specified for storage in LDAP, for example). > Can IDNA afford to wait for it? If not, should IDNA go ahead and limit > the applicability of Nameprep to the still-vague concepts of "host name > label" and "mail domain name label" in the hopes that those terms will > become rigorous? I don't know how to answer that. It would seem that a standalone codec doesn't need to specify anything other than the inputs and outputs, and without imposing on other standards and WGs. I would also think that nameprep can say that it provides one method for mapping UCS character sequences into strings which are usable as LDH labels (and vice-versa) without imposing on other standards and WGs. Otherwise I'll leave this to people who are more knowledgable in these matters. I'll say no more on this subject. > We bundle Stringprep and Punycode and the prefix into a single operation > for convenience of description, so we can say something simple like > "for any text label X, ToASCII(X) is an equivalent ASCII label". We > needed ToASCII and ToUnicode to serve as definitions of the correct > results for *any* input, not just already-prepared input. If you have > already-prepared input, you can optimize the Stringprep step down to > nothing. > > IDNA never says that ToASCII needs to be performed all at once by a > single entity. For example, an IDN-aware interface can require its > non-ASCII input to be already prepared, in which case when it performs > ToASCII the Stringprep step has no effect and can be optimized away. > The thing calling the interface then has the burden of performing > Stringprep, but not the rest of ToASCII. In this scenario the work of > ToASCII has effectively been split across two entities. > How about mixing the two models? You can pass a stringprep profile to ToASCII as a parameter, but an empty parameter value (or some other flag) means that the string has already been prepared and that steps(N) are to be skipped. Would that work? >>The resolver doesn't have to keep track of this > > Sure it does. If I pass an 8-bit label to a new-resolver, the resolver > needs to know whether the 80..FF values are UTF-8 text or opaque bytes Clarification, the resolver doesn't "need" a flag because it already has access to a flag. On the application side, this would be the Wide API versus the legacy API, while on the wire side this would be the STD13 versus EDNS label formats. In either case, if the legacy API/label is used and the label does not contain zz-- then it is not ACE and it certainly isn't UTF-8. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jun 13 21:25:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06975 for ; Thu, 13 Jun 2002 21:25:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ifi1-0001DH-00 for idn-data@psg.com; Thu, 13 Jun 2002 18:17:01 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Ifhs-00016R-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 18:16:52 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Ifhr-00088W-00 for ; Thu, 13 Jun 2002 18:16:51 -0700 Date: Fri, 14 Jun 2002 01:16:51 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <20020614011651.GA31167@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> <20020613235428.GC29461@nicemice.net> <3D093BDF.5080409@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D093BDF.5080409@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,NO_MX_FOR_FROM version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > You can pass a stringprep profile to ToASCII as a parameter, but an > empty parameter value (or some other flag) means that the string has > already been prepared and that steps(N) are to be skipped. Would that > work? That would be a fine way to implement it. In the specification, it needs to be clear that "apply ToASCII" means the proper Stringprep profile must be applied, it is not optional. Exactly when and by whom it is applied is an implementation detail. > Clarification, the resolver doesn't "need" a flag because it already > has access to a flag. On the application side, this would be the Wide > API versus the legacy API That works until you have a name in which some labels are non-ASCII text and some labels are opaque bytes. I guess in that case the application could just use the legacy API and do the IDNA conversions itself. But another solution is for the new API to take an extra bit per label as input. AMC From owner-idn@ops.ietf.org Fri Jun 14 00:55:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11516 for ; Fri, 14 Jun 2002 00:55:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iisk-0008zM-00 for idn-data@psg.com; Thu, 13 Jun 2002 21:40:18 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Iisg-0008zB-00 for idn@ops.ietf.org; Thu, 13 Jun 2002 21:40:14 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141685 for idn@ops.ietf.org; Thu, 13 Jun 2002 23:38:14 -0500 Message-ID: <3D0973AC.7040606@ehsco.com> Date: Thu, 13 Jun 2002 23:40:12 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> <20020613235428.GC29461@nicemice.net> <3D093BDF.5080409@ehsco.com> <20020614011651.GA31167@nicemice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/13/2002 8:16 PM Adam M. Costello wrote: >> Clarification, the resolver doesn't "need" a flag because it already >> has access to a flag. On the application side, this would be the Wide >> API versus the legacy API > > That works until you have a name in which some labels are non-ASCII > text and some labels are opaque bytes. I had to think about this some. If any label is EDNS/UTF-8 then all of them must be flagged that way. So if any domain names come through the legacy API then all of the labels in that domain name are treated as STD13. The entire domain name is what gets cached, and not the individual labels. Therefore, if any of the STD13 labels contained eight-bit data (regardless of whether there was ACE in any of the others) the entire domain name would get flagged. There would not be any expansion of the other labels in that scenario, and that domain name would always be returned as an STD13 sequence. In the normal scenario, the zone-specific labels can't have eight-bit character codes since those labels aren't legitimate for delegation, so only the labels on the left edge of the domain can possibly contain eight-bit data. This means that the scheme above won't cause problems with any "normal" domain names (such as delegations) but would only prevent the abnormal domain names from undergoing conversion. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Jun 14 16:43:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14711 for ; Fri, 14 Jun 2002 16:43:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ixgd-0000ds-00 for idn-data@psg.com; Fri, 14 Jun 2002 13:28:47 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17IxgZ-0000dh-00 for idn@ops.ietf.org; Fri, 14 Jun 2002 13:28:44 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17IxgY-0001eP-00 for ; Fri, 14 Jun 2002 13:28:42 -0700 Date: Fri, 14 Jun 2002 20:28:42 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <20020614202842.GA6218@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> <20020613235428.GC29461@nicemice.net> <3D093BDF.5080409@ehsco.com> <20020614011651.GA31167@nicemice.net> <3D0973AC.7040606@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D0973AC.7040606@ehsco.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk "Eric A. Hall" wrote: > So if any domain names come through the legacy API then all of the > labels in that domain name are treated as STD13. Right. Which is why it might be convenient for applications if the new resolver API takes an extra bit per label as input. Suppose I want to look up a STD-13 8-bit label under an internationalized domain. If I can only flag the whole domain as STD-13, then I need to perform ToASCII for the other labels. If I can flag individual labels, then I can pass in a name containing one STD-13 8-bit label and several non-ASCII text labels, and the resolver will know what to do. On the other hand, if you want to discourage the use of STD-13 8-bit labels, then requiring the use of the old API for the entire name will help with the discouraging. :) AMC From owner-idn@ops.ietf.org Fri Jun 14 16:57:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14921 for ; Fri, 14 Jun 2002 16:57:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iy0C-00014v-00 for idn-data@psg.com; Fri, 14 Jun 2002 13:49:00 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17Iy08-00014V-00 for idn@ops.ietf.org; Fri, 14 Jun 2002 13:48:56 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17Iy07-0001hW-00 for ; Fri, 14 Jun 2002 13:48:55 -0700 Date: Fri, 14 Jun 2002 20:48:55 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] One profile for domain names, or many? Message-ID: <20020614204855.GA6361@nicemice.net> Reply-To: IETF idn working group References: <20020613002810.GC17395@nicemice.net> <3D08185B.5080002@ehsco.com> <20020613054905.GC20196@nicemice.net> <3D085422.1060608@ehsco.com> <20020613215356.GD27606@nicemice.net> <3D091F2B.1040703@ehsco.com> <20020613235428.GC29461@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020613235428.GC29461@nicemice.net> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Here is my attempt at wording to clearly delimit the scope of IDNA and Nameprep without precluding any future directions: Applicability of Nameprep: When ToASCII or ToUnicode is applied to a label, the proper Stringprep profile for that label MUST be used. Nameprep is the proper profile for all types of labels that do not specify a profile, which includes all types that predate IDNA (for example, host name labels and mail domain labels). In the future the IETF might or might not define new types of labels that use other profiles with IDNA. Applicability of IDNA: IDNA MAY be used with all types of textual domain names and textual domain labels that do not explicitly forbid the use of IDNA, which includes all types that predate IDNA (for example, host names and mail domain names). In the future the IETF might or might not define new types of textual domain names/labels that forbid the use of IDNA. IDNA cannot be used with domain labels that contain non-textual data. For example, in the current DNS protocol [RFC1034] [RFC1035] labels can contain octet values greater than 0x7F, but there is no defined interpretation of those values as characters. Therefore IDNA cannot be used with DNS labels containing octet values greater than 0x7F. With this policy, I think we could publish IDNA now and defer the one-vs-many-profiles decision until later. We can make a more informed decision after the effort to formalize the label types has succeeded or failed. I think this policy would make it clear how to use IDNA today, and would leave the IETF with three options when people ask to define a new label that doesn't use Nameprep: 1) Use a STD-13 binary. 2) Use a text label that forbids the use of IDNA. 3) Use a text label that requires fooprep with IDNA. We could in the future decide that one or two of these options are undesirable and should never be used, but for the moment we can leave them all open. What do people think of this? AMC From owner-idn@ops.ietf.org Sat Jun 15 22:57:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18873 for ; Sat, 15 Jun 2002 22:57:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JQ0R-0007iO-00 for idn-data@psg.com; Sat, 15 Jun 2002 19:43:07 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17JQ0O-0007iA-00 for idn@ops.ietf.org; Sat, 15 Jun 2002 19:43:04 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA21115; Sat, 15 Jun 2002 19:47:11 -0700 Message-Id: <5.1.0.14.2.20020615142442.023f8700@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 15 Jun 2002 14:37:59 -0700 To: John C Klensin From: Dave Crocker Subject: Re: [idn] IDNA applicability: per RR/Class or DNS-wide (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: idn@ops.ietf.org In-Reply-To: <53855516.1023791895@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,PORN_10 version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:38 AM 6/11/2002 -0400, John C Klensin wrote: > Should the applicability of IDNA in the DNS context, and > the xxx-prep procedures to be used with it, be specified > on a per-RR (and per-Class) basis? > >(i) The DNS now has different rules for valid label forms and >parameters for different RR types (e.g., "A", "MX", etc., are >recommended to contain only LDH names, while "SRV" uses names >that are in ASCII but violation LDN norms) and the core DNS >specification clearly anticipates an even broader range of >names/ labels. IDNA should recognize this and anticipate the >use of different "foo-prep" profiles of stringprep with >different RR types and/or classes, rather than forcing >everything into a "nameprep" model. Or IDNA should focus only on solving the URL/mail naming issue and defer the rest. The deferral will not be -- cannot be and has not been -- entirely ignoring the future effort for other aspects of RR domain label specification. But it need not be required to solve the whole problem for everyone for ever. >(ii) It is unreasonable and undesirable for IDNA to specify >behavior for Classes and RRs not yet invented. Constraints like >that are nothing but an invitation to trouble. > >Suggested remedies: damn. i think i agree with your suggestions, though #3 is a bit discomfiting. >This model is just much cleaner. It makes IDNA more flexible >for other uses and protocols. ... >This work is long overdue. grrrr. mumble. i agree. grrrr. d/ >---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 15 22:57:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18876 for ; Sat, 15 Jun 2002 22:57:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JQ05-0007hk-00 for idn-data@psg.com; Sat, 15 Jun 2002 19:42:45 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17JQ01-0007hZ-00 for idn@ops.ietf.org; Sat, 15 Jun 2002 19:42:41 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA21033; Sat, 15 Jun 2002 19:46:41 -0700 Message-Id: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 15 Jun 2002 14:08:51 -0700 To: John C Klensin From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: idn@ops.ietf.org In-Reply-To: <51536347.1023789576@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:59 AM 6/11/2002 -0400, John C Klensin wrote: > Is IDNA properly and adequately specified for the uses to > which it will be put and is it designed appropriately > for that range of uses? > >I think the answer is probably that more specification, tightly >bound to IDNA, is needed. In terms of the sequencing of things, >I believe that the beginning of serious work on those >specifications will expose specification problems with the >current IDNA spec. It is certainly true that further work will develop further understanding. In this business, that's a truism. The pattern of IETF experience suggest a number of interesting guidelines, some of which are impressively counter-intuitive. And intuitively obvious rule is that a complex problem needs to be studied carefully and thoroughly and the solution needs to be complete, before it is release. The rule is wrong. IETF experience shows that consistently, yet it is being cited here. The rule that works -- especially for a new effort -- it to find a way to release the smallest, useful piece of work as quickly as possible, so that the learning and improving can be based on experience, rather than on academic introspection. It is essential to note both words -- smallest and useful. The former permits releasing something quickly, though one is hardpressed to find a way to apply the word quickly to IDN. The latter ensures market pull to deply and use the new facility. Infinite delay of the IDN work will have one major benefit: The current proprietary solutions will gain permanent position in the market. The derivative likelihood is that the IETF work will cease to matter. We have an excellent example of this possibility with instant messaging. Let's not repeat it for IDN. >(i) The specification now appears to say that applications can >decide to use IDNA or not. Yes, it is a meaningless statement and should be removed. IETF standards are always optional. In other words, the problem is with the presence of the statement. The statement itself does not cite a meaningful problem. >(ii) The specification seems inconsistent about what it about >and who needs to understand it. So the applicability text needs clarifying. Not the normative text. That is hardly a major issue. > It implies in several places >that it is not about the DNS and has no impact on the DNS. Yes, the text could be more clear. That is often true of new text. However this example of needing greater clarity again does not pertain to normative specification. My own effort to work through the text suggests that the specification really covers 3 issues: 1. Enhancement of the DNS label namespace, to expand to include Unicode -- IDN. This is clearly a change to the formal DNS model. 2. Provision of a general mechanism for encoding Unicode (non-Ascii) into a portion of the ASCII namespace -- ACE. This requires reserving a piece of the existing name space. It also requires changes to participating resolvers (or the software that calls resolvers) and to DNS server administrative tools. However it requires no changes to the DNS protocol, nor to non-participating DNS entities. Obviously it also requires changes to participating applications, but that is a matter concerning support for Unicode, rather than anything about the DNS, itself. 3. Rules for creating internationalized host names (ie, domain names intended for use in URLs and email addresses) by using IDNA but still working under both STD13 and STD3. For convenience, I am starting to call this IDNA-Host. >(iii) Despite the "applications can choose to do this, or not do >it" language, section 6.4 effectively implies a requirement that >any application that uses the DNS be upgraded. If a DNS entity is going to participate in IDNA, it must be upgraded. That is a truism. Here again, the real problem is that the attempt to help clarify things has been counter-productive. The right solution is simply to remove that bit of text. It is not normative;. >(iv) Section 7 imposes several normative requirements on name >servers and zone populations. ... > >(v) In particular, several of the statements in the draft go >beyond almost anything we have about the DNS in trying to >narrowly constrain the behavior of RR labels and data that are >not yet defined, Interestingly, I believe the real problem here is with trying to do exactly what you are proposing, namely to work on a whole problem, rather than first solving the smallest, immediately useful part that can be done. So, here again, the right answer is to factor out the larger work for a later time. (My reading of your note suggests you might even agree on this point.) That immediately useful work needs to be about domain names -- and more specifically about the strings that are used in URLS and email addresses. Other domain labels that occur within DNS RRs can be considered in separate work. >(vi) I suggest that it is a useful general principle to design >service ("micro layer" to use Dave's term) protocols to be as The IDNA document's term is "shim". I find myself preferring the contextual implications of that word. Micro-layer works as a formalism, but shim is a term that carries more information. >general as feasible without making them overly complex. What generality is lacking from the current IDNA spec? >It should be revised and some of that material should be pulled >out and into separate documents. As an alternative, that >material should be highlighted: the abstract and introductory >material should indicate that these normative DNS requirements >are present, that 2181 is explicitly updated, and so on. >Finally, the apparent reach of the protocol should be narrowed >and specified, either in this document or elsewhere. This is amusing. You are suggesting a bit of work that I believe is straightforward document cleanup, rather than substantial delay. I agree with you. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 15 22:57:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18899 for ; Sat, 15 Jun 2002 22:57:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JQ0I-0007i2-00 for idn-data@psg.com; Sat, 15 Jun 2002 19:42:58 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17JQ0E-0007hp-00 for idn@ops.ietf.org; Sat, 15 Jun 2002 19:42:54 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA21048; Sat, 15 Jun 2002 19:46:55 -0700 Message-Id: <5.1.0.14.2.20020615140908.022afe70@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 15 Jun 2002 14:24:22 -0700 To: John C Klensin From: Dave Crocker Subject: Re: [idn] IDNA: a micro layer above DNS or DNS internationalization ? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: idn@ops.ietf.org In-Reply-To: <46752036.1023784792@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:39 AM 6/11/2002 -0400, John C Klensin wrote: > Is IDNA closely bound to internationalization of the DNS > or, as you note above, is it really "about a micro layer > above DNS and below applications" and hence "has nothing > to do with putting anything into RRs"? > >I have long read the charter of this WG more broadly than Dave >has, but I see nothing that authorizes the WG to develop general >internationalization tools or new micro layers. Larger internationalization, no. Micro layer is just an approach to solving a requirement. > So, if we take >the "nothing to do with the DNS" reading of what IDNA is about, That phrase is not careful enough. IDNA is not about the DNS protocol. Certainly the introduction of Unicode is very much about the expansion of the DNS namespace. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 15 23:06:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18956 for ; Sat, 15 Jun 2002 23:06:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JQCm-0007x8-00 for idn-data@psg.com; Sat, 15 Jun 2002 19:55:52 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17JQCi-0007wv-00 for idn@ops.ietf.org; Sat, 15 Jun 2002 19:55:48 -0700 Received: (qmail 20357 invoked from network); 16 Jun 2002 03:00:58 -0000 Received: from bb-203-125-8-234.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.8.234) by sentosa.post1.com with SMTP; 16 Jun 2002 03:00:58 -0000 Message-ID: <00aa01c214e1$4a24d480$c600a8c0@JAMESSONYVAIO> From: "James Seng" To: "John C Klensin" , "Dave Crocker" Cc: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Sun, 16 Jun 2002 10:55:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have tried to remain silent and observe the discussion going on. I think the discussion of IETF history, experience and best practice should be bought to another list (poised?) or offline, despite the education value. Given we are in the last stage of the wg, I dont think we have too many newcomers lately. Thanks. -James Seng ----- Original Message ----- From: "Dave Crocker" To: "John C Klensin" Cc: Sent: Sunday, June 16, 2002 5:08 AM Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) > At 09:59 AM 6/11/2002 -0400, John C Klensin wrote: > > Is IDNA properly and adequately specified for the uses to > > which it will be put and is it designed appropriately > > for that range of uses? > > > >I think the answer is probably that more specification, tightly > >bound to IDNA, is needed. In terms of the sequencing of things, > >I believe that the beginning of serious work on those > >specifications will expose specification problems with the > >current IDNA spec. > > It is certainly true that further work will develop further > understanding. In this business, that's a truism. > > The pattern of IETF experience suggest a number of interesting guidelines, > some of which are impressively counter-intuitive. > > And intuitively obvious rule is that a complex problem needs to be studied > carefully and thoroughly and the solution needs to be complete, before it > is release. > > The rule is wrong. > > IETF experience shows that consistently, yet it is being cited here. > > The rule that works -- especially for a new effort -- it to find a way to > release the smallest, useful piece of work as quickly as possible, so that > the learning and improving can be based on experience, rather than on > academic introspection. > > It is essential to note both words -- smallest and useful. The former > permits releasing something quickly, though one is hardpressed to find a > way to apply the word quickly to IDN. The latter ensures market pull to > deply and use the new facility. > > Infinite delay of the IDN work will have one major benefit: The current > proprietary solutions will gain permanent position in the market. The > derivative likelihood is that the IETF work will cease to matter. > > We have an excellent example of this possibility with instant > messaging. Let's not repeat it for IDN. > > > >(i) The specification now appears to say that applications can > >decide to use IDNA or not. > > Yes, it is a meaningless statement and should be removed. IETF standards > are always optional. > > In other words, the problem is with the presence of the statement. The > statement itself does not cite a meaningful problem. > > > >(ii) The specification seems inconsistent about what it about > >and who needs to understand it. > > So the applicability text needs clarifying. Not the normative text. That > is hardly a major issue. > > > > It implies in several places > >that it is not about the DNS and has no impact on the DNS. > > Yes, the text could be more clear. That is often true of new > text. However this example of needing greater clarity again does not > pertain to normative specification. > > My own effort to work through the text suggests that the specification > really covers 3 issues: > > 1. Enhancement of the DNS label namespace, to expand to include Unicode -- > IDN. This is clearly a change to the formal DNS model. > > 2. Provision of a general mechanism for encoding Unicode (non-Ascii) into > a portion of the ASCII namespace -- ACE. This requires reserving a piece > of the existing name space. It also requires changes to participating > resolvers (or the software that calls resolvers) and to DNS server > administrative tools. However it requires no changes to the DNS protocol, > nor to non-participating DNS entities. Obviously it also requires changes > to participating applications, but that is a matter concerning support for > Unicode, rather than anything about the DNS, itself. > > 3. Rules for creating internationalized host names (ie, domain names > intended for use in URLs and email addresses) by using IDNA but still > working under both STD13 and STD3. For convenience, I am starting to call > this IDNA-Host. > > > >(iii) Despite the "applications can choose to do this, or not do > >it" language, section 6.4 effectively implies a requirement that > >any application that uses the DNS be upgraded. > > If a DNS entity is going to participate in IDNA, it must be upgraded. That > is a truism. Here again, the real problem is that the attempt to help > clarify things has been counter-productive. The right solution is simply > to remove that bit of text. It is not normative;. > > > >(iv) Section 7 imposes several normative requirements on name > >servers and zone populations. ... > > > >(v) In particular, several of the statements in the draft go > >beyond almost anything we have about the DNS in trying to > >narrowly constrain the behavior of RR labels and data that are > >not yet defined, > > Interestingly, I believe the real problem here is with trying to do exactly > what you are proposing, namely to work on a whole problem, rather than > first solving the smallest, immediately useful part that can be done. So, > here again, the right answer is to factor out the larger work for a later > time. (My reading of your note suggests you might even agree on this point.) > > That immediately useful work needs to be about domain names -- and more > specifically about the strings that are used in URLS and email > addresses. Other domain labels that occur within DNS RRs can be considered > in separate work. > > > >(vi) I suggest that it is a useful general principle to design > >service ("micro layer" to use Dave's term) protocols to be as > > The IDNA document's term is "shim". I find myself preferring the > contextual implications of that word. Micro-layer works as a formalism, > but shim is a term that carries more information. > > > >general as feasible without making them overly complex. > > What generality is lacking from the current IDNA spec? > > > >It should be revised and some of that material should be pulled > >out and into separate documents. As an alternative, that > >material should be highlighted: the abstract and introductory > >material should indicate that these normative DNS requirements > >are present, that 2181 is explicitly updated, and so on. > > >Finally, the apparent reach of the protocol should be narrowed > >and specified, either in this document or elsewhere. > > This is amusing. > > You are suggesting a bit of work that I believe is straightforward document > cleanup, rather than substantial delay. > > I agree with you. > > d/ > > > ---------- > Dave Crocker > TribalWise, Inc. > tel +1.408.246.8253; fax +1.408.850.1850 > > > From owner-idn@ops.ietf.org Sat Jun 15 23:10:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18974 for ; Sat, 15 Jun 2002 23:10:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JQHT-00084a-00 for idn-data@psg.com; Sat, 15 Jun 2002 20:00:43 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17JQHQ-00084O-00 for idn@ops.ietf.org; Sat, 15 Jun 2002 20:00:40 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA21652; Sat, 15 Jun 2002 20:04:43 -0700 Message-Id: <5.1.0.14.2.20020615195835.03922550@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 15 Jun 2002 20:00:22 -0400 To: "James Seng" From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: "John C Klensin" , In-Reply-To: <00aa01c214e1$4a24d480$c600a8c0@JAMESSONYVAIO> References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:55 AM 6/16/2002 +0800, James Seng wrote: >I think the discussion of IETF history, experience and best practice should >be bought to another list (poised?) or offline, despite the education value. >Given we are in the last stage of the wg, I dont think we have too many >newcomers lately. James, Please review the context of the historical comment. I was responding to an apparent suggestion that this working group delay publishing the current work until it completed additional work that had not yet started. So, the reference to history was solely for suggesting guidance in the current IDN working group circumstance. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Jun 16 04:42:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00115 for ; Sun, 16 Jun 2002 04:42:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JVOv-000Cn7-00 for idn-data@psg.com; Sun, 16 Jun 2002 01:28:45 -0700 Received: from ds217-115-140-127.dedicated.hosteurope.de ([217.115.140.127] helo=ns10913a.cobalthosting.net) by psg.com with esmtp (Exim 3.36 #1) id 17JVOq-000Cmw-00 for idn@ops.ietf.org; Sun, 16 Jun 2002 01:28:40 -0700 Received: from notebook (pD9538CAD.dip.t-dialin.net [217.83.140.173]) by ns10913a.cobalthosting.net (8.10.2/8.10.2) with SMTP id g5G8Saq24678 for ; Sun, 16 Jun 2002 10:28:36 +0200 Message-ID: <002801c2150f$9f9aa4c0$b48dfea9@notebook> From: "Georg Ochsner" To: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <00aa01c214e1$4a24d480$c600a8c0@JAMESSONYVAIO> Subject: [idn] When will IDNs go live? Date: Sun, 16 Jun 2002 10:27:15 +0200 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=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear WG, I've been listening to you now since dec 2001. Besides all the interesting technical aspects, I'd be very interested in the schedule now for launching IDNs. Hundred thousands of people are actually waiting for your results and have already spent money on IDNs. On the other side you do not seem to care about time very much (at all?) ... In the meantime Verisign goes its own way again and has just extended the registration period for IDNs for additional free 4 months and will bring out a free ACE-plug-in for IE and outlook... My question is not technical but aiming on your project management. What is the actual schedule? When will IDNs really go live? Thanks Georg From owner-idn@ops.ietf.org Sun Jun 16 19:31:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09225 for ; Sun, 16 Jun 2002 19:31:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JjLA-000N3D-00 for idn-data@psg.com; Sun, 16 Jun 2002 16:21:48 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17JjL6-000N32-00 for idn@ops.ietf.org; Sun, 16 Jun 2002 16:21:45 -0700 Received: from MASTER ([211.196.254.39]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5GNLTA20954 for ; Mon, 17 Jun 2002 08:21:29 +0900 Message-ID: <005a01c2158c$7978a670$2b19fea9@temp> From: "Soobok Lee" To: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Mon, 17 Jun 2002 08:20:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > > Infinite delay of the IDN work will have one major benefit: The current > proprietary solutions will gain permanent position in the market. The > derivative likelihood is that the IETF work will cease to matter. At least, IETF/ICANN/DoC could issue warnings, since they sit on the top of the DNS hierarchy. Proposing a half-baked or unimplementable soluion as standards does not help, since it will be abandoned and it will be classified as yet another proprietary solution by industries as long as everyone knows they are just quick fix for registries, not for all the public. > > We have an excellent example of this possibility with instant > messaging. Let's not repeat it for IDN. Seems Pointless. DNS is mandatory and universal, while application protocols are optional. If you are proposing directory-flavored micro layer above DNS, you will get my support. But it should be called as an interactive translation service, instead of IDN. Soobok Lee From owner-idn@ops.ietf.org Sun Jun 16 20:45:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09924 for ; Sun, 16 Jun 2002 20:45:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JkXy-000OAv-00 for idn-data@psg.com; Sun, 16 Jun 2002 17:39:06 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17JkXu-000OAi-00 for idn@ops.ietf.org; Sun, 16 Jun 2002 17:39:02 -0700 Received: (qmail 28293 invoked from network); 17 Jun 2002 00:44:07 -0000 Received: from bb-203-125-8-234.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.8.234) by sentosa.post1.com with SMTP; 17 Jun 2002 00:44:07 -0000 Message-ID: <024401c21597$577c8ae0$c600a8c0@JAMESSONYVAIO> From: "James Seng" To: "Georg Ochsner" , References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <00aa01c214e1$4a24d480$c600a8c0@JAMESSONYVAIO> <002801c2150f$9f9aa4c0$b48dfea9@notebook> Subject: Re: [idn] When will IDNs go live? Date: Mon, 17 Jun 2002 08:38:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Georg, Thanks for your note, which I believe would strike a chord with many wg members. It is true that the group has taken far longer but the documents are now in the hand of the IESG waiting for publication. The best the group can do now on these documents is wait. -James Seng ----- Original Message ----- From: "Georg Ochsner" To: Sent: Sunday, June 16, 2002 4:27 PM Subject: [idn] When will IDNs go live? > Dear WG, > > I've been listening to you now since dec 2001. Besides all the interesting > technical aspects, I'd be very interested in the schedule now for launching > IDNs. Hundred thousands of people are actually waiting for your results and > have already spent money on IDNs. On the other side you do not seem to care > about time very much (at all?) ... > > In the meantime Verisign goes its own way again and has just extended the > registration period for IDNs for additional free 4 months and will bring out > a free ACE-plug-in for IE and outlook... > > My question is not technical but aiming on your project management. What is > the actual schedule? When will IDNs really go live? > > Thanks > Georg > > > From owner-idn@ops.ietf.org Sun Jun 16 22:59:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12138 for ; Sun, 16 Jun 2002 22:59:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JmUP-00005j-00 for idn-data@psg.com; Sun, 16 Jun 2002 19:43:33 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 17JmUM-00005W-00 for idn@ops.ietf.org; Sun, 16 Jun 2002 19:43:30 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/6q787f2tLy4n3KM2n0b8VA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G5GM8RG8; Sun, 16 Jun 2002 22:41:58 EDT To: georg@ochsner.de Cc: idn@ops.ietf.org Date: Sun, 16 Jun 2002 12:17:12 -0700 Subject: Re: [idn] When will IDNs go live? Message-ID: <20020616.194101.360.4.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-24,26-52 X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye X-Spam-Status: No, hits=1.9 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,FORGED_JUNO_RCVD version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Geora: Your waiting is only 6 months. It has been the concern for at least last 10 years in the CJK community. It is also the concern that many computer researchers in China have been debated and researched during the whole 1980's. The key of the words you may find mostly under the subject of "sorting of Chinese characters". If there is an easy answer to it, then we are only discussing another MIME. If you don't believe the complexity, you are wellcomed to joint the test run at realname.com or Verisign.com. Please follow Tedd's pointer. Liana Any comments about what VeriSign is doing? tedd On Sun, 16 Jun 2002 10:27:15 +0200 "Georg Ochsner" writes: > Dear WG, > > I've been listening to you now since dec 2001. Besides all the > interesting > technical aspects, I'd be very interested in the schedule now for > launching > IDNs. Hundred thousands of people are actually waiting for your > results and > have already spent money on IDNs. On the other side you do not seem > to care > about time very much (at all?) ... > > In the meantime Verisign goes its own way again and has just > extended the > registration period for IDNs for additional free 4 months and will > bring out > a free ACE-plug-in for IE and outlook... > > My question is not technical but aiming on your project management. > What is > the actual schedule? When will IDNs really go live? > > Thanks > Georg > > From owner-idn@ops.ietf.org Sun Jun 16 23:23:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12322 for ; Sun, 16 Jun 2002 23:23:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jn0w-0000gS-00 for idn-data@psg.com; Sun, 16 Jun 2002 20:17:10 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Jn0s-0000gG-00 for idn@ops.ietf.org; Sun, 16 Jun 2002 20:17:06 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA20800; Sun, 16 Jun 2002 20:21:14 -0700 Message-Id: <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 16 Jun 2002 19:03:05 -0400 To: "Soobok Lee" From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: In-Reply-To: <005a01c2158c$7978a670$2b19fea9@temp> References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:20 AM 6/17/2002 +0900, Soobok Lee wrote: >At least, IETF/ICANN/DoC could issue warnings, since they sit on the top >of the DNS hierarchy. >Proposing a half-baked or unimplementable soluion as standards does not >help, since >it will be abandoned and it will be classified as yet another proprietary >solution by industries >as long as everyone knows they are just quick fix for registries, not for >all the public. 1. You are entitled to your opinion. 2. The apparent IETF rough consensus differs from your opinion, markedly. 3. Why you believe the technology is unimplementable is a matter of some curiosity. 4, The design principles are very far from half-baked. In fact they are very well established, with extensive practical history that demonstrates their real, high utility. 5. Calling something from the IETF "proprietary" suggests that you also have a definition of proprietary that is at odds with standard industry nomenclature. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Mon Jun 17 00:55:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13313 for ; Mon, 17 Jun 2002 00:55:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JoOS-00024c-00 for idn-data@psg.com; Sun, 16 Jun 2002 21:45:32 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17JoOO-00023z-00 for idn@ops.ietf.org; Sun, 16 Jun 2002 21:45:28 -0700 Received: from MASTER ([211.196.254.39]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5H4jAA23447 for ; Mon, 17 Jun 2002 13:45:10 +0900 Message-ID: <00f701c215b9$b2b848f0$2b19fea9@temp> From: "Soobok Lee" To: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Mon, 17 Jun 2002 13:44:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > At 08:20 AM 6/17/2002 +0900, Soobok Lee wrote: > >At least, IETF/ICANN/DoC could issue warnings, since they sit on the top > >of the DNS hierarchy. > >Proposing a half-baked or unimplementable soluion as standards does not > >help, since > >it will be abandoned and it will be classified as yet another proprietary > >solution by industries > >as long as everyone knows they are just quick fix for registries, not for > >all the public. > > 1. You are entitled to your opinion. > > 2. The apparent IETF rough consensus differs from your opinion, markedly. > > 3. Why you believe the technology is unimplementable is a matter of some > curiosity. I18n without proper localization loses usability,interoperability and implementability. Proposed IDN standards are not adquate for any mission critical use. This argument may be extended to the IDN concept itself, but not up to the concept of micro-i18n-directory-layer above DNS, which can deal more easily with approximations ,heuristic suggestion and exception handlings about extended and open char sets. > > 4, The design principles are very far from half-baked. In fact they are > very well established, with extensive practical history that demonstrates > their real, high utility. I have been not talking about IDNA(ACE) principle, but, some advocates of UTF8-based solution would argue in that same way against ACE, because UTF8 use is well established and encouraged in numorous IETF standards. But,it's clear that even UTF8-based solutions will suffer from the same kind of l10n and implementability problems as those of IDNA. > > 5. Calling something from the IETF "proprietary" suggests that you also > have a definition of proprietary that is at odds with standard industry > nomenclature. > The application/OS industries and TLD registries will answer for it by actions. From owner-idn@ops.ietf.org Mon Jun 17 04:00:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24136 for ; Mon, 17 Jun 2002 04:00:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JrFC-00055s-00 for idn-data@psg.com; Mon, 17 Jun 2002 00:48:10 -0700 Received: from host-111.innovation.t1.primus.ca ([216.254.145.111] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17JrF8-00055g-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 00:48:07 -0700 Message-ID: <00e001c215d1$550786e0$0f01a8c0@neteka.inc> From: "Edmon Chung" To: "Georg Ochsner" , References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <00aa01c214e1$4a24d480$c600a8c0@JAMESSONYVAIO> <002801c2150f$9f9aa4c0$b48dfea9@notebook> Subject: Re: [idn] When will IDNs go live? Date: Mon, 17 Jun 2002 03:33:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Georg, This is a very interesting question you ask. You see, the real question is really when will registries be moving to transition towards IDNs. And the answer to that question "should" be now. The reality is that whatever IDNA states, there will be a lengthy period for transition. First we need to wait for the documents to be published (which is what we are doing now), then it is waiting for application providers (such as MSIE or NSCP) to adopt the standard in their next release of sofware, then we wait for them to become stable, then we need to wait for the propagation of the new versions in the market. And remember every single person on the internet must upgrade their application, and it is not just the browser, but also any application that uses domain names in any form. All in all, it means that if you want a meaningful percentage of internet users to be able to access IDNs you are looking at at least a handful of years. The answer for your concern is therefore in the transition. How do a registry provide a seamless transition that makes sense and create a positive user experience? We all know very well that users with existing applications will attempt to access a multilingual domain name and that these requests will reach the registry DNS server. Whether the registry decides to resolve the request or not is their choice. If the registry decides to resolve these request (even that it is not preformatted in ACE), then IDNs are live immediately. If not, they would most likely be inundated with customer support calls asking why the names dont work (such as observed by the VeriSign testbed). So, my point is, it is up to the registries really when they decide to address the issue. In fact .cn and .tw has been working very hard towards this and have successfully rolled out multilingual.cn and .tw names in their respective countries. So has .bz, .tv, .cc and .nu, all of the IDNs under these domains work already in varying degrees. And as the millions of users start to download or upgrade those new IDN aware applications, we will slowly but surely move towards a standard. But the key here is the transition and that can happen today. Edmon PS. I could provide you with a more extensive document outlining the issues and challenges for a domain registry and how to address them with the right technologies if you wish. cause this is probably not the best forum to just send an attachment into. ----- Original Message ----- From: "Georg Ochsner" To: Sent: Sunday, June 16, 2002 4:27 AM Subject: [idn] When will IDNs go live? > Dear WG, > > I've been listening to you now since dec 2001. Besides all the interesting > technical aspects, I'd be very interested in the schedule now for launching > IDNs. Hundred thousands of people are actually waiting for your results and > have already spent money on IDNs. On the other side you do not seem to care > about time very much (at all?) ... > > In the meantime Verisign goes its own way again and has just extended the > registration period for IDNs for additional free 4 months and will bring out > a free ACE-plug-in for IE and outlook... > > My question is not technical but aiming on your project management. What is > the actual schedule? When will IDNs really go live? > > Thanks > Georg > > > From owner-idn@ops.ietf.org Mon Jun 17 06:50:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25907 for ; Mon, 17 Jun 2002 06:50:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JtsD-00078p-00 for idn-data@psg.com; Mon, 17 Jun 2002 03:36:37 -0700 Received: from nod.reston.mci.net ([166.60.6.38]) by psg.com with esmtp (Exim 3.36 #1) id 17JtsA-00078d-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 03:36:34 -0700 Received: from vint.wcom.com ([67.209.200.233]) by shoe.reston.mci.net (PMDF V6.1-1 #39689) with ESMTPA id <01KJ10FRXJOC90N6TU@shoe.reston.mci.net> for idn@ops.ietf.org; Mon, 17 Jun 2002 06:36:32 -0500 (EST) Date: Mon, 17 Jun 2002 06:22:14 -0400 From: vint cerf Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) In-reply-to: <00f701c215b9$b2b848f0$2b19fea9@temp> X-Sender: vcerf@shoe.reston.mci.net To: Soobok Lee , idn@ops.ietf.org Message-id: <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT It seems to me that we err if we mix "finding" identifiers (with search engines, elaborate directories that offer multiple choices of IDNs based on imprecise search criteria) with resolving unambiguous identifiers into their respective IP addresses (speaking roughly since DNS also offers indirect resolutions such as MX, CNAME and so on). I think we do ourselves a disservice if we try to make DNS resolve ambiguous references - it is not designed for such applications; search engines and directory structures are more oriented towards that aspect of finding things "by name" on the Internet. Vint From owner-idn@ops.ietf.org Mon Jun 17 07:23:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26304 for ; Mon, 17 Jun 2002 07:23:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JuUw-0007ep-00 for idn-data@psg.com; Mon, 17 Jun 2002 04:16:38 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17JuUt-0007eb-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 04:16:36 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5HBGVlf021858; Mon, 17 Jun 2002 13:16:31 +0200 To: vint cerf Cc: Soobok Lee , idn@ops.ietf.org Subject: [idn] Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> From: Simon Josefsson Date: Mon, 17 Jun 2002 13:16:31 +0200 In-Reply-To: <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> (vint cerf's message of "Mon, 17 Jun 2002 06:22:14 -0400") Message-ID: Lines: 36 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk vint cerf writes: > It seems to me that we err if we mix "finding" identifiers > (with search engines, elaborate directories that offer multiple > choices of IDNs based on imprecise search criteria) with > resolving unambiguous identifiers into their respective IP addresses > (speaking roughly since DNS also offers indirect resolutions such as > MX, CNAME and so on). > > I think we do ourselves a disservice if we try to make DNS resolve > ambiguous references - it is not designed for such applications; > search engines and directory structures are more oriented towards > that aspect of finding things "by name" on the Internet. This seem to argue against the current design of IDNA. IDNA resolves some ambiguities in identifiers by Unicode normalization, and introduces further ambiguities by not handling legacy charset transcoding issues at all. Admittedly, "resolving ambiguities" in human entered text strings is a fuzzy area. One extreme is to not resolve any ambiguity at all, the other is to use as much intelligence in the software as possible to figure out what the user meant. Domain names in DNS traditionally was in the first extreme, IDNA move things slightly toward the other extreme with normalization and legacy transcoding, but far from approaching search engines or directories. Now, one can argue that Unicode normalization is only used because Unicode happens to have different ways of representing the same, or non-visual, characters, but nevertheless this adds an ambiguity resolving mechanism to software. One that will have to be modified over time, as well, since consensus on how to resolve ambiguities will change over time. I have trouble visualizing how this can be implemented and work well for 2, 5, 10 years and more, when Unicode and other charsets are moving targets. From owner-idn@ops.ietf.org Mon Jun 17 11:39:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08048 for ; Mon, 17 Jun 2002 11:39:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JyOu-000BeG-00 for idn-data@psg.com; Mon, 17 Jun 2002 08:26:40 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17JyOs-000Be0-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 08:26:38 -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 g5HFQZn11121 for ; Mon, 17 Jun 2002 08:26:35 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> Date: Mon, 17 Jun 2002 08:26:35 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 1:16 PM +0200 6/17/02, Simon Josefsson wrote: >vint cerf writes: > >> It seems to me that we err if we mix "finding" identifiers >> (with search engines, elaborate directories that offer multiple >> choices of IDNs based on imprecise search criteria) with >> resolving unambiguous identifiers into their respective IP addresses >> (speaking roughly since DNS also offers indirect resolutions such as >> MX, CNAME and so on). >> >> I think we do ourselves a disservice if we try to make DNS resolve >> ambiguous references - it is not designed for such applications; >> search engines and directory structures are more oriented towards >> that aspect of finding things "by name" on the Internet. > >This seem to argue against the current design of IDNA. > >IDNA resolves some ambiguities in identifiers by Unicode >normalization, and introduces further ambiguities by not handling >legacy charset transcoding issues at all. Simon, both of those statements are wrong, and Vint is right. Unicode normalization doesn't fix ambiguous references, it canonicalizes references: there is a huge difference between those two. "Letter A followed by combining umlaut" is not ambiguous: it means that the display should show an a with an umlaut over it. There are charset transcoders today that transcode differently from each other. That's not an ambiguity, that's a mistake. No one can create protocols that fix every previous mistake. >Now, one can argue that Unicode normalization is only used because >Unicode happens to have different ways of representing the same, or >non-visual, characters, but nevertheless this adds an ambiguity >resolving mechanism to software. One that will have to be modified >over time, as well, since consensus on how to resolve ambiguities will >change over time. I have trouble visualizing how this can be >implemented and work well for 2, 5, 10 years and more, when Unicode >and other charsets are moving targets. So your solution is that nothing can ever be internationalized? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jun 17 12:45:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10910 for ; Mon, 17 Jun 2002 12:45:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JzQP-000CrX-00 for idn-data@psg.com; Mon, 17 Jun 2002 09:32:17 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17JzQM-000CrJ-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 09:32:14 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5HGW9lf023895; Mon, 17 Jun 2002 18:32:10 +0200 To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: [idn] Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> From: Simon Josefsson Date: Mon, 17 Jun 2002 18:32:09 +0200 In-Reply-To: (Paul Hoffman / IMC's message of "Mon, 17 Jun 2002 08:26:35 -0700") Message-ID: Lines: 67 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Paul Hoffman / IMC writes: >>IDNA resolves some ambiguities in identifiers by Unicode >>normalization, and introduces further ambiguities by not handling >>legacy charset transcoding issues at all. > > Simon, both of those statements are wrong, and Vint is right. Unicode > normalization doesn't fix ambiguous references, it canonicalizes > references: there is a huge difference between those two. "Letter A > followed by combining umlaut" is not ambiguous: it means that the > display should show an a with an umlaut over it. If I see the (swedish) word "å" displayed on my screen, cut'n'paste it into a browser, an IDNA resolver will normalize this into U+00C5 before a server is queried for that string, regardless of whether the original string was U+00C5 or U+212B. Isn't this "resolving ambiguity"? Isn't there an ambiguity between U+00C5 and U+212B? If there isn't an ambiguity between U+00C5 and U+212B, why does IDNA treat them the same? Perhaps I fail to communicate, not being a native speaker perhaps I'm interpreting the word "ambiguous" incorrectly, although my dictionary doesn't seem to help me find any alternative interpretation. > There are charset transcoders today that transcode differently from > each other. That's not an ambiguity, that's a mistake. No one can > create protocols that fix every previous mistake. You can fix the one mistake. Building a critical infrastructure on past mistakes doesn't like a good idea to me. >>Now, one can argue that Unicode normalization is only used because >>Unicode happens to have different ways of representing the same, or >>non-visual, characters, but nevertheless this adds an ambiguity >>resolving mechanism to software. One that will have to be modified >>over time, as well, since consensus on how to resolve ambiguities will >>change over time. I have trouble visualizing how this can be >>implemented and work well for 2, 5, 10 years and more, when Unicode >>and other charsets are moving targets. > > So your solution is that nothing can ever be internationalized? That's not a solution, and that's not what I'm proposing, I don't understand how that could ever be read into what I wrote, but I'll try to be specific on how to solve the problems with IDNA right now, giving internationalized domain names that would be secure and could be implemented and continue to work years ahead: First, specify clearly that application MUST NOT use any other normalization table than the one defined in the IDNA spec suite (following Unicode 3.1 currently, being updated to Unicode 3.2 if I understand things correctly) and that in particular normalization tables supplied by operating systems should never be used unless the application author can assert that they will never change throughout the lifetime of the application (which probably only will be true if the application author is the operating system author). Secondly, define how to transcode legacy charsets into Unicode, and specify that only this transcoding table is to be used. Transcoding mapping tables can be defined in RFCs, much like MIME CTE's or similar. The initial IDNA spec suite could define transcoding tables for commonly used charsets; ISO-8859-X, ISO-2022-X, KOI8-X, KS-C-5601-X etc. The main argument against these proposals are that they require lots of work to implement, but if the alternative is poor security, I'd rather have people do lots of work. A lesser argument against it is that they don't adopt new updates to Unicode, but that is by design. From owner-idn@ops.ietf.org Mon Jun 17 13:35:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12856 for ; Mon, 17 Jun 2002 13:35:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K08C-000DqO-00 for idn-data@psg.com; Mon, 17 Jun 2002 10:17:32 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17K089-000DqD-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 10:17:29 -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 g5HHHOn16753; Mon, 17 Jun 2002 10:17:24 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> Date: Mon, 17 Jun 2002 10:16:56 -0700 To: Simon Josefsson From: Paul Hoffman / IMC Subject: [idn] Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: idn@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 6:32 PM +0200 6/17/02, Simon Josefsson wrote: >If I see the (swedish) word "å" displayed on my screen, cut'n'paste it >into a browser, an IDNA resolver will normalize this into U+00C5 >before a server is queried for that string, regardless of whether the >original string was U+00C5 or U+212B. Isn't this "resolving >ambiguity"? No, it is canonicalizing. In the bits on the wire, there is nothing ambiguous about the combined version or the uncombined version: they are very clearly different sets of characters, and the representation of those characters in every encoding of Unicode is also non-ambiguous. > Isn't there an ambiguity between U+00C5 and U+212B? Only visually, not in the protocol. > If >there isn't an ambiguity between U+00C5 and U+212B, why does IDNA >treat them the same? It doesn't. It canonicalizes one into the other. That is far from "treating them the same", yes? > Perhaps I fail to communicate, not being a >native speaker perhaps I'm interpreting the word "ambiguous" >incorrectly, although my dictionary doesn't seem to help me find any >alternative interpretation. My dictionary has these definitions: - having two or more possible meanings - doubtful, uncertain U+00C5 and U+212B do not have the same meaning, and there is nothing doubtful or uncertain about either of them. > > There are charset transcoders today that transcode differently from >> each other. That's not an ambiguity, that's a mistake. No one can >> create protocols that fix every previous mistake. > >You can fix the one mistake. Which one mistake is that? There are probably dozens of transcoders with errors, and worse yet, there are probably dozens of transcoder implemntors that, in the face of some IETF or Unicode standard that tells them how to transcode, would say "screw you, you don't understand our language" (and they would possibly be correct). > > So your solution is that nothing can ever be internationalized? > >That's not a solution, and that's not what I'm proposing, I don't >understand how that could ever be read into what I wrote, Because you said "I have trouble visualizing how this can be implemented and work well for 2, 5, 10 years and more, when Unicode and other charsets are moving targets." I agree with you that Unicode and other charsets are moving targets. > but I'll try >to be specific on how to solve the problems with IDNA right now, >giving internationalized domain names that would be secure and could >be implemented and continue to work years ahead: > >First, specify clearly that application MUST NOT use any other >normalization table than the one defined in the IDNA spec suite >(following Unicode 3.1 currently, being updated to Unicode 3.2 if I >understand things correctly) and that in particular normalization >tables supplied by operating systems should never be used unless the >application author can assert that they will never change throughout >the lifetime of the application (which probably only will be true if >the application author is the operating system author). We already say the first part (you must use the Unicode 3.1 -- soon to be Unicode 3.2 -- table). We don't say the second part because it flows from the first part. >Secondly, define how to transcode legacy charsets into Unicode, and >specify that only this transcoding table is to be used. Transcoding >mapping tables can be defined in RFCs, much like MIME CTE's or >similar. The initial IDNA spec suite could define transcoding tables >for commonly used charsets; ISO-8859-X, ISO-2022-X, KOI8-X, >KS-C-5601-X etc. Yes, we could do that, but the IETF lacks both the linguistic and political expertise to do it. The fact that even the experts such as ISO and the Unicode Consortium have not chosen to do this should be a very broad hint to you about why the IETF shouldn't. But if you really think this is needed (I still don't), you absolutely should ask the appropriate bodies (Unicode or ISO) to do it. If they do it, I'd bet that the IETF would strongly consider pointing to those standards. >The main argument against these proposals are that they require lots >of work to implement, but if the alternative is poor security, I'd >rather have people do lots of work. A lesser argument against it is >that they don't adopt new updates to Unicode, but that is by design. We disagree about what the main argument is. Creating transcoding tables is easy; in fact, it has already been done. See for some non-official mappings. My main argument against the IETF doing this is that being sure the tables are "right" is nearly impossible because it involves getting consensus among the users of the scripts and the experts. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jun 17 14:32:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15386 for ; Mon, 17 Jun 2002 14:32:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K14H-000F0Z-00 for idn-data@psg.com; Mon, 17 Jun 2002 11:17:33 -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 17K14A-000F0N-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 11:17:27 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5HIHLlf024584; Mon, 17 Jun 2002 20:17:22 +0200 To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Subject: [idn] Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> From: Simon Josefsson Date: Mon, 17 Jun 2002 20:17:22 +0200 In-Reply-To: (Paul Hoffman / IMC's message of "Mon, 17 Jun 2002 10:16:56 -0700") Message-ID: Lines: 163 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Paul Hoffman / IMC writes: > At 6:32 PM +0200 6/17/02, Simon Josefsson wrote: >>If I see the (swedish) word "å" displayed on my screen, cut'n'paste it >>into a browser, an IDNA resolver will normalize this into U+00C5 >>before a server is queried for that string, regardless of whether the >>original string was U+00C5 or U+212B. Isn't this "resolving >>ambiguity"? > > No, it is canonicalizing. In the bits on the wire, there is nothing > ambiguous about the combined version or the uncombined version: they > are very clearly different sets of characters, and the representation > of those characters in every encoding of Unicode is also non-ambiguous. Right. But isn't the _reason_ for canonicalizing that the characters are visually ambiguous? The canonicalization step isn't there for the fun of it, surely. If the reason for canonicalization isn't to resolve visual _ambiguity_, what is it there for? >> Isn't there an ambiguity between U+00C5 and U+212B? > > Only visually, not in the protocol. The IDNA "protocol" handles how the visual ambiguity is resolved, with the technique being canonicalization / normalization / decomposing. >> If >>there isn't an ambiguity between U+00C5 and U+212B, why does IDNA >>treat them the same? > > It doesn't. It canonicalizes one into the other. That is far from > "treating them the same", yes? Sorry, I don't see the difference. After IDNA processing, strings containing U+00C5 instead of U+212B look the same. There is no way at the server to tell whether the user entered U+00C5 or U+212B. There is no way to register two domains that only differs by the Unicode code point for "å" chosen. This is what I meant with IDNA treating them the same. Resolving ambiguity in this way can introduce ambiguity. Consider a user intentionally entering U+212B because it has a different meaning than U+00C5 attached to it in Unicode, IDNA resolves this into one code point. Unless the user knows the Unicode 3.2 decomposition table, it is uncertain to her whether those two code points are treated differently or not. >> Perhaps I fail to communicate, not being a >>native speaker perhaps I'm interpreting the word "ambiguous" >>incorrectly, although my dictionary doesn't seem to help me find any >>alternative interpretation. > > My dictionary has these definitions: > - having two or more possible meanings > - doubtful, uncertain > U+00C5 and U+212B do not have the same meaning, and there is nothing > doubtful or uncertain about either of them. If you look at the character "å" it can have at least two (Unicode) meanings, either U+00C5 or U+212B. This ambiguity is resolved in IDNA by normalization. To the user, whether "å" denotes U+00C5 or U+212B is "ambiguous". >> > There are charset transcoders today that transcode differently from >>> each other. That's not an ambiguity, that's a mistake. No one can >>> create protocols that fix every previous mistake. >> >>You can fix the one mistake. > > Which one mistake is that? There are probably dozens of transcoders > with errors, and worse yet, there are probably dozens of transcoder > implemntors that, in the face of some IETF or Unicode standard that > tells them how to transcode, would say "screw you, you don't > understand our language" (and they would possibly be correct). The mistake is that the transcoding tables are not specified somewhere, for IDNA purposes. If they tell us that, and is correct at telling us that, why not let them define the transcoding table? Sounds like maybe they will do a better job. If different people says that, you need to invite all of them to resolve their differences, or state that IDN will not work with charset X because people cannot agree. IMHO the end result will be better than (as is proposed now) leave those people alone to implement different transcoding tables. >> > So your solution is that nothing can ever be internationalized? >> >>That's not a solution, and that's not what I'm proposing, I don't >>understand how that could ever be read into what I wrote, > > Because you said "I have trouble visualizing how this can be > implemented and work well for 2, 5, 10 years and more, when Unicode > and other charsets are moving targets." I agree with you that Unicode > and other charsets are moving targets. "This" was referring to the current IDNA proposal. I'm convinced it is possible to implement internationalized domain names in a way that works. (In fact, I see IDN's on ads in buses and trains every other week or so, to doubt that it is impossible to implement would be foolish.) >> but I'll try >>to be specific on how to solve the problems with IDNA right now, >>giving internationalized domain names that would be secure and could >>be implemented and continue to work years ahead: >> >>First, specify clearly that application MUST NOT use any other >>normalization table than the one defined in the IDNA spec suite >>(following Unicode 3.1 currently, being updated to Unicode 3.2 if I >>understand things correctly) and that in particular normalization >>tables supplied by operating systems should never be used unless the >>application author can assert that they will never change throughout >>the lifetime of the application (which probably only will be true if >>the application author is the operating system author). > > We already say the first part (you must use the Unicode 3.1 -- soon to > be Unicode 3.2 -- table). We don't say the second part because it > flows from the first part. OK, perhaps it is sufficient. We'll see how people implement it. >>Secondly, define how to transcode legacy charsets into Unicode, and >>specify that only this transcoding table is to be used. Transcoding >>mapping tables can be defined in RFCs, much like MIME CTE's or >>similar. The initial IDNA spec suite could define transcoding tables >>for commonly used charsets; ISO-8859-X, ISO-2022-X, KOI8-X, >>KS-C-5601-X etc. > > Yes, we could do that, but the IETF lacks both the linguistic and > political expertise to do it. The fact that even the experts such as > ISO and the Unicode Consortium have not chosen to do this should be a > very broad hint to you about why the IETF shouldn't. But if you really > think this is needed (I still don't), you absolutely should ask the > appropriate bodies (Unicode or ISO) to do it. If they do it, I'd bet > that the IETF would strongly consider pointing to those standards. > >>The main argument against these proposals are that they require lots >>of work to implement, but if the alternative is poor security, I'd >>rather have people do lots of work. A lesser argument against it is >>that they don't adopt new updates to Unicode, but that is by design. > > We disagree about what the main argument is. Creating transcoding > tables is easy; in fact, it has already been done. See > for some non-official > mappings. > > My main argument against the IETF doing this is that being sure the > tables are "right" is nearly impossible because it involves getting > consensus among the users of the scripts and the experts. Perhaps we do agree, it was the consensus building I was referring to with the "require lots of work". Without solving transcoding issues, and if banks have the nerves of using non-ASCII IDN's for critical purposes, people will exploit these characteristics of IDNA. With the current proposal, I think banks will not chose to use IDN's because there are security concerns, which I consider a partial failure of IDN. I don't see much useful coming out of this discussion, and I'm not offering to talk with ISO or Unicode, so I'll stop whining for now. From owner-idn@ops.ietf.org Mon Jun 17 15:03:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16626 for ; Mon, 17 Jun 2002 15:03:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K1fi-000FlY-00 for idn-data@psg.com; Mon, 17 Jun 2002 11:56:14 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17K1ff-000FlL-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 11:56:11 -0700 Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5HIt19f006873; Mon, 17 Jun 2002 20:55:15 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 17 Jun 2002 20:19:24 +0200 Received: from [10.0.68.247] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 17 Jun 2002 17:36:34 +0200 Date: Mon, 17 Jun 2002 11:32:23 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Simon Josefsson , vint cerf cc: Soobok Lee , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <40912056.1024313543@localhost> In-Reply-To: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com> <5.1.0.14.2.20020616185947.022b0430@jay.songbird.com> <5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 17 Jun 2002 15:36:34.0874 (UTC) FILETIME=[C32209A0:01C21614] X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-06-17 13.16 +0200 Simon Josefsson wrote: > This seem to argue against the current design of IDNA. I don't agree. It is an example of IDNA solving the problem of using identifiers with non-ascii codepoints. IDNA does _not_ (and I think that has been clear all the time from us writing the spec) solve the problem with use of "words" with non-ascii codepoints. As Vint wrote, DNS is extremely bad at the functionality needed for word matching. Issues like locale dependent matching rules, ambigous result sets, more interactivity all are non-existing in the lookup system DNS defines. Regarding the "normalization for resolving ambiguities", I think we talk about different kind of ambiguities. In the case of normalization we only take care of the ambigous representations that, according to UTC, exists in the design of the Unicode Character Set. If you do word matching, you get different (often-locale-dependent) ambiguities, part from of course context-dependent ambiguities which exists because two very different things can be named exactly the same. paf From owner-idn@ops.ietf.org Mon Jun 17 20:33:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24319 for ; Mon, 17 Jun 2002 20:33:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K6mJ-000N5k-00 for idn-data@psg.com; Mon, 17 Jun 2002 17:23:23 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17K6mG-000N5W-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 17:23:21 -0700 Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5I0Mbef007322 for ; Tue, 18 Jun 2002 02:22:37 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 18 Jun 2002 02:23:19 +0200 Received: from [10.0.68.247] ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 18 Jun 2002 02:23:18 +0200 Date: Mon, 17 Jun 2002 20:04:12 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: idn@ops.ietf.org Subject: [idn] Liason statement from Unicode Consortium Message-ID: <42754677.1024344252@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 18 Jun 2002 00:23:18.0921 (UTC) FILETIME=[589CE790:01C2165E] X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have as liason in the IETF with the Unicode Consortium received the following text. Patrik The Unicode Consortium welcomes the progression of Stringprep and IDNA to last call. The development of those will have a significant impact on the majority of the people of the world, for the first time allowing them to have domain names in their own languages and scripts. There is only one issue for the consortium has a strong recommendation. The proposals are currently built on Unicode 3.1, since that was the latest version available during the initial development of IDNA and Stringprep. The consortium recommends that the version of Unicode be upgraded to Unicode 3.2, which was released on 2002-03-27 (For more information, see http://www.unicode.org/reports/tr28/.) This makes the first release of the standards encompass the broadest set of characters possible. It also means that a few small fixes in existing characters (between versions 3.1 and 3.2) can be accounted for. This should not delay the progress of the standards; the changes to the data tables are relatively minor. If this request cannot be accomodated, then the version should at least be updated to fix Corrigendum #3 (http://www.unicode.org/versions/enumeratedversions.html#Unicode_3_1_1_With _Corrigendum). This would address the most pressing concern, although not expand the character set to the most up-to-date version. From owner-idn@ops.ietf.org Mon Jun 17 21:30:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24902 for ; Mon, 17 Jun 2002 21:30:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K7Zk-000OUC-00 for idn-data@psg.com; Mon, 17 Jun 2002 18:14:28 -0700 Received: from [66.123.187.68] (helo=bean.ar.com) by psg.com with esmtp (Exim 3.36 #1) id 17K7Zh-000OU0-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 18:14:25 -0700 Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g5I1EA9m000278; Mon, 17 Jun 2002 18:14:10 -0700 (PDT) Date: Mon, 17 Jun 2002 18:14:16 -0700 (PDT) From: Rick Wesson X-X-Sender: To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Subject: Re: [idn] Liason statement from Unicode Consortium In-Reply-To: <42754677.1024344252@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT I'd prefer we move Stringprep and IDNA to use Unicode 3.2 now than wait until the next revision. -rick On Mon, 17 Jun 2002, Patrik Fältström wrote: > I have as liason in the IETF with the Unicode Consortium received the > following text. > > Patrik > > The Unicode Consortium welcomes the progression of Stringprep and IDNA to > last call. The development of those will have a significant impact on the > majority of the people of the world, for the first time allowing them to > have domain names in their own languages and scripts. > > There is only one issue for the consortium has a strong recommendation. The > proposals are currently built on Unicode 3.1, since that was the latest > version available during the initial development of IDNA and Stringprep. > The consortium recommends that the version of Unicode be upgraded to > Unicode 3.2, which was released on 2002-03-27 (For more information, see > http://www.unicode.org/reports/tr28/.) This makes the first release of the > standards encompass the broadest set of characters possible. It also means > that a few small fixes in existing characters (between versions 3.1 and > 3.2) can be accounted for. This should not delay the progress of the > standards; the changes to the data tables are relatively minor. > > If this request cannot be accomodated, then the version should at least be > updated to fix Corrigendum #3 > (http://www.unicode.org/versions/enumeratedversions.html#Unicode_3_1_1_With > _Corrigendum). This would address the most pressing concern, although not > expand the character set to the most up-to-date version. > > > > From owner-idn@ops.ietf.org Tue Jun 18 00:49:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28481 for ; Tue, 18 Jun 2002 00:49:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KAi2-0004QG-00 for idn-data@psg.com; Mon, 17 Jun 2002 21:35:14 -0700 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.36 #1) id 17KAhz-0004Q5-00 for idn@ops.ietf.org; Mon, 17 Jun 2002 21:35:12 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GXVWQG00.130; Tue, 18 Jun 2002 00:35:04 -0400 Message-ID: <002601c21681$2fa797e0$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: "Paul Hoffman / IMC" , "Simon Josefsson" Cc: References: <5.1.0.14.2.20020615133616.0236f8c8@jay.songbird.com><5.1.0.14.2.20020616185947.022b0430@jay.songbird.com><5.0.2.1.2.20020617061922.04817210@shoe.reston.mci.net> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Mon, 17 Jun 2002 21:32:36 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Simon Josefsson wrote: > Resolving ambiguity in this way can introduce ambiguity. Consider a > user intentionally entering U+212B because it has a different meaning > than U+00C5 attached to it in Unicode, IDNA resolves this into one > code point. Unless the user knows the Unicode 3.2 decomposition > table, it is uncertain to her whether those two code points are > treated differently or not. I don't see where the problem lies. Yes, U+00C5 and U+212B do look identical; the existence of pairs like this is the main reason why canonical equivalence tables exist. If you *could* have two separate domain names whose only difference was that one contained U+00C5 Ã… and the other contained U+212B â„«, now *that* could cause spoofing problems. > If you look at the character "Ã¥" it can have at least two (Unicode) > meanings, either U+00C5 or U+212B. This ambiguity is resolved in IDNA > by normalization. To the user, whether "Ã¥" denotes U+00C5 or U+212B > is "ambiguous". There aren't two meanings. Unicode considers them to be "canonically equivalent." They both exist in Unicode because somewhere, once upon a time, there was a legacy character set that included both, and Unicode wanted to provide round-trip mappings for both. That should be a clue that these "problems," if they are that, didn't originate with Unicode. > The mistake is that the transcoding tables are not specified > somewhere, for IDNA purposes. IDNA deals with Unicode. Transcoding between Unicode and other encodings is the responsibility of client-side software that does not natively deal with Unicode. > Without solving transcoding issues, and if banks have the nerves of > using non-ASCII IDN's for critical purposes, people will exploit these > characteristics of IDNA. With the current proposal, I think banks > will not chose to use IDN's because there are security concerns, which > I consider a partial failure of IDN. I have to agree with Paul. Neither the Unicode Technical Committee, nor ISO/IEC JTC1/SC2/WG2, nor anyone else can force vendors to adopt uniform mapping tables, or to mean the same thing when they say (for example) "Shift-JIS." Applications will continue to use transcoding routines supplied by the operating system, even if Unicode or IDNA were to publish "definitive" mapping tables. Transcoding between 80,000 legacy encodings is what we had to do before Unicode came along. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Tue Jun 18 06:03:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11265 for ; Tue, 18 Jun 2002 06:03:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KFUF-000Cuu-00 for idn-data@psg.com; Tue, 18 Jun 2002 02:41:19 -0700 Received: from mail.telia.se ([131.115.15.108] helo=maila.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17KFUC-000Cuh-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 02:41:16 -0700 Received: from maila.telia.se (localhost [127.0.0.1]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g5I9fEx10036 for ; Tue, 18 Jun 2002 11:41:14 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by maila.telia.se (8.11.6/8.11.6) with ESMTP id g5I9fAN09992 for ; Tue, 18 Jun 2002 11:41:10 +0200 (METDST) Message-ID: <3D0F0036.81D3D52A@trab.se> Date: Tue, 18 Jun 2002 11:41:10 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >I don't see where the problem lies. Yes, U+00C5 and U+212B do look >identical; the existence of pairs like this is the main reason why >canonical equivalence tables exist. They look identical because it is the same character. As Dough said they exist because a legacy encoding. Personally I think Unicode should never have allowed them to have more than one code point. While there is not doubt about the above, I am not sure that the nameprep specification that 00DF (small letter sharp s) should be matted to "ss". I am not sure how Germans handle this character. Do they always replace double s with it? Or only on some special words? If they do not generally do this, the mapping should not be done. It is somewhat like the fact that the Greek version of latin A is not mapped to the Roman version of latin A. Even though their origin is the same latin A and look alike. While "small letter sharp s" looks like "small letter beta", there are no similarities between double s and "small letter sharp s". So why not let "small letter sharp s" remain that and be a distinctive character in a domain name. I assume Germans use it to write German words. Not to replace double s in non-German names. Dan From owner-idn@ops.ietf.org Tue Jun 18 09:31:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16479 for ; Tue, 18 Jun 2002 09:31:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KIwM-000Jpf-00 for idn-data@psg.com; Tue, 18 Jun 2002 06:22:34 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17KIwI-000JpN-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 06:22:30 -0700 Received: (qmail 52468 invoked from network); 18 Jun 2002 13:27:28 -0000 Received: from bb-203-125-7-72.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.7.72) by sentosa.post1.com with SMTP; 18 Jun 2002 13:27:28 -0000 Message-ID: <00a701c216cb$250ebc10$c600a8c0@JAMESSONYVAIO> From: "James Seng" To: "Dan Oscarsson" , Cc: References: <3D0F0036.81D3D52A@trab.se> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Tue, 18 Jun 2002 21:22:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Whether DF should be decompose to "SS" or otherwise is defined in NFKC. Therefore, this question should be appropriately address in Unicode Consortium. -James Seng > While there is not doubt about the above, I am not sure that > the nameprep specification that 00DF (small letter sharp s) should > be matted to "ss". I am not sure how Germans handle this character. > Do they always replace double s with it? Or only on some special words? > If they do not generally do this, the mapping should not be done. > It is somewhat like the fact that the Greek version of latin A is > not mapped to the Roman version of latin A. Even though their origin > is the same latin A and look alike. > While "small letter sharp s" looks like "small letter beta", there are > no similarities between double s and "small letter sharp s". So why not > let "small letter sharp s" remain that and be a distinctive character > in a domain name. I assume Germans use it to write German words. Not > to replace double s in non-German names. > > Dan > > From owner-idn@ops.ietf.org Tue Jun 18 09:47:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17297 for ; Tue, 18 Jun 2002 09:47:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KJEv-000KVO-00 for idn-data@psg.com; Tue, 18 Jun 2002 06:41:45 -0700 Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17KJEs-000KV8-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 06:41:42 -0700 Received: from mailc.telia.se (localhost [127.0.0.1]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g5IDfdk29987 for ; Tue, 18 Jun 2002 15:41:39 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g5IDfaD29939; Tue, 18 Jun 2002 15:41:36 +0200 (METDST) Message-ID: <3D0F3890.7586E39C@trab.se> Date: Tue, 18 Jun 2002 15:41:36 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org, jseng@pobox.org.sg Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: > >Whether DF should be decompose to "SS" or otherwise is defined in NFKC. >Therefore, this question should be appropriately address in Unicode >Consortium. It is not decomposed in NFKC, from what I can see. It is in the special, multi character case folding file. Though as it is already a "small letter sharp s" I cannot understand how one can lower case it once more. It is already lower case. > >> While there is not doubt about the above, I am not sure that >> the nameprep specification that 00DF (small letter sharp s) should >> be matted to "ss". I am not sure how Germans handle this character. >> Do they always replace double s with it? Or only on some special words? >> If they do not generally do this, the mapping should not be done. >> It is somewhat like the fact that the Greek version of latin A is >> not mapped to the Roman version of latin A. Even though their origin >> is the same latin A and look alike. >> While "small letter sharp s" looks like "small letter beta", there are >> no similarities between double s and "small letter sharp s". So why not >> let "small letter sharp s" remain that and be a distinctive character >> in a domain name. I assume Germans use it to write German words. Not >> to replace double s in non-German names. >> Dan From owner-idn@ops.ietf.org Tue Jun 18 10:30:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19308 for ; Tue, 18 Jun 2002 10:30:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KJlL-000Lec-00 for idn-data@psg.com; Tue, 18 Jun 2002 07:15:15 -0700 Received: from [151.99.229.67] (helo=pmsv0001.saritel.it) by psg.com with esmtp (Exim 3.36 #1) id 17KJlI-000LeP-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 07:15:12 -0700 Received: from butch.pm.saritel.it ([172.16.20.127]) by pmsv0001.saritel.it with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 16:19:19 +0200 Received: by butch.pm.saritel.it with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 16:08:08 +0200 Message-ID: <013D3552A4BCD411AF6000508BDE8DEC712F4D@misv0002.mi.saritel.it> From: Codogno Maurizio To: "'idn@ops.ietf.org'" Subject: [idn] =?iso-8859-1?Q?eszet_=28ss=2C_sz=2C_=DF=2C_call_it_whatever_yo?= =?iso-8859-1?Q?u_want=29?= Date: Tue, 18 Jun 2002 16:01:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Jun 2002 14:19:19.0296 (UTC) FILETIME=[2286B800:01C216D3] X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19308 AFAIK, in German there are some specific cases in which you have to use ß instead of ss. Needless to say, it was not the same throughout Germandom: in Switzerland, the character is not used. The writing reform happened some years ago changed again things, reducing the number of cases in which ß has to be used. Moreover, there is no uppercase form: you have to write SS. In short, a mess :-) > I assume Germans use it to write German words. Not > to replace double s in non-German names. Yes, but we could have a mixed-language domain name: what about paß-per-tutti.it ? ciao, .mau. From owner-idn@ops.ietf.org Tue Jun 18 10:30:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19321 for ; Tue, 18 Jun 2002 10:30:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KJko-000Lbu-00 for idn-data@psg.com; Tue, 18 Jun 2002 07:14:42 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17KJkk-000Lbj-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 07:14:38 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17KJjQ-000Mhn-00; Tue, 18 Jun 2002 14:13:16 +0000 Date: Tue, 18 Jun 2002 10:12:59 -0400 From: John C Klensin To: Dan Oscarsson , idn@ops.ietf.org Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Message-ID: <80396120.1024395179@localhost> In-Reply-To: <3D0F0036.81D3D52A@trab.se> References: <3D0F0036.81D3D52A@trab.se> X-Mailer: Mulberry/3.0.0a2 (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.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 18 June, 2002 11:41 +0200 Dan Oscarsson wrote: > While there is not doubt about the above, I am not sure that > the nameprep specification that 00DF (small letter sharp s) > should be matted to "ss". I am not sure how Germans handle > this character. Do they always replace double s with it? Or > only on some special words? If they do not generally do this, > the mapping should not be done. It is somewhat like the fact > that the Greek version of latin A is not mapped to the Roman > version of latin A. Even though their origin is the same latin > A and look alike. This was discussed at length early in the history of the WG. By convention, it is always possible to replace Eszett with "ss", and the upper-case form of Eszett is always "SS", but there are many words in which "ss" appears for which a substitution back to Eszett is not appropriate. In other words, this is a one-way, non-reversible (without word-context), mapping. The good news is that, stringprep gets it right (or at least consistent with other WG decisions) given coding as 0x00DF, which clearly identifies the character as Eszett. The bad news is that, if this character [form] is observed in a written string, or a non-Unicode coding system that does not distinguish between Eszett and "small letter [Greek] beta", one really needs to have language context in order to determine which Unicode character to map it to, especially because, given stringprep, the consequences of getting it wrong are likely to be very significant. But this is not new news, or even a new example. We may see it differently as our sensitivities to the issues evolve, but the bottom line is that Unicode is not especially well adapted to coding of strings that appear without language, or even word, contexts in non-Unicode form. Whether that form is a pre-existing coding system, or a sign on the side of a bus, there are likely to be examples of problematic characters. Unfortunately, there are no standardized alternatives for a UCS with even near-global applicability. And it appears obvious to me that, while a hypothetical Unicode alternative could make different choices, it wouldn't eliminate these problems, but rather just create a different set of scary examples. I think there are only two ways out of this, and neither involves either changes in stringprep or more examples of this type. For the latter, I think almost everyone with a strong desire to understand the problem has done so and that the odds of convincing others are fairly low. The alternatives are: (1) To define the problem this working group is trying to solve in a way that causes these problems to be non-issues. Personally, every time I try to do that, I end up with what feel to me to be silly states, but it is clear that I'm in the minority of those speaking up in the WG. For example, one could say, and I think we essentially have, that the WG is solving the problem of getting things into and out of the DNS given that the Unicode coding form is accurately known. This implies that any applications which can't succeed in making the translations are going to be in very bad trouble and that we offer them no help or hope -- it isn't our problem. Personally, I think that, if the WG's position and recommendations are based on that model, we should be obligated to write it down and make it explicit in our documents before they go onto the standards track: we owe that much to those who think we are solving any of a number of more general internationalization problems. (2) To just give it up. The DNS effectively imposes "no language information" and "no script information" restrictions on us. Its octet-based comparison rules effectively prevent us from imposing conventions that would permit guessing anything from context, nor can we prohibit a string that contains 0x00DF in the middle of a string of Greek, or for that matter Arabic, characters. In the Arabic case, it would at least stand out as strange; in the Greek one, humans would almost certainly mistake it, in displayed form, for lower-case beta. Given the restrictions, these presentation-relationship problems have no in-DNS solution. My own personal position on this is presumably well-known at this point: we have tried very hard to solve a "DNS internationalizaiton" problem and have ended up with a number of extremely convincing demonstrations (this example not least among them) that it is overconstrained and can't be solved. If one accepts that, then there is a strong case for saying "sorry, whatever it is people wish for, and can make work in restricted contexts, DNS labels for common, existing, RRs and applications are limited to ASCII-based protocol elements and we had best go solve the real problem and requirement in some less-constrained environment". While others clearly disagree (and are probably the majority), I also don't believe it is appropriate for IETF to adopt a protocol without clear evidence that it can be implemented and used by at least a few of the applications that are anticipated for it -- applications that need to deal with presentation forms, operating systems, and other aspects of the real world. But, again, if we are going to do it, or if we see some restricted applications for which this _does_ provide a useful part of a solution, I believe that we are obligated to explain exactly what problem we are solving, so as to not inadvertently surprise implementors and users with scenarios and problems that we understand. If we didn't know about these problems, it might be different, but we certainly do. But I do think those are the issues that the WG (and really, at this stage, the IESG) should be discussing. And, if there are new issues, I, at least, would like to understand them. But more examples or transcription or transcoding difficulties won't, I think, help: we already have enough examples to kill a dozen protocols if the WGs considered them relevant. More examples, or repeating of older ones, would not persuade anyone who is convinced that the ones documented so far are not relevant that they are suddenly relevant. Just my opinion. john john From owner-idn@ops.ietf.org Tue Jun 18 11:15:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22012 for ; Tue, 18 Jun 2002 11:15:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KKWl-000NTS-00 for idn-data@psg.com; Tue, 18 Jun 2002 08:04:15 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #1) id 17KKWh-000NTG-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 08:04:11 -0700 Received: (qmail 49279 invoked from network); 18 Jun 2002 15:04:08 -0000 Received: from 12-234-208-57.client.attbi.com (HELO c1340594a) (12.234.208.57) by relay1.pair.com with SMTP; 18 Jun 2002 15:04:08 -0000 X-pair-Authenticated: 12.234.208.57 Message-ID: <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> From: "Mark Davis" To: "John C Klensin" , "Dan Oscarsson" , References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Tue, 18 Jun 2002 08:05:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > The bad news is that, if this character [form] is observed in a > written string, or a non-Unicode coding system that does not > distinguish between Eszett and "small letter [Greek] beta", one > really needs to have language context in order to determine > which Unicode character to map it to, especially because, given > stringprep, the consequences of getting it wrong are likely to > be very significant. A few items here. 1. While there are many Unicode characters with very similar shapes, beta and eszed -- in normal fonts -- are really no more alike than y and gamma (or, for that matter, capital I, lowercase L, and 1!!). Beta typically has a descender, while eszed does not. See http://www.macchiato.com/unicode/beta-eszed.htm for a GIF image from three fonts. 2. There are no "non-Unicode coding systems" that unify beta and eszed; the language issue is irrelevant. 3. As I pointed out some time ago on this list, it is *not* rocket science to provide a user interface that makes it very clear to people if there are mixed scripts in a domain name; and also simple to extend it to other confusables. For a demo, see http://www.macchiato.com/utc/show_script.html. I have recommended and continue to recommend that the IDNA documents contain some wording on this, something like: "To help prevent confusion between characters that are visually similar, it is recommended 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 characters, or to distinguish zero and one from O and l." Mark __________ http://www.macchiato.com â—„ “Eppur si muove†► ----- Original Message ----- From: "John C Klensin" To: "Dan Oscarsson" ; Sent: Tuesday, June 18, 2002 07:12 Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? > --On Tuesday, 18 June, 2002 11:41 +0200 Dan Oscarsson > wrote: > > > While there is not doubt about the above, I am not sure that > > the nameprep specification that 00DF (small letter sharp s) > > should be matted to "ss". I am not sure how Germans handle > > this character. Do they always replace double s with it? Or > > only on some special words? If they do not generally do this, > > the mapping should not be done. It is somewhat like the fact > > that the Greek version of latin A is not mapped to the Roman > > version of latin A. Even though their origin is the same latin > > A and look alike. > > This was discussed at length early in the history of the WG. By > convention, it is always possible to replace Eszett with "ss", > and the upper-case form of Eszett is always "SS", but there are > many words in which "ss" appears for which a substitution back > to Eszett is not appropriate. In other words, this is a > one-way, non-reversible (without word-context), mapping. The > good news is that, stringprep gets it right (or at least > consistent with other WG decisions) given coding as 0x00DF, > which clearly identifies the character as Eszett. > > The bad news is that, if this character [form] is observed in a > written string, or a non-Unicode coding system that does not > distinguish between Eszett and "small letter [Greek] beta", one > really needs to have language context in order to determine > which Unicode character to map it to, especially because, given > stringprep, the consequences of getting it wrong are likely to > be very significant. > > But this is not new news, or even a new example. We may see it > differently as our sensitivities to the issues evolve, but the > bottom line is that Unicode is not especially well adapted to > coding of strings that appear without language, or even word, > contexts in non-Unicode form. Whether that form is a > pre-existing coding system, or a sign on the side of a bus, > there are likely to be examples of problematic characters. > Unfortunately, there are no standardized alternatives for a UCS > with even near-global applicability. And it appears obvious to > me that, while a hypothetical Unicode alternative could make > different choices, it wouldn't eliminate these problems, but > rather just create a different set of scary examples. > > I think there are only two ways out of this, and neither > involves either changes in stringprep or more examples of this > type. For the latter, I think almost everyone with a strong > desire to understand the problem has done so and that the odds > of convincing others are fairly low. > > The alternatives are: > > (1) To define the problem this working group is trying to solve > in a way that causes these problems to be non-issues. > Personally, every time I try to do that, I end up with what feel > to me to be silly states, but it is clear that I'm in the > minority of those speaking up in the WG. For example, one could > say, and I think we essentially have, that the WG is solving the > problem of getting things into and out of the DNS given that the > Unicode coding form is accurately known. This implies that any > applications which can't succeed in making the translations are > going to be in very bad trouble and that we offer them no help > or hope -- it isn't our problem. Personally, I think that, if > the WG's position and recommendations are based on that model, > we should be obligated to write it down and make it explicit in > our documents before they go onto the standards track: we owe > that much to those who think we are solving any of a number of > more general internationalization problems. > > (2) To just give it up. The DNS effectively imposes "no > language information" and "no script information" restrictions > on us. Its octet-based comparison rules effectively prevent us > from imposing conventions that would permit guessing anything > from context, nor can we prohibit a string that contains 0x00DF > in the middle of a string of Greek, or for that matter Arabic, > characters. In the Arabic case, it would at least stand out as > strange; in the Greek one, humans would almost certainly mistake > it, in displayed form, for lower-case beta. Given the > restrictions, these presentation-relationship problems have no > in-DNS solution. > > My own personal position on this is presumably well-known at > this point: we have tried very hard to solve a "DNS > internationalizaiton" problem and have ended up with a number of > extremely convincing demonstrations (this example not least > among them) that it is overconstrained and can't be solved. If > one accepts that, then there is a strong case for saying "sorry, > whatever it is people wish for, and can make work in restricted > contexts, DNS labels for common, existing, RRs and applications > are limited to ASCII-based protocol elements and we had best go > solve the real problem and requirement in some less-constrained > environment". > > > While others clearly disagree (and are probably the majority), I > also don't believe it is appropriate for IETF to adopt a > protocol without clear evidence that it can be implemented and > used by at least a few of the applications that are anticipated > for it -- applications that need to deal with presentation > forms, operating systems, and other aspects of the real world. > But, again, if we are going to do it, or if we see some > restricted applications for which this _does_ provide a useful > part of a solution, I believe that we are obligated to explain > exactly what problem we are solving, so as to not inadvertently > surprise implementors and users with scenarios and problems that > we understand. If we didn't know about these problems, it might > be different, but we certainly do. > > But I do think those are the issues that the WG (and really, at > this stage, the IESG) should be discussing. And, if there are > new issues, I, at least, would like to understand them. But > more examples or transcription or transcoding difficulties > won't, I think, help: we already have enough examples to kill a > dozen protocols if the WGs considered them relevant. More > examples, or repeating of older ones, would not persuade anyone > who is convinced that the ones documented so far are not > relevant that they are suddenly relevant. > > Just my opinion. > > john > > > john > > > From owner-idn@ops.ietf.org Tue Jun 18 12:23:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25409 for ; Tue, 18 Jun 2002 12:23:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KLWk-000Ov3-00 for idn-data@psg.com; Tue, 18 Jun 2002 09:08:18 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17KLWg-000Oui-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 09:08:14 -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 g5IG8Bn03981 for ; Tue, 18 Jun 2002 09:08:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3D0F0036.81D3D52A@trab.se> References: <3D0F0036.81D3D52A@trab.se> Date: Tue, 18 Jun 2002 09:05:04 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:41 AM +0200 6/18/02, Dan Oscarsson wrote: >They look identical because it is the same character. That definition of "same" doesn't match the definition that the rest of us are using. They have different code points, they have different names, and they have different Unicode properties. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jun 18 13:21:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27169 for ; Tue, 18 Jun 2002 13:20:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KMO5-00004p-00 for idn-data@psg.com; Tue, 18 Jun 2002 10:03:25 -0700 Received: from smtprelay1.dc3.adelphia.net ([24.50.78.4]) by psg.com with esmtp (Exim 3.36 #1) id 17KMO1-00004Y-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 10:03:22 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay1.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GXWVDK00.F67; Tue, 18 Jun 2002 13:03:21 -0400 Message-ID: <009401c216e9$beeba320$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Paul Hoffman / IMC" References: <3D0F0036.81D3D52A@trab.se> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Tue, 18 Jun 2002 10:01:09 -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=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Paul Hoffman / IMC" wrote: >> They [U+00C5 and U+212B] look identical because it is the same >> character. > > That definition of "same" doesn't match the definition that the > rest of us are using. They have different code points, they have > different names, and they have different Unicode properties. Same Unicode properties -- "Lu", meaning "Letter, Uppercase." Of course, by itself that hardly makes them the same character -- "A" and "B" are also classified as Lu. I'm not sure how productive it's going to be to argue whether two characters or sequences constitute "the same character." You can go either way in some cases (what about U+00C5 vs. U+0041 U+030A?). Simon Josefsson has been trying to show that, because U+00C5 and U+212B are "different" characters but look the same, and because stringprep folds them together, there is therefore "ambiguity" and security loopholes are introduced. (I still think it's the other way around; leaving them separate is what would invite spoofing.) Because of this line of argument, some of us have stated that U+00C5 and U+212B aren't completely different because of canonical equivalence. But of course they're not completely the same, either. This might be sort of a "dancing angels" debate that generates no light, but perhaps a lot of heat. In any case, hasn't the broad question of canonical folding been settled for a long time now? I'm really starting to sympathize with Georg Ochsner, who asked when on earth this project would finally be completed. I have heard very few new arguments in the past six months, but a great deal of rehashing of old issues (like this one) that I thought had already been resolved. Georg is right -- at this rate, nobody will stick around to wait for the IETF solution, but will go with whatever Verisign slaps together (probably with a lot less consensus building that this WG) and that will become the de-facto standard. Do we want that? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Tue Jun 18 14:16:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29211 for ; Tue, 18 Jun 2002 14:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KN8q-0000ys-00 for idn-data@psg.com; Tue, 18 Jun 2002 10:51:44 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17KN8m-0000ye-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 10:51:40 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17KN8g-000NCd-00; Tue, 18 Jun 2002 17:51:34 +0000 Date: Tue, 18 Jun 2002 13:51:33 -0400 From: John C Klensin To: Mark Davis cc: idn@ops.ietf.org Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Message-ID: <93512505.1024408293@localhost> In-Reply-To: <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> X-Mailer: Mulberry/3.0.0a2 (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.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 18 June, 2002 08:05 -0700 Mark Davis wrote: >> The bad news is that, if this character [form] is observed in >> a written string, or a non-Unicode coding system that does not >> distinguish between Eszett and "small letter [Greek] beta", >> one really needs to have language context in order to >> determine which Unicode character to map it to, especially >> because, given stringprep, the consequences of getting it >> wrong are likely to be very significant. > > A few items here. > > 1. While there are many Unicode characters with very similar > shapes, beta and eszed -- in normal fonts -- are really no > more alike than y and gamma (or, for that matter, capital I, > lowercase L, and 1!!). Beta typically has a descender, while > eszed does not. See > http://www.macchiato.com/unicode/beta-eszed.htm for a GIF > image from three fonts. As you, and I, and others, have noted in the past, there are far better examples than beta and eszett (or eszed if you prefer). But there are certainly fonts (which I assume you would classify as "not normal") -- designed in isolation for the two languages -- whose interpretations of the two characters, if placed in text of the other language, would not catch the eye of a casual reader as being out of place. And I would assume that, in the long history of manual typesetting, there have been instances of Eszett being substituted for beta (probably in German texts containing mathematics because a lazy typesetter was disinclined to walk across to a different font). None of this, of course, challenges your fundamental argument, with which I agree and hope I was careful enough to write my note to not challenge. > 2. There are no "non-Unicode coding systems" that unify beta > and eszed; the language issue is irrelevant. Sure there are. We call some of them "books". Transcription of a language into printed form involves a coding system. And I have to assume, although I can claim no personal knowledge, that German schoolchildren, brought up looking at Eszett, have to be taught, when they encounter mathematical notation that uses Greek characters (if not sooner), that it is important to notice either the context or the descender -- that the two characters are not the same. These distinctions, including getting used to the variations and similarities in different fonts of I-l-1, are bits of pattern recogition that lay people --as distinct from font or character set experts-- rapidly learn, within their own language and script contexts, to distinguish from context or by relatively subtle clues. I can't even spell out Arabic or Thai scripts because I don't have enough experience with the right set of clues -- my loss, but these are learned skills. But this isn't the point, so whether there are, or are not, coded character sets that unify the two is not the point either (I'll defer to your knowledge and experience on this subject, since I haven't studied the question, but statements that sound like universal negatives always scare me). Your third comment _is_ as key part of the point. > 3. As I pointed out some time ago on this list, it is *not* > rocket science to provide a user interface that makes it very > clear to people if there are mixed scripts in a domain name; > and also simple to extend it to other confusables. For a demo, > see > http://www.macchiato.com/utc/show_script.html. > > I have recommended and continue to recommend that the IDNA > documents contain some wording on this, something like: > > "To help prevent confusion between characters that are visually > similar, it is recommended 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 characters, or to > distinguish zero and one from O and l." Mark, I ultimately have only three problems with IDNA and the IDN proposals taken as a group. The first is a technical one and applies to IDNA specifically. The others are problems that would probably extend to any in-DNS substitute): (i) It makes assertions about applicability that I believe are over-broad and risky, to no good benefit. I think we are nearing consensus on that one and, in any event, that reviewing it again wouldn't accomplish much. (ii) It is addressed to, and solves, a very narrow problem. We (for some definition of "we") have not been explicit, in an Internet context, as to what that problem is. I believe that we should be explicit. Then, having carefully described that problem, we then need to carefully evaluate the question of whether the benefits of solving it outweigh the risks to the use of the DNS in the Internet community that it might pose. If we conclude that we can't reasonably do that evaluation (e.g., because it isn't an IETF problem), then I think we are still obligated to delineate the issues and risks to the best of our ability -- at least to the extent of writing down the implications of problems and issues we already know about. (iii) A number of items of knowledge and recommendations have surfaced in the working group -- of which your suggestion above is an excellent example -- that could be used to reduce or eliminate some of those risks to the DNS as a piece of usable Internet infrastructure. I think they need to be written down as part of WG output, if only because "this risk can be ameliorated if one does so-and-so" is a much more satisfactory statement than "there is this horrible problem and we should consider stopping progress until someone has a solution". Of course, if "mixed scripts in domain names" are considered good things, warning when they occur won't help much. But _that_ one, I would contend, is not an IETF problem although I think it would be wise and responsible for us to point out that mixed script labels pose challenges that homogeneous ones do not. regards, john From owner-idn@ops.ietf.org Tue Jun 18 17:42:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05989 for ; Tue, 18 Jun 2002 17:42:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KQYJ-00054n-00 for idn-data@psg.com; Tue, 18 Jun 2002 14:30:15 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17KQYF-00054Y-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 14:30:11 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17KQYF-0008Sb-00 for ; Tue, 18 Jun 2002 14:30:11 -0700 Date: Tue, 18 Jun 2002 21:30:11 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Message-ID: <20020618213010.GC31821@nicemice.net> Reply-To: IETF idn working group References: <3D0F0036.81D3D52A@trab.se> <009401c216e9$beeba320$fa424244@anhmca.adelphia.net> <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009401c216e9$beeba320$fa424244@anhmca.adelphia.net> <80396120.1024395179@localhost> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk I don't understand why there is all fuss concerning the various folding that Nameprep performs. The Unicode standard says that two canonically equivalent strings should be treated the same (either one should work in any place that the other works). IDNA is simply honoring that recommendation. If it didn't normalize strings before encoding them or comparing them, then canonically equivalent strings wouldn't get treated the same. Canonical equivalence deals with things like "a with grave" versus "a" followed by "combining grave". The Unicode standard also defines compatible equivalence, and says that compatibility characters are characters that didn't really deserve their own code points, but were reluctantly given their own code points for the sole purpose of preserving round-trip conversions to legacy charsets. Nameprep respects this reluctance by using NFKC rather than NFC, so that the compatibility characters are folded into their equivalents. The Unicode standard also defines a locale-independent case folding algorithm explicitly intended for doing case-insensitive comparisons, which is exactly what IDNA needs it for. German sharp s is folded to ss because a case-insensitive comparison must match German sharp s with SS (the latter is the normal uppercase form of the former), and must match SS with ss (the latter is the normal lowercase form of the former), and so by transitivity it must match German sharp s with ss. John C Klensin wrote: > For example, one could say, and I think we essentially have, that the > WG is solving the problem of getting things into and out of the DNS > given that the Unicode coding form is accurately known. Yes (but not just DNS, all existing protocols that use domain names). > if the WG's position and recommendations are based on that model, > we should be obligated to write it down and make it explicit in our > documents before they go onto the standards track: we owe that much > to those who think we are solving any of a number of more general > internationalization problems. Suggested text addressing that concern was posted to the list a few weeks ago, see message . AMC From owner-idn@ops.ietf.org Tue Jun 18 18:06:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06457 for ; Tue, 18 Jun 2002 18:06:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KR2D-0005jN-00 for idn-data@psg.com; Tue, 18 Jun 2002 15:01:09 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #1) id 17KR2A-0005jB-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 15:01:06 -0700 Received: (qmail 50399 invoked from network); 18 Jun 2002 22:01:00 -0000 Received: from 12-234-208-57.client.attbi.com (HELO c1340594a) (12.234.208.57) by relay1.pair.com with SMTP; 18 Jun 2002 22:01:00 -0000 X-pair-Authenticated: 12.234.208.57 Message-ID: <001601c21713$d16d3d90$8900a8c0@c1340594a> From: "Mark Davis" To: "John C Klensin" Cc: References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> <93512505.1024408293@localhost> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Tue, 18 Jun 2002 15:02:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > 2. There are no "non-Unicode coding systems" that unify beta > > and eszed; the language issue is irrelevant. > > Sure there are. We call some of them "books". Transcription of > a language into printed form involves a coding system. And I > have to assume, although I can claim no personal knowledge, that > German schoolchildren, brought up looking at Eszett, have to be > taught, when they encounter mathematical notation that uses > Greek characters (if not sooner), that it is important to notice > either the context or the descender -- that the two characters > are not the same. My point was that they probably have about the same level of confusion that you had when you first saw a gamma as a schoolchild and confused it with a y. > These distinctions, including getting used to > the variations and similarities in different fonts of I-l-1, are > bits of pattern recogition that lay people --as distinct from > font or character set experts-- rapidly learn, within their own > language and script contexts, to distinguish from context or by > relatively subtle clues. I can't even spell out Arabic or Thai > scripts because I don't have enough experience with the right > set of clues -- my loss, but these are learned skills. True > > But this isn't the point, so whether there are, or are not, > coded character sets that unify the two is not the point either > (I'll defer to your knowledge and experience on this subject, > since I haven't studied the question, but statements that sound > like universal negatives always scare me). Let me qualify my negative: I have never heard of any that do, and of the 750 odd code page mapping tables that we have collected on major platforms (http://oss.software.ibm.com/cvs/icu/charset/data/xml/), none of them do. Of course, if you go down to Arkansas Bob's "Bait, Tackle, and Character Encodings Shack", he can whip up a nice character set in no time flat that'll unify them. You should understand my phrase 'no "non-Unicode coding systems"' as meaning 'no "non-Unicode coding systems" of any importance or impact', and I'll now understand your phrase "non-Unicode coding systems" as meaning "books" ;-) .. > (ii) It is addressed to, and solves, a very narrow problem. We > (for some definition of "we") have not been explicit, in an > Internet context, as to what that problem is. I believe that we > should be explicit. Then, having carefully described that > problem, we then need to carefully evaluate the question of > whether the benefits of solving it outweigh the risks to the use > of the DNS in the Internet community that it might pose. If we > conclude that we can't reasonably do that evaluation (e.g., > because it isn't an IETF problem), then I think we are still > obligated to delineate the issues and risks to the best of our > ability -- at least to the extent of writing down the > implications of problems and issues we already know about. > > (iii) A number of items of knowledge and recommendations have > surfaced in the working group -- of which your suggestion above > is an excellent example -- that could be used to reduce or > eliminate some of those risks to the DNS as a piece of usable > Internet infrastructure. I think they need to be written down > as part of WG output, if only because "this risk can be > ameliorated if one does so-and-so" is a much more satisfactory > statement than "there is this horrible problem and we should > consider stopping progress until someone has a solution". I agree that in both of these cases capturing additional information as guidelines for dealing with particular issues would be very helpful. > Of course, if "mixed scripts in domain names" are considered > good things, warning when they occur won't help much. But > _that_ one, I would contend, is not an IETF problem although I > think it would be wise and responsible for us to point out that > mixed script labels pose challenges that homogeneous ones do not. I agree. Such UI's would certainly alert people to something very fishy going on in the case of "Intel.com" spelled with a Cyrillic 'e', without preventing legitimate registrations such as "ABC.com". For the latter, the visual indication would be there, and people would be alerted to the multiple scripts, but it would not prevent usage. Regard, Mark From owner-idn@ops.ietf.org Tue Jun 18 18:53:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07572 for ; Tue, 18 Jun 2002 18:53:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KRlQ-0006ea-00 for idn-data@psg.com; Tue, 18 Jun 2002 15:47:52 -0700 Received: from smtprelay2.dc3.adelphia.net ([24.50.78.5]) by psg.com with esmtp (Exim 3.36 #1) id 17KRlN-0006eO-00 for idn@ops.ietf.org; Tue, 18 Jun 2002 15:47:49 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.250]) by smtprelay2.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GXXBBJ00.CLJ; Tue, 18 Jun 2002 18:47:43 -0400 Message-ID: <00b201c21719$dddc0380$fa424244@anhmca.adelphia.net> From: "Doug Ewell" To: "Mark Davis" , "John C Klensin" , "Dan Oscarsson" , References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Tue, 18 Jun 2002 15:45:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Davis wrote: > 2. There are no "non-Unicode coding systems" that unify beta and > eszed; the language issue is irrelevant. MS-DOS code page 437 had a character at 0xE1 that was sometimes rendered more like a sharp-s and sometimes more like a small beta, depending on which screen font you were using. In the standard 8x8 font and 8x14 fonts it was very definitely a beta, but in the 8x16 font it was a sharp-s. To make matters worse, the character was surrounded by small alpha at 0xE0 and capital gamma at 0xE2, implying a continuous sequence of Greek letters. But in code page 850, 0xE1 was unmistakably a sharp-s. One might say that CP437 was inadequate to encode Greek anyway, but then it was inadequate to encode plenty of Latin-based languages as well, so that was not a great argument against the "beta" interpretation. Of course, character tables hardcoded in the ROMs of PCs weren't intended to be definitive. Things were looser then. Before Unicode came around as sort of the "gold standard" of character encodings, most people didn't worry about whether 0xE1 was a beta or a sharp-s. It could be either, depending on context. Now our expectations are higher, and we need to differentiate between the two. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Wed Jun 19 11:24:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22902 for ; Wed, 19 Jun 2002 11:24:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Kh5F-000N2q-00 for idn-data@psg.com; Wed, 19 Jun 2002 08:09:21 -0700 Received: from ds217-115-140-127.dedicated.hosteurope.de ([217.115.140.127] helo=ns10913a.cobalthosting.net) by psg.com with esmtp (Exim 3.36 #1) id 17Kh5C-000N2f-00 for idn@ops.ietf.org; Wed, 19 Jun 2002 08:09:18 -0700 Received: from notebook (pD95385D5.dip.t-dialin.net [217.83.133.213]) by ns10913a.cobalthosting.net (8.10.2/8.10.2) with SMTP id g5JF9Da28085 for ; Wed, 19 Jun 2002 17:09:13 +0200 Message-ID: <015501c217a3$135ee750$b48dfea9@notebook> From: "Georg Ochsner" To: References: <013D3552A4BCD411AF6000508BDE8DEC712F4D@misv0002.mi.saritel.it> Subject: [idn] =?iso-8859-1?Q?Re:_=5Bidn=5D_eszet_=28ss=2C_sz=2C_=DF=2C_call_it_whatever?= =?iso-8859-1?Q?_you_want=29?= Date: Wed, 19 Jun 2002 17:07:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > AFAIK, in German there are some specific cases in which you have > to use ß instead of ss. Needless to say, it was not the same throughout > Germandom: in Switzerland, the character is not used. The writing > reform happened some years ago changed again things, reducing the number > of cases in which ß has to be used. Moreover, there is no uppercase > form: you have to write SS. In short, a mess :-) "SS" is not always the case, sometimes "SZ" is used instead. "ss" (or "sz", "SS", "SZ") is not necessarily meaning the same as "ß" (sharp s) (also after the "writing reform") e.g.: "Masse" means: mass, majority "Maße" means: metrics, gauges "Ass" means ace "aß" means ate (pastens of "to eat") ... In many words the "ß" (sharp s) is the only right spelling in Germany and Austria (about 90 million people). In Switzerland and Liechtenstein (4,5 million German speaking people) there is AFAIK no "ß" (sharp s), maybe in names. German is the most spoken mother tongue in the European Union. I think the reason, why there is no uppercase "ß" (sharp s) is because there are no words beginning with it - so uppercase is grammatically not necessary. > > I assume Germans use it to write German words. Not > > to replace double s in non-German names. correct I guess a great majority of the people uses lowercase spelling to enter URLs into its browsers... Georg From owner-idn@ops.ietf.org Thu Jun 20 21:24:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17475 for ; Thu, 20 Jun 2002 21:24:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LCua-000Ohl-00 for idn-data@psg.com; Thu, 20 Jun 2002 18:08:28 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17LCuU-000OhE-00 for idn@ops.ietf.org; Thu, 20 Jun 2002 18:08:22 -0700 Received: from MASTER ([211.196.254.39]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5L18GD24224 for ; Fri, 21 Jun 2002 10:08:16 +0900 Message-ID: <003801c218c0$04d683f0$2b19fea9@temp> From: "Soobok Lee" To: References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> <00b201c21719$dddc0380$fa424244@anhmca.adelphia.net> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Fri, 21 Jun 2002 10:07:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Ewell" To: "Mark Davis" ; "John C Klensin" ; "Dan Oscarsson" ; Sent: Wednesday, June 19, 2002 7:45 AM Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? > Mark Davis wrote: > > > 2. There are no "non-Unicode coding systems" that unify beta and > > eszed; the language issue is irrelevant. > > MS-DOS code page 437 had a character at 0xE1 that was sometimes rendered > more like a sharp-s and sometimes more like a small beta, depending on > which screen font you were using. In the standard 8x8 font and 8x14 > fonts it was very definitely a beta, but in the 8x16 font it was a > sharp-s. One similar example in TC/SC: One of the most popular korean word processor "Arae-A Hangeul" (not unicode-based) provides with two chinese font sets, one for TC and the other for SC. If a Korean user wanna write a letter in SC that may contain IRI or IDN, he should type it in TC first and change the session font set into given SC font. Then, most 1:1 TC letter is displayed/printed as its SC equivalent. Most Koreans are not familar to exotic Input Methods of Japanese and Chinese Simplified letters. Facilitating input of exotic chars by font substitutions has merits. That remind me of the ASCII-mapped DINGBATS font sets. I don't know well about whether or not there are similar cases in japan , taiwan and china. Soobok Lee From owner-idn@ops.ietf.org Thu Jun 20 22:24:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18960 for ; Thu, 20 Jun 2002 22:24:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LDw0-000Pg5-00 for idn-data@psg.com; Thu, 20 Jun 2002 19:14:00 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17LDvv-000Pfp-00 for idn@ops.ietf.org; Thu, 20 Jun 2002 19:13:55 -0700 Received: from MASTER ([211.196.254.39]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5L2DmD25524 for ; Fri, 21 Jun 2002 11:13:49 +0900 Message-ID: <007a01c218c9$2cdd50f0$2b19fea9@temp> From: "Soobok Lee" To: References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> <00b201c21719$dddc0380$fa424244@anhmca.adelphia.net> <003801c218c0$04d683f0$2b19fea9@temp> Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Date: Fri, 21 Jun 2002 11:13:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Copy&Paste operations from such legacy applications into other applications may not preserve the intended character glyph informations determined by char sets+font sets. That will pose another interoperablility problems to end users. Some OS-addon/applications has it own proprietary legacy char set/locale, but share the same code space with ASCII and use ASCII-mapped font-substitution to implement their legacy char sets, for example, in order to implement CJK supports in English-only windows or linux. I found some other examples in Indic char sets. In General, informations about assumed/system-wide font sets are not available to applications or not interpretable with machine intelligence. These kinds of font usages should be discouraged in IDN specifications ? Soobok Lee ----- Original Message ----- From: "Soobok Lee" > Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? > > > > Mark Davis wrote: > > > > > 2. There are no "non-Unicode coding systems" that unify beta and > > > eszed; the language issue is irrelevant. > > > > MS-DOS code page 437 had a character at 0xE1 that was sometimes rendered > > more like a sharp-s and sometimes more like a small beta, depending on > > which screen font you were using. In the standard 8x8 font and 8x14 > > fonts it was very definitely a beta, but in the 8x16 font it was a > > sharp-s. > > One similar example in TC/SC: > > One of the most popular korean word processor "Arae-A Hangeul" (not unicode-based) > provides with two chinese font sets, one for TC and the other for SC. > If a Korean user wanna write a letter in SC that may contain IRI or IDN, > he should type it in TC first and change the session font set into given SC font. > Then, most 1:1 TC letter is displayed/printed as its SC equivalent. > > Most Koreans are not familar to exotic Input Methods of Japanese and Chinese Simplified > letters. Facilitating input of exotic chars by font substitutions has merits. That remind me of > the ASCII-mapped DINGBATS font sets. I don't know well > about whether or not there are similar cases in japan , taiwan and china. > > Soobok Lee > > > > > > > From owner-idn@ops.ietf.org Fri Jun 21 09:23:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11563 for ; Fri, 21 Jun 2002 09:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LO6D-000AL6-00 for idn-data@psg.com; Fri, 21 Jun 2002 06:05:13 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17LO6A-000AKr-00 for idn@ops.ietf.org; Fri, 21 Jun 2002 06:05:10 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18348; Fri, 21 Jun 2002 07:05:04 -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 g5LD52b22069; Fri, 21 Jun 2002 15:05:02 +0200 (MEST) Date: Fri, 21 Jun 2002 15:03:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) To: John C Klensin Cc: Erik Nordmark , IETF idn working group , Paul Hoffman / IMC , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: "Your message with ID" <127445574.1023965818@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk > Because we have tried that approach, mostly inadvertently, many > times before, and it has always gotten us into trouble. "You > are not permitted to do this" leaves us in a position where we > can later make it permissible and give it an interpretation at > the same time. "It is undefined" seems to invariably create a > community of people who are sure what "undefined" means --i.e., > who assign a meaning to it-- and who then become a serious, > installed-base, impediment to any other interpretation. And > "this applies globally" will be taken as the basis for a claim > that we are making a seriously incompatible change if we try to > do something else in some other name space. John, I'm not saying that leaving things undefined is the way forward. But you seem to be saying, in addition to wanting things to be well defined, that there needs to be an attempt to either predict the future or only apply IDNA in the smallest possible context. I think there is a 3rd alternative which is to, unless explicitly overridden elsewhere in the future, apply it everywhere. This can be perfectly well-defined as far as I can tell and it means that any changes can be done with the well-defined basis as a foundation. > * RFC821 specified Internet email transport in terms of > ASCII. It didn't explicitly (enough) prohibit sending > non-ASCII ("8bit") characters. [...] > * RFC 1034 and 1035 define labels in terms of ASCII > characters, but contains more or less vague language > about how labels containing octet values that cannot be > ASCII are to be interpreted. [...] The above two examples seems to me to be cases of loosly defined specifications. I agree that we want to avoid that in the IDN space to the extent possible. > As just one example of this, suppose we come along later > and want to put Unicode more directly into the DNS. We > know that UTF-8 isn't a particularly efficient encoding > -- its design is strongly influenced by the need to be > compatible with octet-based systems. We also know > that UCS-4 (UTF-32) isn't very efficient either. But we > know a good deal about compression, and could do some > elegant things about compressing a string written in > Unicode characters. But, to do that, we need _binary_ > labels (not just binary octets), i.e., a length-encoded > bit string of up to 63 octets in length and with no > variant interpretations based on whether the stored > value of a given octet falls in the 0x00-0xFF range. > That is pretty easy to do in the DNS structure, but it > requires per-RR or per-Class definitions of how the > label string is interpreted/ matched. If we read > 1034/1035 as "it is all characters" then either this is > hopeless or we will need to invent another kludge > (fortunately, the obvious one is still more efficient > than UTF-8). If we read 1034/1035 as "only the existing > RRs and Classes are specfied, new ones get to specify > their own rules" then the range of options remains open. I think the place where this discussion belongs is the now expired draft-ietf-dnsext-unknown-rrs-02.txt. But I note that it is lacking as well in that it silently seems to assume that all the owner names are ASCII text by saying: The owner name is still set to lower case. I agree it is highly desirable to be able to define new RR types and/or classes without the ASCII case insensitive comparison of the owner names. But the feasibility of this is a function of what existing DNS implementations do with unknown types and classes. If it turns out that this isn't possible one can still envision efficient encoding of Unicode owner names e.g. by applying the Bootstring algorithm (used by punycode) but have the output code set be e.g. 0-0x40,0x5b-0xff i.e. avoid using bytes which an ASCII case insensitive comparison would trip on. The alternative seems to be to embark on discussions whether RR type X (for different values of X including e.g. SRV, NAPTR) benefits enough from IDNA to make that RR type be covered by the IDNA specification. I fail to see how this WG can have expertize in determining the usage of all defined RR types. Even if the WG had that expertise I still wouldn't be suprised there were radically opposing judgements about "benefit enough from IDNA" for some types. Erik From owner-idn@ops.ietf.org Fri Jun 21 11:58:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18818 for ; Fri, 21 Jun 2002 11:58:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LQXf-000D2v-00 for idn-data@psg.com; Fri, 21 Jun 2002 08:41:43 -0700 Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com) by psg.com with esmtp (Exim 3.36 #1) id 17LQXc-000D2k-00 for idn@ops.ietf.org; Fri, 21 Jun 2002 08:41:40 -0700 Received: from [64.109.213.10] (adsl-64-109-213-10.dsl.lgnnmi.ameritech.net [64.109.213.10]) by www.wordnic.com (8.9.3/8.9.3) with ESMTP id KAA24834; Fri, 21 Jun 2002 10:41:34 -0500 Mime-Version: 1.0 X-Sender: tedd1@sperling.com Message-Id: In-Reply-To: <007a01c218c9$2cdd50f0$2b19fea9@temp> References: <3D0F0036.81D3D52A@trab.se> <80396120.1024395179@localhost> <00aa01c216d9$9461b1e0$8900a8c0@c1340594a> <00b201c21719$dddc0380$fa424244@anhmca.adelphia.net> <003801c218c0$04d683f0$2b19fea9@temp> <007a01c218c9$2cdd50f0$2b19fea9@temp> Date: Fri, 21 Jun 2002 11:41:34 -0400 To: From: tedd Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete? Cc: "Soobok Lee" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok said: >Copy&Paste operations from such legacy applications into other applications >may not preserve the intended character glyph informations >determined by char sets+font sets. >That will pose another interoperablility problems to end users. Soobok: IMP, inoperable problems to end users will happen regardless of what the IDN does. Copy&Paste operations (legacy or otherwise) are not uniform across platforms and nothing this WG (or any WG) does will fix that. However, Copy&Paste operations (at least in the Macintosh) are becoming much more complex than they were and what they would appear. While the specifics of what is evolving in the Copy&Paste world is beyond the interest of this WG, I foresee an end user OS software solution to your concerns. I do not expect this WG providing (or even having the means to provide) a solution to that problem. tedd -- http://sperling.com From owner-idn@ops.ietf.org Fri Jun 21 16:06:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29922 for ; Fri, 21 Jun 2002 16:06:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LUUw-000IJc-00 for idn-data@psg.com; Fri, 21 Jun 2002 12:55:10 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17LUUr-000IIf-00 for idn@ops.ietf.org; Fri, 21 Jun 2002 12:55:06 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17LUUc-0007HT-00; Fri, 21 Jun 2002 19:54:50 +0000 Date: Fri, 21 Jun 2002 15:54:21 -0400 From: John C Klensin To: Erik Nordmark cc: IETF idn working group , "Paul Hoffman / IMC" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <103959547.1024674861@localhost> X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_Q_MARK version=2.20 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 21 June, 2002 15:03 +0200 Erik Nordmark wrote: >> Because we have tried that approach, mostly inadvertently, >> many times before, and it has always gotten us into trouble. >> "You are not permitted to do this" leaves us in a position >> where we can later make it permissible and give it an >> interpretation at the same time. "It is undefined" seems to >> invariably create a community of people who are sure what >> "undefined" means --i.e., who assign a meaning to it-- and >> who then become a serious, installed-base, impediment to any >> other interpretation. And "this applies globally" will be >> taken as the basis for a claim that we are making a seriously >> incompatible change if we try to do something else in some >> other name space. > > John, > > I'm not saying that leaving things undefined is the way > forward. But you seem to be saying, in addition to wanting > things to be well defined, that there needs to be an attempt > to either predict the future or only apply IDNA in the > smallest possible context. Let me restate the second alternative. I believe there are several different ways to do it, but * At this time, IDNA should be applied only to well-understood cases * Both it, and any alternatives, should be prohibited elsewhere, leaving future cases for future specification. * We have a procedure for loosening the rules -- applying IDNA or other conventions elsewhere -- in the future if needed. is the essence of the suggestion. > I think there is a 3rd alternative which is to, unless > explicitly overridden elsewhere in the future, apply it > everywhere. This can be perfectly well-defined as far as I can > tell and it means that any changes can be done with the > well-defined basis as a foundation. Actually, I suggest we have never been able to do that and that it is exactly the source of my concern. We try very hard to avoid getting into situations in which we standardize something, let it get deployed, and then say "sorry, we are changing that, you must do something else in this particular case". IESG has almost never approved such things, and IETF action has mostly failed in the marketplace when we have tried to do so. Installed base is important, installed base backed by our standards is irreversible. >> * RFC821 specified Internet email transport in terms of >> ASCII. It didn't explicitly (enough) prohibit sending >> non-ASCII ("8bit") characters. [...] > >> * RFC 1034 and 1035 define labels in terms of ASCII >> characters, but contains more or less vague language >> about how labels containing octet values that cannot be >> ASCII are to be interpreted. [...] > > The above two examples seems to me to be cases of loosly > defined specifications. I agree that we want to avoid that in > the IDN space to the extent possible. I agree that they are loosely defined. And that more precise definition is better. But it seems to me that precisely defining something to cover things that are not invented yet is not the way to go unless it is necessary and we have a clear picture. I.e., I am trying hard to avoid having to predict the future or to constrain it. >> As just one example of this, suppose we come along later >> and want to put Unicode more directly into the DNS. We >> know that UTF-8 isn't a particularly efficient encoding >> -- its design is strongly influenced by the need to be >> compatible with octet-based systems. We also know >>... > I think the place where this discussion belongs is the now > expired draft-ietf-dnsext-unknown-rrs-02.txt. But I note that > it is lacking as well in that it silently seems to assume that > all the owner names are ASCII text by saying: > The owner name is > still set to lower case. Yes, probably, although I haven't looked at that draft. I'm happy to have that discussion anywhere you direct. My concern is that the IDN WG, as a side-effect of a passing phrase in a document that does not appear to have been carefully examined in the DNS community and that isn't supposed to impact the DNS, is imposing a major constraint on future DNS use and expansion. That doesn't seem right to me. > I agree it is highly desirable to be able to define new RR > types and/or classes without the ASCII case insensitive > comparison of the owner names. But the feasibility of this is > a function of what existing DNS implementations do with > unknown types and classes. If it turns out that this isn't > possible one can still envision efficient encoding of Unicode > owner names e.g. by applying the Bootstring algorithm (used by > punycode) but have the output code set be e.g. > 0-0x40,0x5b-0xff i.e. avoid using bytes which an ASCII case > insensitive comparison would trip on. > > The alternative seems to be to embark on discussions whether > RR type X (for different values of X including e.g. SRV, > NAPTR) benefits enough from IDNA to make that RR type be > covered by the IDNA specification. I fail to see how this WG > can have expertize in determining the usage of all defined RR > types. Even if the WG had that expertise I still wouldn't be > suprised there were radically opposing judgements about > "benefit enough from IDNA" for some types. Ah, but you see... that is the point. With the current wording, at least as I read it, the WG is trying to do exactly that, and to do it without looking at the RRs involved. But I can live with even that. Let's assume the text said something more like "IDNA can be applied to all currently-defined and registered RRs in Class=IN, but is not to be applied to subsequent RRs or other Classes unless their definitions explicitly say so". I wouldn't be wild about that, but, perhaps unlike Eric Hall, I'm also not willing to lose sleep over it. But, if we are ever going to be able to extend the DNS in ways that impact the name space, we must avoid setting a standard that applies to those spaces where we haven't ventured. So, it seems to me that the right thing to do is to deal with the RRs we have (if necessary, sweepingly and all at once), and to prohibit the application of IDNA --or any set of rules more restrictive than "binary"-- until rules and methods of interpretation are specified by those new definitions. They might well apply IDNA. I would expect that, at least within Class=IN, most would. But let's leave ourselves in a position to late-bind that decision. john From owner-idn@ops.ietf.org Fri Jun 21 18:15:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02833 for ; Fri, 21 Jun 2002 18:15:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LWWz-000Lsr-00 for idn-data@psg.com; Fri, 21 Jun 2002 15:05:25 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17LWWv-000Lsc-00 for idn@ops.ietf.org; Fri, 21 Jun 2002 15:05:22 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17LWWq-0004or-00; Fri, 21 Jun 2002 15:05:16 -0700 Date: Fri, 21 Jun 2002 22:05:15 +0000 From: "Adam M. Costello" To: John C Klensin Cc: Erik Nordmark , IETF idn working group , Paul Hoffman / IMC , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <20020621220514.GE16851@nicemice.net> Reply-To: IETF idn working group References: <103959547.1024674861@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <103959547.1024674861@localhost> User-Agent: Mutt/1.3.28i X-Advice: should read soon X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK,DIFFERENT_REPLY_TO version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk John C Klensin wrote: > But, if we are ever going to be able to extend the DNS in ways that > impact the name space, we must avoid setting a standard that applies > to those spaces where we haven't ventured. Any future spec that defines a new RR type or a new class (or any new region) can stipulate that IDNA does not apply there. Yes, people are reluctant to make breaks like that, and they should be. They should do it only if there is a compelling reason. If we set the default the other way, so that future RR types and classes need to explicitly adopt IDNA, we might encourage unnecessary disharmony. AMC From owner-idn@ops.ietf.org Fri Jun 21 20:12:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04933 for ; Fri, 21 Jun 2002 20:12:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LYO8-000COb-00 for idn-data@psg.com; Fri, 21 Jun 2002 17:04:24 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17LYO4-000CNw-00 for idn@ops.ietf.org; Fri, 21 Jun 2002 17:04:20 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17LYO3-0007pY-00; Sat, 22 Jun 2002 00:04:19 +0000 Date: Fri, 21 Jun 2002 20:04:18 -0400 From: John C Klensin To: IETF idn working group cc: Erik Nordmark , "Paul Hoffman / IMC" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <118959077.1024689858@localhost> In-Reply-To: <20020621220514.GE16851@nicemice.net> References: <103959547.1024674861@localhost> <20020621220514.GE16851@nicemice.net> X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.20 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 21 June, 2002 22:05 +0000 "Adam M. Costello" wrote: > John C Klensin wrote: > >> But, if we are ever going to be able to extend the DNS in >> ways that impact the name space, we must avoid setting a >> standard that applies to those spaces where we haven't >> ventured. > > Any future spec that defines a new RR type or a new class (or > any new region) can stipulate that IDNA does not apply there. > > Yes, people are reluctant to make breaks like that, and they > should be. They should do it only if there is a compelling > reason. > > If we set the default the other way, so that future RR types > and classes need to explicitly adopt IDNA, we might encourage > unnecessary disharmony. Adam, I think I've just understood the philosophical difference here. Assuming I've gotten it right now, I apologize for not understanding and identifying it sooner. To me, IDNA is a kludge. If we were designing the DNS (and Internet applications) for the first time today, and it was clear to us that "full internationalization" (whatever that means) was desirable, IDNA is almost certainly not how we would do it. It is a really clever kludge, one that responds well to the constraints we have because we are not starting fresh, but it is a kludge. And making a kludge the default for future cases is just not a good idea. Please note that I am not proposing the LDH be the default, or the unrestricted binary be the default, or that "make up your own prefix and do strange things to yourself" be the default. I am suggesting that we should create a "no default" situation, in which new RRs (and, more important, new Classes) are required to specify how the octets in their labels are to be interpreted, and what syntax restrictions might be applied to them. With regard to "encourag[ing] unnecessary disharmony", this is an area where I have a lot of confidence in the IESG --not just this IESG, but predictions I think can safely be made about future IESGs. If someone comes along and says, well, I'm Bob, and I want to introduce a new coding scheme into the DNS called IDNB (for "Bob"), he isn't going to survive the laugh test. I imagine that "this doesn't require internationalization" or "I need to invent a new scheme" will get really intense scrutiny, as they should. But no sweeping defaults. Especially no sweeping defaults that apply not only to future classes but to existing ones where there has been absolutely no review and discussion by this WG on whether or not there is an adverse impact. That isn't just incorrect from a design standpoint, it is procedurally incorrect. john From owner-idn@ops.ietf.org Sat Jun 22 03:13:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20781 for ; Sat, 22 Jun 2002 03:13:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Lepk-000CpX-00 for idn-data@psg.com; Fri, 21 Jun 2002 23:57:20 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Lepa-000CpG-00 for idn@ops.ietf.org; Fri, 21 Jun 2002 23:57:10 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id AAA21952 for ; Sat, 22 Jun 2002 00:01:55 -0700 Message-Id: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 20:14:32 -0400 To: IETF idn working group From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) In-Reply-To: <103959547.1024674861@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=3.4 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK,NO_MX_FOR_FROM, DATE_IN_PAST_06_12,MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: *** Sender: owner-idn@ops.ietf.org Precedence: bulk At 03:54 PM 6/21/2002 -0400, John C Klensin wrote: >--On Friday, 21 June, 2002 15:03 +0200 Erik Nordmark > wrote: > > > I think there is a 3rd alternative which is to, unless > > explicitly overridden elsewhere in the future, apply it > > everywhere. This can be perfectly well-defined as far as I can > > tell and it means that any changes can be done with the > > well-defined basis as a foundation. > >Actually, I suggest we have never been able to do that and that >it is exactly the source of my concern. We try very hard to >avoid getting into situations in which we standardize something, >let it get deployed, and then say "sorry, we are changing that, >you must do something else in this particular case". At the end of the movie "War of the Roses", Danny DeVito (playing an attorney) says that he is going to offer his potential client some free advice, and "when a $1000 per hour attorney offers free advice, you should listen." When John and I agree about an action, the rest of you folks should listen. To use a whimsical legal phrase, folks are talking about unringing a bell. The working group needs to focus more narrowly: we have exactly ONE DNS PROBLEM that must have immediate solution: Permitting an internationalized form of domain name for business cards -- that is, for URLs and email. These are usually called hostnames. All other IDN requirements can wait. So far, the IDN working group has produced nothing that is used. If the working group issues a first, narrow specification, we can make immediate progress and offer the community something it desperately needs. We can also learn more about how this all works and then apply it to the next, ummmmmmm,,, domain. >I agree that they are loosely defined. And that more precise >definition is better. But it seems to me that precisely >defining something to cover things that are not invented yet is >not the way to go unless it is necessary and we have a clear >picture. I.e., I am trying hard to avoid having to predict the >future or to constrain it. correct on all counts. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 22 11:53:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29183 for ; Sat, 22 Jun 2002 11:53:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Lmyg-000Lns-00 for idn-data@psg.com; Sat, 22 Jun 2002 08:39:06 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17Lmyc-000Lnf-00 for idn@ops.ietf.org; Sat, 22 Jun 2002 08:39:02 -0700 Received: from MASTER ([211.196.254.39]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5MFclD27659; Sun, 23 Jun 2002 00:38:48 +0900 Message-ID: <017d01c21a02$cea790a0$2b19fea9@temp> From: "Soobok Lee" To: "IETF idn working group" , "Dave Crocker" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Sun, 23 Jun 2002 00:38:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.3 required=5.0 tests=SUBJ_HAS_Q_MARK,DOUBLE_CAPSWORD,RCVD_IN_RFCI version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > The working group needs to focus more narrowly: we have exactly ONE DNS > PROBLEM that must have immediate solution: > > Permitting an internationalized form of domain name for business > cards -- that is, for URLs and email. These are usually called > hostnames. > > All other IDN requirements can wait. > > So far, the IDN working group has produced nothing that is used. If the > working group issues a first, narrow specification, we can make immediate > progress and offer the community something it desperately needs. We can > also learn more about how this all works and then apply it to the next, > ummmmmmm,,, domain. Do you suggest that the new narrower specification should be about 1) transitional directory solution that may become the precursor to the real IDN with "NEW CLASS" ? or 2) the real IDN limited to hostnames and its supporting RRs (NS,A,MX,CNAME) ? If future "new class" should have type A and type NS records like "IN" class, approach 1) is more appropriate in this stage. some commercial IDN TLD registries already implemented this transitional directory by wildcard label (*) resolutions for native 8bit A-type queries. They redirect such incoming native 8bit A-type queries into a forwarding webserver which maintains registrants-supplied ASCII URL address with no ACE hostname. Moreover, the forwarding webserver can extract some default locale information from the http header information from the brower client and make most correct guess about what the local charset was and transcode the 8bit hostname into UCS one which is then compared against UCS-to-URL databases . I think this directory feature is enough for most desperate consumers for a while and IMO, forever. Soobok Lee From owner-idn@ops.ietf.org Sat Jun 22 12:35:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00181 for ; Sat, 22 Jun 2002 12:35:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Lnli-000MOe-00 for idn-data@psg.com; Sat, 22 Jun 2002 09:29:46 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17LnlY-000MOI-00 for idn@ops.ietf.org; Sat, 22 Jun 2002 09:29:36 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA31409; Sat, 22 Jun 2002 09:34:23 -0700 Message-Id: <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 22 Jun 2002 09:25:41 -0700 To: "Soobok Lee" From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: "IETF idn working group" In-Reply-To: <017d01c21a02$cea790a0$2b19fea9@temp> References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.9 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK,DOUBLE_CAPSWORD, NO_MX_FOR_FROM,MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:38 AM 6/23/2002 +0900, Soobok Lee wrote: >Do you suggest that the new narrower specification should be about "new" is not a word I would use, right now. I am talking about cutting away the generalities from the current work and leaving the portion that applies to usage for the immediate need. > 1) transitional directory solution that may become the precursor to > the real IDN with "NEW CLASS" ? or > 2) the real IDN limited to hostnames and its supporting RRs > (NS,A,MX,CNAME) ? The idea of defining something that is a transition, without already having the the end-point of the transition also defined and in the process of being deployed is simply not practical. When "transition" takes 5 years and more, it is counterproductive to think of transition as temporary. The work done here is to define the IDN and an encoding scheme for IDN. Perhaps there will be more encoding schemes and perhaps there will not. The only prediction about future IETF work and future Internet development that has proved accurate is that predictions prove to be inaccurate. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 22 13:49:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01294 for ; Sat, 22 Jun 2002 13:49:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Lovn-000NGe-00 for idn-data@psg.com; Sat, 22 Jun 2002 10:44:15 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17Lovj-000NGT-00 for idn@ops.ietf.org; Sat, 22 Jun 2002 10:44:11 -0700 Received: from MASTER ([211.196.254.39]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5MHi5D28404; Sun, 23 Jun 2002 02:44:05 +0900 Message-ID: <019801c21a14$495cecd0$2b19fea9@temp> From: "Soobok Lee" To: "Dave Crocker" Cc: "IETF idn working group" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Sun, 23 Jun 2002 02:43:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.3 required=5.0 tests=SUBJ_HAS_Q_MARK,DOUBLE_CAPSWORD,RCVD_IN_RFCI version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > > The idea of defining something that is a transition, without already having > the the end-point of the transition also defined and in the process of > being deployed is simply not practical. > > When "transition" takes 5 years and more, it is counterproductive to think > of transition as temporary. The directory-for-8bit-query approach for IDN need not be declared as "transitional", rather may be independant one which may be later obsoleted smoothly by "new class" solution. Non-ASCII octets in "IN" class has no defined comparison rules and that opens rooms and rationales for per-registry comparison rules that can be implementable only in a directory approach. Each TLD registry can decide which one it deploy among "directory" approach, "new class", or both. Both can coexist for two differnt audiences with/without "new class" supports,respectively, IMO. Please correct me if it is impossible or problematic. Such directory approach allows each TLD registries to adopt its own comparison rules, thus non-monolithic normalization rules and works better in dealing with charset interoperability and look-similar/identical character problems. Such rules or experiences would be implementable as multiple registrations or normalization rules in "new class" IDN in the future when stringprep,UNICODE and local charset standards become mature and stablized. Most TLD registries feel strongly the need to add native labels in *both* UTF8 and local charsets, because existing applications blindly make 8bit queries. If those queries are not served, end users experience failures. Current ACE architecture requries every end user to install IDN-plugins to enjoy IDN safely, but that is not the one that end users and registries desperately need "right now". The directory approach can fulfill these needs clealy and safely. Soobok Lee From owner-idn@ops.ietf.org Sat Jun 22 15:48:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02970 for ; Sat, 22 Jun 2002 15:48:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LqkS-000Odn-00 for idn-data@psg.com; Sat, 22 Jun 2002 12:40:40 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17LqkI-000OdA-00 for idn@ops.ietf.org; Sat, 22 Jun 2002 12:40:30 -0700 Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA03400; Sat, 22 Jun 2002 12:45:18 -0700 Message-Id: <5.1.0.14.2.20020622123317.02d425d0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 22 Jun 2002 12:39:54 -0700 To: "Soobok Lee" From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: "IETF idn working group" In-Reply-To: <019801c21a14$495cecd0$2b19fea9@temp> References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK,NO_MX_FOR_FROM, MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:43 AM 6/23/2002 +0900, Soobok Lee wrote: >Each TLD registry can decide which one it deploy among "directory" approach, A decision to use an 8-bit encoding scheme will be rather useless, since there is no standard specification for doing it. The absence of a standard means there is no interoperability. >Such directory approach allows each TLD registries to adopt its own >comparison rules, Oh? Different rules for each TLD? What about different for each level in the hierarchy, too? You appear to be intent on making architecture choices that ensure long term non-interoperability. having many choices creates an architecture that does not scale. >Most TLD registries feel strongly the need to add native labels in *both* >UTF8 and local charsets, "local charsets"? Whatever does that mean? And UTF-8 is merely an encoding scheme. It is not the "native" representation of the character set. For that matter, I suspect most TLD registries neither know nor care about the technical details of UTF-8 vs. ACE, or the like. They merely want a functioning, standard, interoperable IDN. > The directory approach can fulfill these needs clealy and safely. By the way, the DNS is not a directory system. This has been explained many times. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sat Jun 22 21:08:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07188 for ; Sat, 22 Jun 2002 21:08:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LvhW-0002qJ-00 for idn-data@psg.com; Sat, 22 Jun 2002 17:57:58 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17LvhS-0002q8-00 for idn@ops.ietf.org; Sat, 22 Jun 2002 17:57:54 -0700 Received: (qmail 61858 invoked from network); 23 Jun 2002 01:02:29 -0000 Received: from bb-203-125-4-70.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.4.70) by sentosa.post1.com with SMTP; 23 Jun 2002 01:02:29 -0000 Message-ID: <015b01c21a50$f5ceecc0$bb00a8c0@JAMESSONYVAIO> From: "James Seng" To: "Soobok Lee" , "Dave Crocker" Cc: "IETF idn working group" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> <5.1.0.14.2.20020622123317.02d425d0@jay.songbird.com> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Sun, 23 Jun 2002 08:57:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.2 required=5.0 tests=SUBJ_HAS_Q_MARK,RCVD_IN_RFCI version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hmm...it seem to me that Lee is proposing something new, a directory approach which includes various features etc. Therefore, I suggest Lee write down his ideas in a new internet draft as a basis for further discussion. -James Seng ----- Original Message ----- From: "Dave Crocker" To: "Soobok Lee" Cc: "IETF idn working group" Sent: Sunday, June 23, 2002 3:39 AM Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) > At 02:43 AM 6/23/2002 +0900, Soobok Lee wrote: > >Each TLD registry can decide which one it deploy among "directory" approach, > > A decision to use an 8-bit encoding scheme will be rather useless, since > there is no standard specification for doing it. The absence of a standard > means there is no interoperability. > > > >Such directory approach allows each TLD registries to adopt its own > >comparison rules, > > Oh? Different rules for each TLD? What about different for each level in > the hierarchy, too? > > You appear to be intent on making architecture choices that ensure long > term non-interoperability. having many choices creates an architecture > that does not scale. > > > >Most TLD registries feel strongly the need to add native labels in *both* > >UTF8 and local charsets, > > "local charsets"? Whatever does that mean? > > And UTF-8 is merely an encoding scheme. It is not the "native" > representation of the character set. > > For that matter, I suspect most TLD registries neither know nor care about > the technical details of UTF-8 vs. ACE, or the like. They merely want a > functioning, standard, interoperable IDN. > > > > The directory approach can fulfill these needs clealy and safely. > > By the way, the DNS is not a directory system. This has been explained > many times. > > d/ > > > ---------- > Dave Crocker > TribalWise, Inc. > tel +1.408.246.8253; fax +1.408.850.1850 > > > From owner-idn@ops.ietf.org Sat Jun 22 21:35:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07518 for ; Sat, 22 Jun 2002 21:35:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LwDe-0003KD-00 for idn-data@psg.com; Sat, 22 Jun 2002 18:31:10 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17LwDV-0003Ju-00 for idn@ops.ietf.org; Sat, 22 Jun 2002 18:31:02 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA11384; Sat, 22 Jun 2002 18:35:47 -0700 Message-Id: <5.1.1.2.2.20020622182848.0280f5d8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sat, 22 Jun 2002 18:28:57 -0700 To: "James Seng" From: Dave Crocker Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Cc: "Soobok Lee" , "IETF idn working group" In-Reply-To: <015b01c21a50$f5ceecc0$bb00a8c0@JAMESSONYVAIO> References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> <5.1.0.14.2.20020622123317.02d425d0@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SUBJ_HAS_Q_MARK,NO_MX_FOR_FROM, MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:57 AM 6/23/2002 +0800, James Seng wrote: >Hmm...it seem to me that Lee is proposing something new, a directory >approach which includes various features etc. Therefore, I suggest Lee write >down his ideas in a new internet draft as a basis for further discussion. yes, that would be helpful. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Jun 23 14:08:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02251 for ; Sun, 23 Jun 2002 14:08:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MBWc-000GlI-00 for idn-data@psg.com; Sun, 23 Jun 2002 10:51:46 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17MBWX-000Gl7-00 for idn@ops.ietf.org; Sun, 23 Jun 2002 10:51:41 -0700 Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17MBW7-000DqD-00; Sun, 23 Jun 2002 17:51:15 +0000 Date: Sun, 23 Jun 2002 13:51:11 -0400 From: John C Klensin To: Dave Crocker , Soobok Lee cc: IETF idn working group Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Message-ID: <2991532.1024840271@localhost> In-Reply-To: <5.1.0.14.2.20020622123317.02d425d0@jay.songbird.com> References: <5.1.0.14.2.20020622123317.02d425d0@jay.songbird.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=-2.7 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, 22 June, 2002 12:39 -0700 Dave Crocker wrote: >... > For that matter, I suspect most TLD registries neither know nor > care about the technical details of UTF-8 vs. ACE, or the like. > They merely want a functioning, standard, interoperable IDN. Not to put too fine a point on it, but most users of applications and the data associated with TLD registries neither know nor care whether the get their "functioning, standard, interoperable 'IDN'" in the DNS or somewhere else entirely, just so long as the mechanism meets they needs and is "functioning, standard, and interoperable". john From owner-idn@ops.ietf.org Mon Jun 24 07:16:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29164 for ; Mon, 24 Jun 2002 07:16:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MRcp-0002cs-00 for idn-data@psg.com; Mon, 24 Jun 2002 04:03:15 -0700 Received: from dove.cc.ncu.edu.tw ([140.115.17.111]) by psg.com with esmtp (Exim 3.36 #1) id 17MRch-0002cT-00 for idn@ops.ietf.org; Mon, 24 Jun 2002 04:03:07 -0700 Received: from LocalHost ([140.115.5.82]) (authenticated tsenglm (0 bits)) by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g5OB29i03295 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 24 Jun 2002 19:02:09 +0800 (CST) Message-ID: <000e01c21b6e$23f66ce0$5205738c@LocalHost> From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= To: "Soobok Lee" , "Dave Crocker" Cc: "IETF idn working group" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> <019801c21a14$495cecd0$2b19fea9@temp> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Mon, 24 Jun 2002 18:57:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_NAME_NO_SPACES,SUBJ_HAS_Q_MARK,DEAR_SOMEBODY, DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Soobok: Your good suggestion reflects some exised facts and it is very interesting. The directory-for-8bit-query approach is currently used in .CC , .NU, .TW . It is independent on 8 bit or ASCII . The 8 bit approach is based on UTF-8 resolver of Win2k OS . After the "*" "match to any others" , The simulated UTF-8 NS server or a redirected A RR web server can redirect the client to get an ACE name to do regular resolving . By the PUNY code or RACE code approach , the nameprep are solved in the simulated DNS server side. Always, it is out of scope in this working group to discuss equivalence comparison of non-ASCII code point, so it is a local issue based on TLD . This approach only work for a DNS subtree . Even it is safe without new plug-in to client , but there are some other problems. One is that need more effort on web proxy servers to treat native to UTF-8 conversion . Another important interoperability protocol issue is the virtual host of web page , that is how to pass what kind of identifier (native , utf-8 , ACE or others) to let a web server to act as the "virtual host" of web page and will guide the client re-direct to the target web page. L.M.Tseng > The directory-for-8bit-query approach for IDN need not be declared as "transitional", > rather may be independant one which may be later obsoleted smoothly by "new class" solution. > Non-ASCII octets in "IN" class has no defined comparison rules and that opens > rooms and rationales for per-registry comparison rules that can be implementable only in > a directory approach. > > Each TLD registry can decide which one it deploy among "directory" approach, "new class", or both. > Both can coexist for two differnt audiences with/without "new class" supports,respectively, IMO. > Please correct me if it is impossible or problematic. > > Such directory approach allows each TLD registries to adopt its own comparison rules, thus > non-monolithic normalization rules and works better in dealing with charset interoperability > and look-similar/identical character problems. Such rules or experiences would be implementable > as multiple registrations or normalization rules in "new class" IDN in the future > when stringprep,UNICODE and local charset standards become mature and stablized. > > Most TLD registries feel strongly the need to add native labels in *both* UTF8 and local charsets, > because existing applications blindly make 8bit queries. If those queries are not served, > end users experience failures. Current ACE architecture requries every end user to install > IDN-plugins to enjoy IDN safely, but that is not the one that end users and registries > desperately need "right now". The directory approach can fulfill these needs clealy and safely. > > Soobok Lee > > From owner-idn@ops.ietf.org Mon Jun 24 07:46:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00045 for ; Mon, 24 Jun 2002 07:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MS4X-00039F-00 for idn-data@psg.com; Mon, 24 Jun 2002 04:31:53 -0700 Received: from host-111.innovation.t1.primus.ca ([216.254.145.111] helo=neteka.com) by psg.com with smtp (Exim 3.36 #1) id 17MS4S-000393-00 for idn@ops.ietf.org; Mon, 24 Jun 2002 04:31:49 -0700 Message-ID: <01f201c21b72$1f63c890$6601a8c0@neteka.inc> From: "Edmon Chung" To: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= , "Soobok Lee" , "Dave Crocker" Cc: "IETF idn working group" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> <019801c21a14$495cecd0$2b19fea9@temp> <000e01c21b6e$23f66ce0$5205738c@LocalHost> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Mon, 24 Jun 2002 07:27:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.1 required=5.0 tests=SUBJ_HAS_Q_MARK,DEAR_SOMEBODY,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM version=2.30 X-Spam-Level: *** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit You could add .bz and .tv to the list of TLDs that allow 8bit query, although we do not use a redirection service but utilizes a dynamic CNAME mechanism to provider the requesting application with an ACE domain so the delegated host can host the domain with only the ACE RR. Edmon ----- Original Message ----- From: "tsenglm@計網中心.中大.tw" To: "Soobok Lee" ; "Dave Crocker" Cc: "IETF idn working group" Sent: Monday, June 24, 2002 6:57 AM Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) > Dear Soobok: > Your good suggestion reflects some exised facts and it > is very interesting. > The directory-for-8bit-query approach is currently used > in .CC , .NU, .TW . It is independent > on 8 bit or ASCII . The 8 bit approach is based on UTF-8 resolver of Win2k > OS . After the "*" "match to any others" , The simulated UTF-8 NS server > or a redirected A RR web server can redirect the client to get an ACE > name to do regular resolving . By the PUNY code or RACE code approach , the > nameprep are solved in the simulated DNS server side. Always, it is out of > scope in this working group to discuss equivalence comparison of non-ASCII > code point, so it is a local issue based on TLD . This approach only work > for a DNS subtree . > Even it is safe without new plug-in to client , but > there are some other problems. One is that need more effort on web proxy > servers to treat native to UTF-8 conversion . Another important > interoperability protocol issue is the virtual host of web page , that is > how to pass what kind of identifier (native , utf-8 , ACE or others) to let > a web server to act as the "virtual host" of web page and will guide the > client re-direct to the target web page. > > L.M.Tseng > > The directory-for-8bit-query approach for IDN need not be declared as > "transitional", > > rather may be independant one which may be later obsoleted smoothly by > "new class" solution. > > Non-ASCII octets in "IN" class has no defined comparison rules and that > opens > > rooms and rationales for per-registry comparison rules that can be > implementable only in > > a directory approach. > > > > Each TLD registry can decide which one it deploy among "directory" > approach, "new class", or both. > > Both can coexist for two differnt audiences with/without "new class" > supports,respectively, IMO. > > Please correct me if it is impossible or problematic. > > > > Such directory approach allows each TLD registries to adopt its own > comparison rules, thus > > non-monolithic normalization rules and works better in dealing with > charset interoperability > > and look-similar/identical character problems. Such rules or experiences > would be implementable > > as multiple registrations or normalization rules in "new class" IDN in the > future > > when stringprep,UNICODE and local charset standards become mature and > stablized. > > > > Most TLD registries feel strongly the need to add native labels in *both* > UTF8 and local charsets, > > because existing applications blindly make 8bit queries. If those > queries are not served, > > end users experience failures. Current ACE architecture requries every end > user to install > > IDN-plugins to enjoy IDN safely, but that is not the one that end users > and registries > > desperately need "right now". The directory approach can fulfill these > needs clealy and safely. > > > > Soobok Lee > > > > > > From owner-idn@ops.ietf.org Mon Jun 24 08:32:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03375 for ; Mon, 24 Jun 2002 08:31:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MSsb-00045x-00 for idn-data@psg.com; Mon, 24 Jun 2002 05:23:37 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17MSsT-00045k-00 for idn@ops.ietf.org; Mon, 24 Jun 2002 05:23:29 -0700 Received: from MASTER ([211.104.159.166]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g5OCMRD24951; Mon, 24 Jun 2002 21:22:27 +0900 Message-ID: <019501c21b79$b2f971c0$2b19fea9@temp> From: "Soobok Lee" To: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= , "Dave Crocker" Cc: "IETF idn working group" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> <019801c21a14$495cecd0$2b19fea9@temp> <000e01c21b6e$23f66ce0$5205738c@LocalHost> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Mon, 24 Jun 2002 21:21:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.8 required=5.0 tests=SUBJ_HAS_Q_MARK,DOUBLE_CAPSWORD,PORN_3,RCVD_IN_RFCI version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Thanks for your interests. My directory-for-8bit-query approach is just a short-term kludge and I hope we can prove that it serves well as a seamless migration path to NEW CLASS IDN. I hope we could publish the directory approach as a small part of the entire picture of the standardization roadmap to new class IDN which appears to require more years of research and preparations from our experienecs in this WG. I am writing a draft about the minimal specification of the directory-for-8bit-query approach which seems simple and straightforward. Most challenging part of my work, is how to prove that the roadmap is correct and would not place any obstacles in the future new class IDN efforts. My comments continues.. ----- Original Message ----- From: "tsenglm@計網中心.中大.tw" > Even it is safe without new plug-in to client , but > there are some other problems. > One is that need more effort on web proxy > servers to treat native to UTF-8 conversion . the conversion may be done on the central forwarding webserver which can gather more contexts from the incoming http requests. Some http proxy maybe strip the 8th bit off from the non-ASCII HOST: header values into ASCII ones. Even in those cases, the original hostname often can be restored by the forwarding server with simple "OR with 0x80" operations. Moreover, Hostnames may not be in UTF8 and their legacy encodings may not be explicitly specified in the http headers. Such brower behaviors have been well documented grouped by vendors , OSes and versions which context information is, fortunately , available in the incoming http request headers. > Another important > interoperability protocol issue is the virtual host of web page , that is > how to pass what kind of identifier (native , utf-8 , ACE or others) to let > a web server to act as the "virtual host" of web page and will guide the > client re-direct to the target web page. Current HTTP/1.1 is still bound to the restriction imposed by ASCII hostname rules over Host: header. Therefore, To be faithful to the current standards, the forwarding webserver SHOULD accept ASCII-only URL which contains no native-encoded IDN and no ACE hostname in my suggestion. If we assume future new class IDN will have "A,MX,NS,CNAME..." like "IN" class, IDNA and future new class IDN are mutually exclusive options. Soobok Lee From owner-idn@ops.ietf.org Thu Jun 27 12:47:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00584 for ; Thu, 27 Jun 2002 12:47:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Nc5r-000O7Y-00 for idn-data@psg.com; Thu, 27 Jun 2002 09:26:03 -0700 Received: from dove.cc.ncu.edu.tw ([140.115.17.111]) by psg.com with esmtp (Exim 3.36 #1) id 17Nc5j-000O7B-00 for idn@ops.ietf.org; Thu, 27 Jun 2002 09:25:55 -0700 Received: from LocalHost ([140.115.5.82]) (authenticated tsenglm (0 bits)) by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g5RGPYi07618 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 28 Jun 2002 00:25:35 +0800 (CST) Message-ID: <000801c21df6$d80a28e0$5205738c@LocalHost> From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= To: "Soobok Lee" Cc: "IETF idn working group" References: <5.1.0.14.2.20020621230433.02bd32d0@jay.songbird.com> <5.1.0.14.2.20020622091233.044d7ac8@jay.songbird.com> <019801c21a14$495cecd0$2b19fea9@temp> <000e01c21b6e$23f66ce0$5205738c@LocalHost> <019501c21b79$b2f971c0$2b19fea9@temp> Subject: Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt) Date: Fri, 28 Jun 2002 00:21:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=1.5 required=5.0 tests=FROM_NAME_NO_SPACES,SUBJ_HAS_Q_MARK,DEAR_SOMEBODY, DOUBLE_CAPSWORD,PORN_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dear Soobok: From: "Soobok Lee" > I am writing a draft about the minimal specification of the directory-for-8bit-query approach which > seems simple and straightforward. Most challenging part of my work, is how to prove that the roadmap is correct > and would not place any obstacles in the future new class IDN efforts. > The new class IDN means an isolated subtree of DNS with the same root , so you need an interface or some trap scheme to let different class RR can be treated by the current class with difference data type (for ex. UTF-8 or legacy encoding). It is like to use "bq--" as an explicit indicater in domain name . > > ----- Original Message ----- > From: "tsenglm@計網中心.中大.tw" > > Even it is safe without new plug-in to client , but > > there are some other problems. > > > One is that need more effort on web proxy > > servers to treat native to UTF-8 conversion . > > the conversion may be done on the central forwarding webserver which can gather > more contexts from the incoming http requests. Some http proxy maybe strip the 8th bit off from > the non-ASCII HOST: header values into ASCII ones. Even in those cases, the original > hostname often can be restored by the forwarding server with simple "OR with 0x80" operations. > Moreover, Hostnames may not be in UTF8 and their legacy encodings may not be explicitly specified > in the http headers. Such brower behaviors have been well documented grouped by vendors , OSes and versions > which context information is, fortunately , available in the incoming http request headers. > We have some 8bit pass-thru squid proxy server in our testing bed . The name from IE browser pass to proxy server port is legacy encoding via it passed thru to resolver in Win2K is UTF-8 . Althought IE has one option to always send with UTF-8 from input address bar , but it can not pass the internal range check of local native code in IE browser. The current situation is legacy encoding is valid passed thru by proxy port. Many legacy encoding is not always using leading bit in each byte (The second byte of BIG5 , JIS may be 7 bits). > > > Another important > > interoperability protocol issue is the virtual host of web page , that is > > how to pass what kind of identifier (native , utf-8 , ACE or others) to let > > a web server to act as the "virtual host" of web page and will guide the > > client re-direct to the target web page. > > Current HTTP/1.1 is still bound to the restriction imposed by ASCII hostname rules > over Host: header. Therefore, To be faithful to the current standards, > the forwarding webserver SHOULD accept ASCII-only URL > which contains no native-encoded IDN and no ACE hostname in my suggestion. > > If we assume future new class IDN will have "A,MX,NS,CNAME..." like "IN" class, > IDNA and future new class IDN are mutually exclusive options. > To be backward compatible in ASCII encoding of web servers, the directory-for-8 bit-query will need "resulting name replacement " property in client side. An ASCII URI to replace the 8bit new class name is one of the solution, the other is to use the ASCII keyword. May be the ACE encoded name is another solution. Draft of UNAME has been described the approach to let the legacy or UTF-8 character comparing without to care TC/SC and will replace 8 bit domain name to the ACE (or ASCII) identifier. L.M.Tseng From owner-idn@ops.ietf.org Fri Jun 28 06:50:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18880 for ; Fri, 28 Jun 2002 06:50:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Nt9a-0007kN-00 for idn-data@psg.com; Fri, 28 Jun 2002 03:39:02 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17Nt9V-0007kC-00 for idn@ops.ietf.org; Fri, 28 Jun 2002 03:38:58 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17832; Fri, 28 Jun 2002 06:38:10 -0400 (EDT) Message-Id: <200206281038.GAA17832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-11.txt Date: Fri, 28 Jun 2002 06:38:10 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 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 : Nameprep: A Stringprep Profile for Internationalized Domain Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-11.txt Pages : Date : 27-Jun-02 This document describes how to prepare internationalized domain name labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-nameprep-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-nameprep-11.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: <20020627150144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-nameprep-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-nameprep-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627150144.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Jun 28 06:51:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18933 for ; Fri, 28 Jun 2002 06:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Nt9p-0007ke-00 for idn-data@psg.com; Fri, 28 Jun 2002 03:39:17 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17Nt9k-0007kR-00 for idn@ops.ietf.org; Fri, 28 Jun 2002 03:39:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17878; Fri, 28 Jun 2002 06:38:25 -0400 (EDT) Message-Id: <200206281038.GAA17878@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-10.txt Date: Fri, 28 Jun 2002 06:38:25 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 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-10.txt Pages : Date : 27-Jun-02 Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called IDNA for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using the same octets used in so-called host names today. This representation allows IDNs to be introduced with no changes to the existing DNS infrastructure. IDNA is only meant for processing domain names, not free text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-idna-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-idna-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020627150225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-idna-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-idna-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627150225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Jun 28 10:27:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28213 for ; Fri, 28 Jun 2002 10:27:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NwbX-000H7s-00 for idn-data@psg.com; Fri, 28 Jun 2002 07:20:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17NwbS-000H4l-00 for idn@ops.ietf.org; Fri, 28 Jun 2002 07:20:02 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 150805 for idn@ops.ietf.org; Fri, 28 Jun 2002 09:16:51 -0500 Message-ID: <3D1C7083.60704@ehsco.com> Date: Fri, 28 Jun 2002 09:19:47 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt References: <200206281038.GAA17878@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/28/2002 5:38 AM Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-10.txt | 2. Perform the steps specified in [NAMEPREP] and fail if there is | an error. The AllowUnassigned flag is used in [NAMEPREP]. "allowunassigned" does not appear in draft-ietf-idn-nameprep-11.txt Is this the intended mechanism for allowing alternative profiles to be encoded in IDNA? I see that section 1.1 says that nameprep is mandatory: | IDNA requires that implementations process input strings with | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], | and then with Punycode [PUNYCODE]. Implementations of IDNA MUST | fully implement Nameprep and Punycode; neither Nameprep nor Punycode | are optional. Collectively this means that nameprep is still the gatekeeper, and that profiles other than nameprep cannot be encoded with IDNA. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Jun 28 10:43:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28913 for ; Fri, 28 Jun 2002 10:43:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Nwlo-000HeY-00 for idn-data@psg.com; Fri, 28 Jun 2002 07:30:44 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17NwlS-000HdJ-00 for idn@ops.ietf.org; Fri, 28 Jun 2002 07:30:23 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 150809 for idn@ops.ietf.org; Fri, 28 Jun 2002 09:27:16 -0500 Message-ID: <3D1C72F0.6040801@ehsco.com> Date: Fri, 28 Jun 2002 09:30:08 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: IDN Subject: [idn] draft-hall-dns-datatypes-00.txt Content-Type: multipart/mixed; boundary="------------090004000309030607030905" X-Spam-Status: No, hits=1.6 required=5.0 tests=TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090004000309030607030905 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've submitted the attached I-D to the draft editor but since it probably won't appear in the pool for a while... This will eventually have to be dealt with in DNSEXT but if anybody here has any substantive changes that need to be made, I'd like to get those addressed in an updated draft beforehand. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------090004000309030607030905 Content-Type: text/plain; name="draft-hall-dns-datatypes-00.txt" Content-Disposition: attachment; filename="draft-hall-dns-datatypes-00.txt" Content-Transfer-Encoding: 7bit INTERNET-DRAFT Eric A. Hall Document: draft-hall-dns-datatypes-00.txt June 2002 Expires: December 2002 Domain Name Data-Types Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines syntax and structural rules for a namespace of internationalized domain names, and also clarifies the syntax and structural rules for the existing DNS namespace. Furthermore, this document defines syntax and structural rules for specific types of labels and domain names, and also defines usage rules for specific resource records within the domain name system. This document specifically does not describe any mechanisms for interacting with these namespaces, domain names or resource records, but instead focuses exclusively on the syntax and structural rules. INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Table of Contents 1. Abstract.................................................1 2. Introduction.............................................3 3. Background and Overview..................................3 4. The Namespaces...........................................7 4.1. The Class IN Hierarchy.................................7 4.2. The DNS Namespace......................................9 4.2.1. Length Restrictions in the DNS Namespace.............9 4.2.2. Characters Restrictions in the DNS Namespace........10 4.2.3. The DNS Namespace Escape Syntax.....................11 4.3. The Internationalized Namespace.......................13 4.3.1. Length Restrictions in the i18n Namespace...........14 4.3.2. Character Restrictions in the i18n Namespace........15 5. The DNS Data-Types......................................16 5.1. Syntax Validation.....................................16 5.2. Defining New Data-Types...............................17 5.3. The Root Label and Domain Name........................18 5.4. The Hostname Labels and Domain Names..................19 5.4.1. Legacy Hostnames....................................19 5.4.2. Internationalized Hostnames.........................20 5.5. The Octet Label and Domain Name.......................21 5.6. The Mailbox Labels and Domain Names...................22 5.6.1. Legacy Mailboxes....................................23 5.6.2. Internationalized Mailboxes.........................24 5.7. The Service Locator Labels and Domain Names...........24 5.7.1. Legacy Service Locators.............................24 5.7.2. Internationalized Service Locators..................25 6. Resource Records and Query Types........................25 6.1. Resource Records......................................25 6.2. Query Types...........................................34 7. Security Considerations.................................35 8. IANA Considerations.....................................35 9. References..............................................36 10. Acknowledgements........................................38 11. Author's Address........................................39 Hall I-D Expires: December 2002 [page 2] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 2. Introduction The IDN working group has been developing mechanisms for supporting and interacting with internationalized domain names, although a prerequisite to the completion of any such work is the description of the internationalized namespace itself. During this work, it has also been determined that certain clarifications to the existing DNS namespace are also necessary. Encodings, protocols and other mechanisms for accessing domain names and resource records within the internationalized namespace are purposefully not described in this document. Discussion of this document and related work items is currently being held on the "idn@ops.ietf.org" mailing list. To join the list, send a message to with the single word "subscribe" in the body of the message. Subsequent versions of this draft will be brought to DNSEXT for standards-track development, and will be discussed on the "namedroppers@ops.ietf.org" mailing list. To join that list, send a message to with the single word of "subscribe" in the body of the message. 3. Background and Overview The Internet (and the ARPANET before it) has had a formal namespace of network resources since RFC 608 [RFC608]. Over the years, however, the syntax rules associated with the global namespace have been changed, with various updates and clarifications being provided in RFC 810 [RFC810], RFC 882 [RFC882], RFC 952 [RFC952], RFC 1034 [RFC1034], RFC 1123 [RFC1123] and RFC 2181 [RFC2181], with each revision expanding upon the namespace syntax to accommodate a more flexible usage model. The original namespace of network resources defined in [RFC608] used a flat HOSTS.TXT database as a simple list of systems and their network addresses, using a limited subset from the seven-bit US-ASCII charset [ASCII] for the system names. Essentially, the database format was the namespace, with all network services using this one-dimensional namespace for the purpose of specifying systems by name, regardless of whether these hostnames were used for intra-protocol services or for subsequent lookup operations. Hall I-D Expires: December 2002 [page 3] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 The format of the underlying database (and thus the namespace) was redefined by [RFC810] to reflect the coexistence of ARPANET and Internet networks and nodes, redefined again by [RFC952] to allow for multi-label hostnames, and updated in [RFC1123] to slightly expand the allowable character repertoire. Throughout these revisions, the syntax of the namespace was changed somewhat, although it continued to be one-dimensional in nature, reflecting the limitations of the underlying HOSTS.TXT database file. Once the Domain Name System (DNS) specifications were published (first in [RFC882] and RFC 883 [RFC883], then later in [RFC1034] and RFC 1035 [RFC1035]), the database of network resources and the hostname syntax separated into distinct entities. Although DNS uses an eight-bit syntax internally and allows any of the eight- bit codepoint values to be used for any purposes, most applications and protocols restrict their usage of the namespace to well-known data-types which only use subsets of the available namespace. This has resulted in a distinctly layered namespace, where applications and protocols use the data-type subsets, while the DNS itself uses the full range of characters. For example, [RFC1034] states that "the old rules for HOSTS.TXT should be followed" for domain names which reference host systems, and most of the application protocols have followed this advice. For all practical purposes, this means that the legacy hostname syntax is implicitly a strong data-type with formal syntax rules, even though it only represents a subset of the global DNS namespace. Meanwhile, a variety of protocol-specific data-types have also been defined for network resources which are not hosts, and these data-types have also been implemented by applications which work with those kinds of resources. In the end, the DNS namespace essentially exists as two separate layers, with the namespace at large being defined by the underlying DNS service, but with applications and protocols using the data-types and syntax rules which reflect their usage. Moving forward, the IDN working group has developed an internationalized namespace which uses characters from the Universal Character Set (UCS) [ISO-10646] (a.k.a. Unicode [UNICODE])]. Note that the UCS (and thus the namespace) only defines characters and their logical codepoint values, while external codecs are required to encode the canonical UCS characters into sequences which are suitable for specific environments. As such, the canonical UCS characters cannot be Hall I-D Expires: December 2002 [page 4] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 exchanged in their raw form, but instead can be only exchanged in their encoded form. Furthermore, there are no characters in the UCS character repertoire for "octet value 0xHH", so the internationalized namespace cannot directly support the eight-bit values used in the DNS namespace. For these reasons, the internationalized and DNS namespaces have to be defined and managed separately, with the internationalized namespace representing logical UCS characters, and with the DNS namespace representing raw and uninterpreted eight-bit values. However, these namespaces can coexist within the class IN database hierarchy as long as the underlying domain names are encoded in a compatible and consistent form. At that point, the only substantive difference between the two namespaces is in the canonical characters which are used by the presentation-layer namespaces at large. Cumulatively, this means that the internationalized namespace operates at three distinct layers. First of all, applications and protocols have to choose an internationalized data-type which is capable of supporting the characters they need for their domain names, while the protocols also have to choose the encoding formats they will use for the domain names that they exchange. Meanwhile, the end-system applications may need to use another encoding format whenever they map these domain names to the available lookup service(s). | HOSTS.TXT | DNS Names | IDNs | --------------+---------------+---------------+---------------+ Application | database | protocol | data-type | Presentation | subset | subset | specific | | | | (UCS range) | --------------+---------------+---------------+---------------+ Protocol | database | data-type | protocol | Transfer | subset | specific | encoding | | | (7- or 8-bit) | (7- or 8-bit) | --------------+---------------+---------------+---------------+ Subsequent | HOSTS.TXT | 8-bit DNS | 8-bit DNS | Lookups | subset | or HOSTS.TXT | or HOSTS.TXT | | | subset | subset | --------------+---------------+---------------+---------------+ Figure 1: Logical namespace layers and their representations. The different models which have been described in this section are illustrated in Figure 1 above. As can be seen, the hostname syntax Hall I-D Expires: December 2002 [page 5] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 defined for use with the HOSTS.TXT database essentially provided a monolithic and one-dimensional namespace for applications to use, while the DNS namespace provides multiple data-types for applications and protocols to use, with these data-types representing logical subsets of the underlying eight-bit namespace. Finally, the internationalized namespace also uses logical data-types for the applications and protocols, but also requires that protocols define encoding formats for the domain names they use internally, and for the domain names they pass to the underlying lookup services. Collectively, there are a variety of different data elements discussed above which require definitions or clarifications. Originally, this document was only meant to provide definitions for the internationalized namespace and its associated data-types, although several issues with the DNS namespace and data-types have also been encountered which require clarifications and definitions of their own. In particular, since the internationalized namespace is unable to use the eight-bit codepoint values from the DNS namespace, the legacy hostname data-type must be defined with an explicit syntax and its usage must be restricted to specific scenarios in order for those domain names to be accessible from the internationalized namespace. Subsequently, this requires that DNS resource records also be redefined to use the data-types which are appropriate to the data they represent, thereby ensuring that host resources in the common hierarchy are always accessible to both namespaces. On the surface, some of this work may appear to be a reversal of existing standards, since the DNS specifications and the clarifications made in [RFC2181] explicitly allow eight-bit codepoint values to be used with any domain name. In truth, however, this redefinition is a codification of existing practices and recommendations. Specifically, this document encourages applications to define their own data-types and syntax rules when needed but also requires that the common hostname syntax be supported in those places where hosts are specifically referenced, which is essentially a restatement of the [RFC1034] requirements. The only real difference here is that this document also requires that resource records be explicitly restricted to use the appropriate data-types, rather than being allowed to diverge at will. While this is a reversal of policy as defined in [RFC2181], this is necessary in order to ensure basic interoperability across the different namespaces, and is also necessary in order to Hall I-D Expires: December 2002 [page 6] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 prevent basic interoperability problems from developing due to fragmentation of the class IN hierarchy. 4. The Namespaces Conceptually, the DNS namespace and the internationalized namespace are separate, in that they allow for different ranges of characters, with the namespaces containing different identifiers. However, both of the namespaces reside in the class IN hierarchy and share a common root in that class, and are effectively the same namespace when the identifiers have been encoded into a compatible and consistent form. Applications and protocols which specifically utilize any of the data-types defined in this document MUST conform to the syntax rules associated with the parent namespace for that data-type. For example, if an application specifically claims to support the internationalized hostname data-type then that application MUST conform to the requirements associated with the internationalized namespace at large, while applications which claim to conform to the legacy mailbox data-type MUST conform to the requirements of the DNS namespace. If a protocol supports some other external namespace (such as LDAP directories), then the syntax rules for that protocol SHOULD define specific handling rules which clearly state how that protocol will use each of the namespaces defined here. 4.1. The Class IN Hierarchy The IN class use a hierarchical structure, where each domain name is represented by a series of labels, and where the entire sequence of labels represents a globally-unique domain name in the hierarchy. Essentially, the IN class hierarchy represents the database portion of the DNS, and therefore represents the storage, transfer and processing services which are used to construct the DNS namespace. Note that the namespace syntax (such as length and character restrictions) is discussed separately in section 4.2. Also note that alternative classes may have their own structural rules which are different from those used in the IN class. When a domain name from the IN class is used in the DNS, the constituent labels are typically treated as binary sequences (but not always), with each label being prefaced by a length indicator. Hall I-D Expires: December 2002 [page 7] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 The labels are ordered from right-to-left, with the least-specific label at the right edge of the domain name, and with the most- specific labels at the left edge. The right-most label will have a length indicator with the value of zero (it is truly a null label), and represents the root of the class IN hierarchy which is by definition the least-specific label in the hierarchy. When a domain name is used for lookups, the entire sequence of labels act as a lookup key against a globally-distributed hierarchy of database partitions and their leaf-nodes. Some or all of the labels will identify a specific database partition in the hierarchy, while any remaining labels will identify a particular leaf-node within a partition. As a lookup is processed, the input domain name is matched against the contents of the current partition, with the results of this comparison operation either being a referral to another partition, an answer, or an error. If a referral is returned, the matching process is restarted at the referenced partition, with this process repeating until either an answer or an error is returned. Domain names from the DNS namespace which are written out in longhand form are usually written as character sequences, with the labels typically being separated by a Full-Stop character (0x2E) from [ASCII]. When used with longhand domain names in the internationalized namespace, the separator mark is either a trailing Full-Stop (U+002E), an Ideographic Full-Stop (U+3002), an Ideographic Full-Width Full-Stop (U+FF0E), or an Ideographic Half- Width Full-Stop (U+FF61) from the UCS. When any of the ideographic forms are used, they MUST be converted to the traditional Full- Stop character when the domain name labels are normalized, and MUST NOT be exchanged with other applications or protocols in their provided form. Although the separator frequently appears to represent the length indicators in the domain name system, this is not always true. For example, domain names which are written out in longhand form do not typically use a Full-Stop character at the beginning of the domain name to represent the length indicator from the first label, nor do they typically provide a trailing Full-Stop character to represent the root of the hierarchy. Outside of the domain name system, domain names are typically treated as simple identifiers, with no database context being implied. Humans normally treat domain names as simple identifiers of named network resources, without concern for the leaf-node or partitions which may be referenced. Meanwhile, most applications Hall I-D Expires: December 2002 [page 8] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 and protocols also treat domain names as simple identifiers, although many of them apply syntactical analysis to the domain name before performing any additional processing (even in these situations, however, the domain name will not normally be analyzed for database context). Note that a one-to-one match between labels, partitions and leaf- nodes is neither required nor implied. Multiple labels may be used to refer to a partition or a leaf-node, as desired. In most cases, the specific database context of a domain name cannot be determined without querying DNS directly. 4.2. The DNS Namespace These rules represent the allowable syntax of all domain names within the IN class hierarchy as defined by [RFC1034] and [RFC1035]. Alternative classes may define their own namespaces and rules. Subsets of these rules are defined for specific labels and domain names in section 5. The rules provided in this section specifically apply to the DNS namespace at large, and do not define any formal data-types. 4.2.1. Length Restrictions in the DNS Namespace A label from the DNS namespace is restricted to a minimum of one octet and a maximum of 63 octets, inclusive. A domain name from the DNS namespace is restricted to a minimum of one octet and a maximum of 255 octets, inclusive. Any number of labels may be provided in a domain name, but the maximum length restriction MUST NOT be exceeded. Note that many delegation bodies have defined their own minimum length rules for their zones. For example, the historic generic top-level domains (such as com, net and org) require a minimum of two characters for all immediate delegations, while some of the newer generic TLDs have three- and four-character minimums. Since these rules only affect the delegations within those zones (and not the subordinate delegations from the child zones), this usage is not in conflict with any of the other rules defined in this document, and is expressly allowed. Whenever a domain name is written in longhand form, it SHOULD be restricted to a maximum length which allows a direct conversion to Hall I-D Expires: December 2002 [page 9] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 the DNS format. In particular, a longhand domain name SHOULD allow a length indicator to be added to the first label in the DNS domain name, and SHOULD allow a length indicator to be added to the end of the domain name (representing the root domain), if necessary. In the common case, a longhand domain name will only allow for 253 octets of data so that it can be directly converted to the DNS format. If a longhand domain name uses the escape syntax described in section 4.2.3, the allowable length of the longhand domain name MAY be extended to accommodate the escape sequence, since a multi- byte escape sequence will generally collapse to a single octet in the DNS message. Applications and protocols which need to specify the root domain explicitly MUST allow a single Full-Stop character to be specified in the longhand domain name for this purpose. Other application- or protocol-specific syntaxes MAY also be supported for this purpose, if necessary. Note that this usage is not required to be supported unless the application needs to explicitly reference the root domain for some purpose, but since the root domain is not addressable as a host system, this is not a common scenario. 4.2.2. Characters Restrictions in the DNS Namespace The lower seven-bit range of values (0x00 through 0x7F) from the DNS namespace MUST be interpreted as characters from [ASCII]. The eight-bit range of values (0x80 through 0xFF) are defined in [RFC1034] as opaque octets, with no default character assignments. Therefore, eight-bit values from the DNS namespace MUST NOT be interpreted as any specific charset, characters or encoding, and SHOULD NOT be rendered as such unless the protocol in use has defined a specific data-type which explicitly states otherwise. When a domain name from the DNS namespace is stored, transferred or compared, the capitalization of the [ASCII] characters in that domain name MUST be preserved as they were provided to the current operation. Secondarily, whenever two domain names from the DNS namespace are compared, the [ASCII] characters in the domain names MUST be treated as case-neutral for the purposes of comparison. Note that these rules combine such that the capitalization of the input domain name will be preserved across a search operation. For example, the search input of "A.example.COM" MUST match the stored Hall I-D Expires: December 2002 [page 10] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 domain name of "a.EXAMPLE.com", and the capitalization of the input domain name MUST be used for the resulting output. However, if the queried domain name referenced "HOST.c.EXAMPLE.net", that domain name MUST be provided in its original capitalization. In those scenarios where the input and output domain names are different but they exist in the same branch of the class IN hierarchy, the secondary references to the common domains MUST inherit the capitalization of the input domain name. For example, if the search input of "A.example.COM" matches with "a.EXAMPLE.com" but that domain name only exists as an alias for the domain name of "HOST.b.EXAMPLE.com", then the output domain name MUST be provided as "HOST.b.example.COM", with the capitalization of the input domain name being used to construct the overlapping domain names in the output. These rules guarantee that the output from the compression algorithm defined in [RFC1035] is always valid. Unless a protocol specifically states otherwise, these rules MUST be followed for all applications and protocols which use domain names and labels from the DNS namespace as specific data. 4.2.3. The DNS Namespace Escape Syntax Although DNS uses raw eight-bit codepoint values, less than half of the codepoint values have defined character equivalents from [ASCII] which can be rendered, which means that most of the codepoint values cannot be written in a longhand domain name which supports those values. For example, the octet label data-type supports 256 possible codepoint values (0x00 through 0xFF), while the mailbox label data-type supports all 128 of the seven-bit character codes defined in [ASCII] (0x00 through 0x7F), but only the printable subset of characters from [ASCII] have defined character representations (0x21 through 0x7E). As such, longhand domain names which use these data-types are generally restricted to the printable subset. Furthermore, some of these domain names make use of characters which are "confusing" to applications and/or their resolvers. For example, many email addresses make use of the Full-Stop character within the local-part element, although this character can easily be misinterpreted as a label separator rather than an embedded Full-Stop character. Hall I-D Expires: December 2002 [page 11] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 [RFC1035] defined a syntax for escaping these characters within the zone database, but it does not require (nor imply) that this mechanism should be supported in other applications, with the result being that most of these applications do not adequately support the necessary syntax. This document corrects this shortcoming by requiring that any application which supports the octet label or mailbox label data-types MUST allow longhand domain names to use the escaping syntax defined herein. Note that these syntax rules only apply to the octet label and mailbox label data-types. The remaining data-types have tighter character ranges, and do not contain characters which require escaping. Furthermore, applications MUST NOT allow these other data-types to use the escaping syntax whatsoever, as this could result in unexpected characters being inserted into the label or domain name, thereby triggering unexpected failures in other applications or systems. The escape syntax uses the Reverse-Solidus (0x5C) character as an escape flag, with this flag preceding a printable [ASCII] character or a three-digit decimal value for a specific codepoint value. For example, if a label contains an embedded Full-Stop character, that character may be escaped as either "\." or "\046" (where "46" is the decimal value of the Full-Stop character's codepoint value from [ASCII]). This escape syntax MUST be used to encapsulate Full-Stop (0x2E), Reverse-Solidus (0x5C), Double-Quote (0x22), a non-printing character from [ASCII] (0x00 through 0x20, or 0x7F) or any of the eight-bit codepoint values (0x80 through 0xFF) whenever one of these domain names is written in longhand form. Protocols which exchange the octet or mailbox data-types as textual data MUST support the use of this escaping syntax within that data. Other application- or protocol-specific syntaxes MAY also be supported for this purpose, if necessary. However, DNS messages MUST NOT contain the escape sequences, and MUST always use the raw octet value of the escaped character. As such, the escape syntax MUST be interpreted by an application or a resolver (depending on the resolver's capabilities) before these characters are passed into DNS. Hall I-D Expires: December 2002 [page 12] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 4.3. The Internationalized Namespace These rules represent the allowable syntax of all domain names within the internationalized IN class namespace. Alternative classes may define their own namespaces and rules. Subsets of these rules are defined for specific labels and domain names in section 5. Conversely, the rules provided in this section apply to the internationalized namespace at large, and do not define any formal data-types. Note that the internationalized namespace is a logical namespace, and does not exist in the same way that the DNS namespace exists. Instead of being a direct mapping to the underlying database, the internationalized namespace is defined as a range of UCS character codes which may be accessed or represented with any of several different encoding mechanisms. Mechanisms which have been discussed for this purpose include codecs that convert the UCS character codes into seven-bit [ASCII] sequences compatible with the legacy hostname syntax, UCS transfer encodings such as UTF-8, and legacy charsets which can be mapped to the UCS repertoire. Any of these mechanisms (or any others) can be used to represent, store, transfer and compare domain names in the internationalized namespace, as is necessary for the application or protocol at hand. For example, an internationalized protocol may use UTF-8 domain names as protocol data or arguments, although it may be necessary to convert a domain name into a hostname-compatible encoding whenever a lookup operation is performed. In this scenario, the logical internationalized namespace will be accessed through two different mechanisms, although the canonical domain name will still be represented as the UCS characters. Similarly, conversion between two or more access mechanisms will likely require an intermediate conversion to UCS first, and in this regard, the canonical UCS characters will represent the logical namespace. Note that this document does not define or describe any codecs or namespace-access mechanisms. However, these different mechanisms have affected the structure and syntax rules of the internationalized namespace at large. Hall I-D Expires: December 2002 [page 13] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 4.3.1. Length Restrictions in the i18n Namespace For the purposes of defining boundary conditions, a label in the internationalized namespace is restricted to a minimum of one UCS character and a maximum of 63 UCS characters, while a domain name in the internationalized namespace is restricted to a maximum of 255 UCS characters, inclusive. Note that this rule specifically refers to the canonical UCS characters, rather than any encoded form. Encoding will often result in labels and domain names with a fewer or greater number of octets, depending on the encoding algorithm in use. For example, an application which uses UCS-4 to represent internationalized domain names will require 32 bits for each UCS character, while an application which uses UTF-8 can require up to 48 bits for each character. The canonical UCS characters will frequently require conversion into a transfer encoding which will be subject to its own length requirements. For example, the ASCII-compatible encoding mechanism defined in [PUNYCODE] and [IDNA] is subject to the length restrictions inherent in the DNS namespace. Although all encodings have their own requirements, [IDNA] is the only encoding which is known to have hard limits beyond its control. As such, labels in the internationalized namespace MUST be restricted to lengths which can be encoded in their [IDNA] encoded form, with the resulting sequence being limited to the DNS namespace restrictions defined in section 4.2.1. This rule MUST be enforced regardless of any other codecs or access mechanisms which may be available that offer larger sizes. These rules combine so that an application can restrict the input of a label or domain name (such as in a form) to a certain number of characters, but once the internationalized domain name has been provided and normalized into its canonical form, any subsequent verification of that domain name MUST ensure that the [IDNA] encoded form of that domain name will comply with the DNS namespace limits, which is a maximum of 63 octets for a label, and 255 octets for a domain name. As with the DNS namespace, domain names written in longhand form MUST leave room for any omitted length indicators when these boundary conditions are tested. In particular, this includes the length indicator at the beginning of the first label and the length indicator at the end of the domain name, both of which are frequently omitted from longhand domain names. Hall I-D Expires: December 2002 [page 14] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 4.3.2. Character Restrictions in the i18n Namespace The logical internationalized namespace uses the entire UCS, including character codes which are currently unassigned. Currently the UCS occupies a 21-bit range of character code values, containing tens of thousands of assigned characters, and hundreds of thousands of unassigned characters, although this repertoire is expected to grow in size over time. Internationalized label and domain name data-types MUST declare their own specific ranges of supportable UCS characters, and MUST also define any normalization, case-conversion, and any other transformations which are needed for that data-type. The guidelines and rules for the development of these internationalized domain name data-types are provided in STRINGPREP [STRINGPREP]. In the normal scenario, the data-type rules will result in labels and domain names containing case-specific, strongly-normalized UCS characters. As a result, the internationalized namespace is case- specific, meaning that all storage, transfer, comparison and conversion operations MUST always preserve the capitalization and normalization of the data as it is processed. Since the domain name provided to the original application can be significantly different from the domain name which is subsequently passed to the underlying protocol, the original domain name MUST NOT be provided to any other applications or protocols if at all possible. Note that certain situations are unavoidable, such as a user copying the hostname from a manually-entered URL into an email message, where the original sequence will not reflect any subsequent normalization. However, this type of bleed-over MUST NOT occur if it can be presented by an application with simple measures. If a label ONLY contains character codes from the seven-bit [ASCII] range of characters (U+0000 through U+007F), then that label MUST be treated as a legacy label from the DNS namespace for the purposes of comparison. In other words, labels which only contain seven-bit [ASCII] MUST be compared as case-neutral sequences, while all other labels MUST be compared as case-exact sequences. In all situations, the output capitalization MUST reflect the capitalization of the input domain name (since these labels will have been capitalized and normalized according to Hall I-D Expires: December 2002 [page 15] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 their domain name syntax rules, the answer data will also be provided in the appropriate form if this rule is always followed). 5. The DNS Data-Types As part of the efforts towards strongly defining strict data- types, this document defines syntax rules for different kinds of domain names and labels. Some of the domain name data-types will only contain labels of a single data-type, while some domain name data-types may contain multiple label data-types. For example, a legacy hostname domain name can only contain legacy hostname labels, while an internationalized service locator domain name can contain a mix of different label types. When one of the internationalized data-types is used with an internationalized protocol, one or more encoding syntaxes MUST be specified by the underlying protocol before the data can be exchanged in a meaningful form. Note that RFC 2277 [RFC2277] states that the preferred encoding for internationalized protocol data is UTF-8. When one of the internationalized data-types is used with a legacy protocol which only has explicit support for [ASCII], the internationalized data-type MUST be encoded into an ASCII- compatible form before the data can exchanged. The [IDNA] specification describes one such mechanism, and is the preferred encoding form whenever legacy protocols are required to be used. 5.1. Syntax Validation Each label in a domain name has specific syntax rules which reflect on the data provided in that label. Therefore, applications which validate domain names against a particular data-type SHOULD apply the appropriate syntax rules to each label, as well as validating the domain name in its entirety. While it may appear that this model is overtly ambiguous, the process of determining the appropriate syntax can be fairly simple if the data-types are consistently enforced. For example, most of the domain name data-types use relatively simple sequences of label data-types, and most applications only support a single domain name data-type for any particular protocol usage. Thus, it is a simple matter to determine if the domain name is valid by comparing it to the syntax rules for the expected usage. Hall I-D Expires: December 2002 [page 16] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 In those cases where the application or protocol allows multiple kinds of domain name to be used, it is still possible to apply some fairly simple lexical analysis to determine the domain name which is in use (a service location label is different from a hostname label, while mailbox labels and octet labels may contain specific escape sequences, and so forth). In those cases where multiple data-types are supported and the domain name data-type cannot be determined (this may happen with an application such as "dig" or "nslookup", for example), then the application MAY choose to simply validate the domain name against the relevant namespace and leave it at that. However, this level of detachment SHOULD NOT be the default behavior; applications SHOULD attempt to validate the labels and domain names to the best of their ability using the available syntax rules. Specifically, the syntax of a label SHOULD be validated whenever a resource record is added to the replication master for a zone, or whenever an application first creates a domain name for use within that application or its associated network service. These rules are specifically designed to avoid garbage-in, garbage-out syndrome. Subsequent applications and protocol end-points MAY perform syntax validation of any domain names, and specific application protocols MAY require verification by the application end-points, although this will not be required if the participating end-points have performed the necessary validation. 5.2. Defining New Data-Types Application protocols MAY define any new label or domain name data-types which are needed, although these data-types MUST conform to the rules which govern the controlling namespace, as described in section 4. Application protocols SHOULD reuse one of the hostname syntaxes if at all possible, since these syntaxes have the widest deployment, and this will facilitate faster adoption of the protocol. If a protocol needs to support a broader syntax for uses other than referring to hostnames in the DNS or internationalized namespaces, then the protocol SHOULD indicate which operations or external syntaxes require specific exceptions, and document those exception syntaxes separately if possible. For example, if a protocol is capable of using DNS and LDAP equally, this SHOULD be stated explicitly when the protocol-specific data-types are Hall I-D Expires: December 2002 [page 17] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 defined, and a subset data-type which applies specifically to DNS lookups SHOULD also be defined. 5.3. The Root Label and Domain Name Whenever the DNS message format is used to transport a domain name, [RFC1034] requires the root domain to be specified. However, most applications and protocols do not require or even allow the root domain to be specified as part of the domain names they use internally. In these cases, the applications and protocols will typically leave it up to the local resolver to fully-qualify the domain name as provided, although this process can fail and cause unexpected domain name to be used (see RFC 1535 [RFC1535] for an example and a discussion of this problem). There are two separate considerations here. First is that an application may need to fully-qualify the domain name in order to prevent misinterpretation. Secondarily, some applications and protocols require that the root domain be provided as the complete domain name, or as part of a domain name (such as a service locator domain name associated with the root zone). The root label is defined to suit both of those purposes, where this is needed. It can be used to explicitly terminate a fully-qualified domain name, and it can be used to explicitly represent the root domain as a standalone entity. In a multi-label domain name, the root label is represented by a trailing separator mark. The root label MAY be used at the end of any domain name, regardless of its data-type. In those cases where the root label is provided by itself, the separator mark will specifically represent the root domain of the class IN hierarchy. Note that the root domain is not currently defined as a host (it does not have an IP address), so it cannot currently be used as a connection identifier. Application protocols SHOULD support the use of a standalone root label as an explicit domain name, although this is specifically not required. Where a protocol defines this usage, it SHOULD NOT be a mandatory requirement for all implementations. Other application- or protocol-specific syntaxes MAY also be supported for this purpose, if necessary. Applications MUST follow the protocol-specific guidelines on this subject. Hall I-D Expires: December 2002 [page 18] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 5.4. The Hostname Labels and Domain Names Hostnames identify specific systems and zone partitions by name, and are the most widely used of all the data-types. Hostnames are used as the owner name and data values of almost all the common resource records, are used as the connection identifier for almost all protocol-specific syntaxes and generalized applications, and are used for storing system names in local hosts databases, among other purposes. Since hostnames have such a broad number of uses and potential storage formats, they also have the strictest syntax rules. A hostname is not valid unless each label and the entire domain validate successfully. 5.4.1. Legacy Hostnames A legacy hostname domain name is a sequence of one or more legacy hostname labels, with an optional root label at the end. Applications which use legacy "hostnames" as specific data-types MUST validate the hostname domain name and label sequences separately and cumulatively. Note that the syntax for legacy hostnames has undergone many subtle and varied shifts over the years, with multiple updates and revisions allowing for slightly different syntaxes. This document unifies these definitions and clarifies some ambiguities, and is to be considered the definitive reference on the definition of a valid legacy hostname label and domain name. A legacy hostname label may only contain the Hyphen (0x2D), the numerals "0" through "9" (0x30 through 0x39), the uppercase letters "A" through "Z" (0x41 through 0x5A), and the lowercase letters "a" through "z" (0x61 through 0x7A) from [ASCII]. The first and last character in a hostname label MUST NOT be a Hyphen character, but any other character sequence is valid within the confines of a hostname label. A legacy hostname domain name is a sequence of one or more legacy hostname labels. However, at least one of the labels MUST contain at least one alphabetic character (a domain name which consists entirely of numeric values has the potential to be confused with an IP address, and this rule prevents this ambiguity). A legacy hostname domain name MAY contain an optional root label at the end Hall I-D Expires: December 2002 [page 19] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 of the domain name, although this usage MUST be explicitly allowed by the application protocol in use. With the exception of the optional root label at the end of a domain name, a legacy hostname domain name MUST NOT contain any other label data-types. If any of the labels do not validate as legacy hostname labels, or if the entire domain name does not validate as a legacy hostname domain name, then the entire domain name MUST be rejected for use as a legacy hostname domain name. The length rules associated with the DNS namespace are specifically adopted as the length rules for the legacy hostname label and domain name data-types. This definition updates the definitions provided in [RFC952] and [RFC1123], which had set these lengths at different values. As such, any system which implements a HOSTS.TXT database (or a local equivalent, such as the "/etc/hosts" file on traditional UNIX systems) MUST conform to the length restrictions defined in section 4.2.1. The syntax rules defined above are somewhat tighter than the syntax allowed in [RFC2181]. However, no standards-track network services have defined hostname syntax rules to use the allowable syntax from [RFC2181]. Instead, almost all application protocols and network services use stricter rules which are highly similar to those defined here. Applications and protocols which need to support internationalized hostnames MUST use the syntax defined in section 5.4.2. Applications and protocols which need to support eight-bit octets in their domain names MUST either use the octet label syntax described in section 5.5 or define a new syntax specifically for use with that network service. In either event, new resource records are also likely to be required. 5.4.2. Internationalized Hostnames An internationalized hostname domain name is a sequence of one or more internationalized hostname labels, with an optional root label at the end. Applications MUST validate the domain name and label sequences separately and cumulatively. The syntax for internationalized hostname labels is defined in NAMEPREP [NAMEPREP], while this document defines the syntax for internationalized hostname domain names. Hall I-D Expires: December 2002 [page 20] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 The international hostname label rules defined in NAMEPREP require that a label be lowercased and normalized with Unicode normalization form KC prior to use. Due to the massive number of characters which are available for use with internationalized hostname labels, this document cannot summarize the entire set. Note that an internationalized hostname label which only contains seven-bit codepoint values from the [ASCII] range MUST also validate as a legacy hostname label, using the rules described in section 5.4.1. This is necessary in order for a label to be reusable in both namespaces. An internationalized hostname domain name is a sequence of internationalized hostname labels, with the additional requirement that at least one of the labels MUST contain a non-numeric character. An internationalized hostname domain name MAY contain an optional root label at the end of the domain name, although this usage MUST be explicitly allowed by the application protocol in use. With the exception of the optional root label at the end of a domain name, an internationalized hostname domain name MUST NOT contain any other label data-types. If any of the labels do not validate as internationalized hostname labels, or if the entire domain name does not validate as an internationalized hostname domain name, then the entire domain name MUST be rejected for use as an internationalized hostname domain name. 5.5. The Octet Label and Domain Name The DNS namespace allows labels to contain eight-bit codepoint values, although no standardized representation or interpretation of these values is defined. While [RFC2181] allows these codepoint values to be used with any domain name or label, this document restricts the usage of these values to the octet label data-type. A octet label essentially provides a direct pass-thru mapping to the underlying DNS namespace. No additional restrictions or interpretations are defined. Multiple octet labels may be used in conjunction with multiple legacy hostname labels (with an optional root label at the end of the end of the domain name) to form an octet domain name. Hall I-D Expires: December 2002 [page 21] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 The UCS character repertoire does not provide any mechanisms for specifying raw octet values, but instead only identifies characters and their codepoint values. As such, eight-bit codepoint values are not accessible to applications which use the internationalized namespace. Instead, those applications will be required to use the DNS namespace directly whenever an octet domain name contains eight-bit codes. However, if the domain name only contains seven-bit characters, then that label can be accessed from the internationalized namespace. For this reason, applications and protocols SHOULD give preference to the range of characters defined for legacy hostname labels, as this allows the domain name to be accessed from the largest number of sources. However, applications MUST allow the full eight-bit range of values to be specified if the octet domain name data-type is required for the protocol at hand, with the caveat that these labels will be inaccessible from the internationalized namespace. If a octet label contains a Full-Stop (0x2E), Reverse-Solidus (0x5C), Double-Quote (0x22), a non-printing character from [ASCII] (0x00 through 0x20, or 0x7F) or any of the eight-bit codepoint values (0x80 through 0xFF), then those characters MUST be escaped (using the syntax rules provided in section 4.2.3) whenever the domain name is written in longhand form. Any number of octet labels may be assigned to a leaf-node in the DNS namespace. However, zone delegations use NS and SOA resource records which use hostname labels, so a fully-qualified domain name outside of the root zone MUST contain at least one legacy hostname label. Since this usage allows for a variable number of octet labels, and since applications outside of the domain name system cannot determine the database context of any given label, this can result in some ambiguity. However, no standards-track network services outside of the DNS currently require the use of octets, so this is fairly narrow area. 5.6. The Mailbox Labels and Domain Names A variety of resource records make use of mailbox label and domain name data-types in order to encapsulate email addresses into the domain name system (this model allows email addresses to use the DNS compression service). Although there are no known application protocols outside of DNS which use this data-type, the label type still has to be defined for use with DNS, and is therefore defined with its own syntax in this document. Hall I-D Expires: December 2002 [page 22] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 5.6.1. Legacy Mailboxes The legacy mailbox domain name consists of a single legacy mailbox label followed by one or more legacy hostname labels. In this model, the legacy mailbox label represents the local-part element from an RFC 2822 [RFC2822] email address, while the legacy hostname labels represent the mail domain element from an [RFC2822] email address. When a legacy mailbox domain name is expanded and mapped to an [RFC2822] email address, the legacy mailbox label goes on the left of the "@" separator, while the hostname labels go on the right of the "@" separator. The local-part element is defined in [RFC2822] as being either a dot-atom or a quoted-string. The dot-atom syntax allows for a relatively complete set of [ASCII] punctuation, numbers and alphabetic characters, while the quoted-string syntax allows for nearly all of the other characters from [ASCII] (certain control characters are globally prohibited in [RFC2822], and these apply to the quoted-string syntax as well). In order to accommodate as many email addresses as possible, these characters are defined as valid for a legacy mailbox label as well. However, if a legacy mailbox label contains a Full-Stop (0x2E), Reverse-Solidus (0x5C), Double-Quote (0x22), or any non- printing character from [ASCII] (0x00 through 0x20, or 0x7F), then those characters MUST be escaped using the syntax rules provided in section 4.2.3 whenever the domain name is written out in longhand form. Note that [RFC2821] defines the maximum length of a local-part element as 64 characters, although the maximum length of a legacy label is 63 characters. As a result, not all local-parts can be supported by the legacy mailbox label. Also note that [RFC2822] also defines the syntax of a "mail domain" as the dot-atom data-type, which allows for a larger subset of [ASCII] characters than the legacy hostname data-type allows. However, [RFC2821] also requires that mail domains be queried through DNS with MX and A resource records, both of which specify host systems. As such, the dot-atom syntax has never been usable with the legacy hostname data-type for the purpose of mail routing. The requirements for stronger data-types and syntax checks defined in this document do not affect this fundamental conflict other than to highlight its presence. Hall I-D Expires: December 2002 [page 23] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 5.6.2. Internationalized Mailboxes Legacy mailbox labels MAY be used with internationalized hostname labels to form an internationalized mailbox domain name. In this model, the legacy mailbox label represents a legacy local-part, while the internationalized hostname labels represent an international mail domain. However, note that an internationalized local-part syntax has not yet been defined, and until such a time, an internationalized mailbox label syntax cannot be defined. 5.7. The Service Locator Labels and Domain Names The service locator label and domain name syntax is used to provide service-specific redirection functions for a particular domain name. This usage is specific to DNS, so it does not have general applicability outside of the domain name system, although the label type still has to be supported, and is therefore defined with its own syntax in this document. 5.7.1. Legacy Service Locators The service locator label and domain name syntax is defined in RFC 2782 [RFC2782]. In summary, a legacy service locator domain name consists of two legacy service locator labels which uniquely identify a specific network service, with the remainder of the domain name containing hostname and/or root labels. The service locator labels are identical to the legacy hostname label syntax, with the additional requirement that a service locator label MUST begin with an Underscore (0x5F) character (this usage prevents the SRV resource record's owner domain name from colliding with other owner domain names). In this model, a registered network service is assigned a _service._proto label sequence, with this sequence being appended to the left of a legacy hostname domain name. Application clients can then issue queries for the fully-qualified service locator domain name, with the resulting answer data providing indicating which hosts offer that service on behalf of the queried domain name. Hall I-D Expires: December 2002 [page 24] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Note that zone delegation requires the use of legacy hostname labels, so a fully-qualified domain name for an SRV resource record associated with a domain name outside of the root zone MUST contain at least one legacy hostname label. However, an application can also query for an SRV resource record associated with the root domain itself, and in that scenario, the fully- qualified domain name would be "_service._proto.", with the trailing separator mark explicitly representing the root domain. 5.7.2. Internationalized Service Locators Service locator labels MAY be used with internationalized hostname labels. In this model, the legacy service locator labels represent a known service associated with an international domain. Note that [RFC2277] says that protocol identifiers do not need to be internationalized. As such, there is no requirement foreseen to allow non-ASCII characters in the service locator label syntax. 6. Resource Records and Query Types This section describes the domain name data-types in use with all of the registered resource records and query-types. These definitions include the valid owner domain names for a particular kind of resource record, and also include the valid domain names for the resource record data sections. Note that each of these rules only use domain name data-types, while those data-types are defined by constituent sets of label data-types. 6.1. Resource Records Resource records may be provided in any section of a DNS message. When they are provided in the question section as the query question, they only have owner names. When they are provided in any other section, they have owner names and resource record data. All resource records have owner name syntax rules, while those resource records which also provide domain names in resource record data also have syntax rules for those domain names. All new resource records MUST be defined with syntax rules appropriate to that resource record. Hall I-D Expires: December 2002 [page 25] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: IPv4 Address Resource Record Mnemonic: A Resource Record Code: 1 Defined In: [RFC1035] Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: Name Server Resource Record Mnemonic: NS Resource Record Code: 2 Defined In: [RFC1035] Owner Name: Hostname (delegated zone partition) Resource Record Data: Hostname (authoritative server) Note: All domain delegations MUST use the hostname data-type. Resource Record Name: Mail Destination Resource Record Mnemonic: MD Resource Record Code: 3 Defined In: [RFC1035] Owner Name: Hostname (mail domain) Resource Record Data: Hostname (delivery server) Note: Obsoleted and deprecated by RFC1035 in favor of MX Resource Record Name: Mail Forwarder Resource Record Mnemonic: MF Resource Record Code: 4 Defined In: [RFC1035] Owner Name: Hostname (mail domain) Resource Record Data: Hostname (relay server) Note: Obsoleted and deprecated by RFC1035 in favor of MX Resource Record Name: Canonical Name Resource Record Mnemonic: CNAME Resource Record Code: 5 Defined In: [RFC1035] Owner Name: inherited from target owner name Resource Record Data: inherited from target owner name Note: The owner domain name and resource record data are both inherited from the target of the CNAME resource record. For example, if a CNAME resource record references an A resource record, then the owner name and the resource record data both use the Hostname domain name data-type. However, if a CNAME resource record references an SRV resource record, then the owner name and the resource record data both use the Service Locator domain name data-type. Hall I-D Expires: December 2002 [page 26] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Start-of-Authority Resource Record Mnemonic: SOA Resource Record Code: 6 Defined In: [RFC1035] Owner Name: Hostname Resource Record Data: multiple fields (see below) MNAME: Hostname (replication master server) RNAME: Mailbox (administrator's email address) SERIAL: (no domain name data-types) REFRESH: (no domain name data-types) RETRY: (no domain name data-types) EXPIRE: (no domain name data-types) MINIMUM: (no domain name data-types) Resource Record Name: Mailbox Resource Record Mnemonic: MB Resource Record Code: 7 Defined In: [RFC1035] Owner Name: Mailbox (recipient email address) Resource Record Data: Hostname (delivery server) Resource Record Name: Mail Group Resource Record Mnemonic: MG Resource Record Code: 8 Defined In: [RFC1035] Owner Name: Mailbox (original email address) Resource Record Data: Mailbox (expanded email address) Resource Record Name: Mail Rename Resource Record Mnemonic: MR Resource Record Code: 9 Defined In: [RFC1035] Owner Name: Mailbox (original email address) Resource Record Data: Mailbox (new email address) Resource Record Name: Null Resource Record Mnemonic: NULL Resource Record Code: 10 Defined In: [RFC1035] Owner Name: Legacy Octets Resource Record Data: (no domain name data-types) Hall I-D Expires: December 2002 [page 27] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Well-Known Services Resource Record Mnemonic: WKS Resource Record Code: 11 Defined In: [RFC1035] Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: Pointer Resource Record Mnemonic: PTR Resource Record Code: 12 Defined In: [RFC1035] Owner Name: inherited from target owner name Resource Record Data: inherited from target owner name Note: Although PTR resource records are most often used to provide reverse-lookup mappings, the data can be used for any domain name which needs to point to another domain name. As such, the owner name and the resource record data must both inherit the domain name data-type in use with the destination. Resource Record Name: Host Information Resource Record Mnemonic: HINFO Resource Record Code: 13 Defined In: [RFC1035] Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: Mail List Information Resource Record Mnemonic: MINFO Resource Record Code: 14 Defined In: [RFC1035] Owner Name: Mailbox (mailing list primary address) Resource Record Data: multiple fields (see below) RMAILBOX: Mailbox / Root (responsible party address) EMAILBOX: Mailbox / Root (error-handler mailbox) Note: MINFO defines an application-specific interpretation for the root domain in the resource record as an alternative to the Mailbox data-type. Hall I-D Expires: December 2002 [page 28] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Mail Exchange Resource Record Mnemonic: MX Resource Record Code: 15 Defined In: [RFC1035] Owner Name: Hostname (mail domain) Resource Record Data: multiple fields (see below) PREFERENCE: (no domain name data-types) DESTINATION: Hostname (mail server) Resource Record Name: Text Resource Record Mnemonic: TXT Resource Record Code: 16 Defined In: [RFC1035] Owner Name: Legacy Octets Resource Record Data: (no domain name data-types) Note: The TXT resource record is commonly used as a proving ground for new resource records, and this must continue to be supported. Resource Record Name: Responsible Person Resource Record Mnemonic: RP Resource Record Code: 17 Defined In: RFC 1183 [RFC1183] Owner Name: Hostname Resource Record Data: multiple fields (see below) RMAILBOX: Mailbox (responsible person contact address) DETAILS: Legacy Octets (pointer to TXT record) Note: Binding this resource record to the hostname data-type may artificially limits its usefulness, although it results in greater predictability and consistency in the internationalized namespace. Resource Record Name: AFS Database Entry Resource Record Mnemonic: AFSDB Resource Record Code: 18 Defined In: [RFC1183] Owner Name: Hostname Resource Record Data: multiple fields (see below) PREFERENCE: (no domain name data-types) DESTINATION: Hostname (AFS server) Hall I-D Expires: December 2002 [page 29] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: X.25 Number Resource Record Mnemonic: X.25 Resource Record Code: 19 Defined In: [RFC1183] Owner Name: Hostname (host) Resource Record Data: (no domain name data-types) Resource Record Name: ISDN Number Resource Record Mnemonic: ISDN Resource Record Code: 20 Defined In: [RFC1183] Owner Name: Hostname (host) Resource Record Data: (no domain name data-types) Resource Record Name: Route-Through Resource Record Mnemonic: RT Resource Record Code: 21 Defined In: [RFC1183] Owner Name: Hostname (host) Resource Record Data: multiple fields (see below) PREFERENCE: (no domain name data-types) DESTINATION: Hostname (next-hop host) Resource Record Name: OSI NSAP Address Resource Record Mnemonic: NSAP Resource Record Code: 22 Defined In: RFC 1706 [RFC1706] Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: OSI NSAP Pointer Resource Record Mnemonic: NSAP-PTR Resource Record Code: 23 Defined In: [RFC1706] Owner Name: Hostname (hexadecimal NSAP address) Resource Record Data: Hostname (host) Resource Record Name: Signature Resource Record Mnemonic: SIG Resource Record Code: 24 Defined In: RFC 2535 [RFC2535] and RFC 2931 [RFC2931] Owner Name: Hostname (?) Resource Record Data: (no domain name data-types) Hall I-D Expires: December 2002 [page 30] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Public Key Resource Record Mnemonic: KEY Resource Record Code: 25 Defined In: [RFC2535] Owner Name: Legacy Octets Resource Record Data: (no domain name data-types) Note: The owner name must be treated as unstructured, since the KEY resource record may be bound to any domain name. Resource Record Name: Pointer to X.400 Mapping Resource Record Mnemonic: PX Resource Record Code: 26 Defined In: RFC 2163 [RFC2163] Owner Name: Hostname (encoded X.400 mail domain) Resource Record Data: multiple fields (see below) RFC822-MAIL: Hostname (mail domain) X400-MAIL: Hostname (mail domain) Resource Record Name: Geographical Position Resource Record Mnemonic: GPOS Resource Record Code: 27 Defined In: RFC 1712 [RFC1712] Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: IPv6 Simple Address Resource Record Mnemonic: AAAA Resource Record Code: 28 Defined In: RFC 1886 [RFC1886] Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: Location Resource Record Mnemonic: LOC Resource Record Code: 29 Defined In: RFC 1876 [RFC1876] Owner Name: Hostname Resource Record Data: (no domain name data-types) Hall I-D Expires: December 2002 [page 31] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Next Record Resource Record Mnemonic: NXT Resource Record Code: 30 Defined In: [RFC2535] Owner Name: Legacy Octets Resource Record Data: multiple fields (see below) NEXT-OWNER: Legacy Octets (the next domain name) TYPE: (no domain name data-types) Note: The owner name must be treated as unstructured, since the NXT resource record may be bound to any domain name. Resource Record Name: Service Locator Resource Record Mnemonic: SRV Resource Record Code: 33 Defined In: [RFC2782] Owner Name: Service Locator Resource Record Data: multiple fields (see below) PRIORITY: (no domain name data-types) WEIGHT: (no domain name data-types) PORT: (no domain name data-types) TARGET: Hostname (target server) Resource Record Name: ATM Address Resource Record Mnemonic: ATMA Resource Record Code: 34 Defined In: N/A (see ATM Forum standards) Owner Name: Hostname Resource Record Data: (no domain name data-types) Resource Record Name: Naming Authority Pointer Resource Record Mnemonic: NAPTR Resource Record Code: 35 Defined In: RFC 2915 [RFC2915] Owner Name: Hostname Resource Record Data: multiple fields (see below) ORDER: (no domain name data-types) PREFERENCE: (no domain name data-types) FLAGS: (no domain name data-types) SERVICE: (no domain name data-types) REGEXPS: (no domain name data-types) REPLACEMENT: Hostname / Service Locator (see notes) Note: The domain name provided in the REPLACEMENT sub-field can reference a NAPTR, SRV or A resource record by its owner name, depending on the value of the FLAGS sub-field. Hall I-D Expires: December 2002 [page 32] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Key Exchange Resource Record Mnemonic: KX Resource Record Code: 36 Defined In: RFC 2230 [RFC2230] Owner Name: Legacy Octets (any domain name) Resource Record Data: multiple fields (see below) PREFERENCE: (no domain name data-types) DESTINATION: Hostname (key server) Note: The owner name must be treated as unstructured, since the KX resource record may be bound to any domain name. Resource Record Name: Certificate Resource Record Mnemonic: CERT Resource Record Code: 37 Defined In: RFC 2538 [RFC2538] Owner Name: Hostname Resource Record Data: (no domain name data-types) Note: The owner name must be treated as unstructured, since the CERT resource record may be bound to any domain name. Resource Record Name: IPv6 Complex Address Resource Record Mnemonic: A6 Resource Record Code: 38 Defined In: RFC 2874 [RFC2874] Owner Name: Hostname (host) Resource Record Data: (no domain name data-types) Resource Record Name: Domain Name Redirection Resource Record Mnemonic: DNAME Resource Record Code: 39 Defined In: RFC 2672 [RFC2672] Owner Name: Hostname Resource Record Data: Hostname Resource Record Name: Extended Option Resource Record Mnemonic: OPT Resource Record Code: 41 Defined In: RFC 2671 [RFC2671] Owner Name: Root Resource Record Data: (no domain name data-types) Hall I-D Expires: December 2002 [page 33] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Resource Record Name: Transaction Key Resource Record Mnemonic: TKEY Resource Record Code: 249 Defined In: RFC 2930 [RFC2930] Owner Name: Legacy Octets Resource Record Data: (no domain name data-types) Note: The owner name must be treated as unstructured, since the TKEY resource record may be bound to any domain name. Resource Record Name: Transaction Signature Resource Record Mnemonic: TSIG Resource Record Code: 250 Defined In: RFC 2845 [RFC2845] Owner Name: Legacy Octets Resource Record Data: (no domain name data-types) Note: The owner name must be treated as unstructured, since the TSIG resource record may be bound to any domain name. 6.2. Query Types Apart from the resource records defined in section 6.1 above, there are also a handful of query types. Query types are only provided in the question section of a DNS message, and do not have resource record data. However, their owner names have domain name data-types which require standardization. All new query-types MUST be defined with syntax rules appropriate to that query-type. Query Name: Incremental Transfer Query Mnemonic: IXFR Query Code: 251 Defined In: RFC 1995 [RFC1995] Owner Name: Hostname Query Name: Zone Transfer Query Mnemonic: AXFR Query Code: 252 Defined In: [RFC1035] Owner Name: Hostname Hall I-D Expires: December 2002 [page 34] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 Query Name: Mailbox Records Query Mnemonic: MAILB Query Code: 253 Defined In: [RFC1035] Owner Name: Mailbox Note: This query-type requests all of the Mailbox, Mail Group, Mail Rename and Mail List resource records associated with an email address. Query Name: Mail Transfer Records Query Mnemonic: MAILA Query Code: 254 Defined In: [RFC1035] Owner Name: Hostname Note: Obsoleted and deprecated by RFC1035 in favor of MX, but used to request all of the Mail Forwarder and Mail Destination resource records associated with a mail domain. Query Name: All Records Query Mnemonic: "*" or ALL Query Code: 255 Defined In: [RFC1035] Owner Name: Hostname 7. Security Considerations This document does not change any on-the-wire formats, and therefore does not introduce any new security risks within the affected protocols. However, it is the author's hope that by defining strict syntaxes for domain names and labels that overall security can be improved as a result of higher predictability and better development practices. 8. IANA Considerations This document requires the use of an EDNS extended label type identification code. This document uses the b000011 ELT code. Hall I-D Expires: December 2002 [page 35] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 9. References [RFC608] RFC 608, "HOST NAMES ON-LINE", M. Kudlick, January 1974. [RFC810] RFC 810, "DoD INTERNET HOST TABLE SPECIFICATION", E. Feinler et al, March 1982. [RFC882] RFC 882, "DOMAIN NAMES - CONCEPTS and FACILITIES", P. Mockapetris, November 1983. [RFC952] RFC 952, "DOD INTERNET HOST TABLE SPECIFICATION", K. Harrenstien et al, October 1985. [RFC1034] RFC 1034, "DOMAIN NAMES - CONCEPTS and FACILITIES", P. Mockapetris, November 1987. [RFC1123] RFC 1123, "Requirements for Internet Hosts -- Application and Support", R. Braden, October 1989. [RFC2181] RFC 2181, "Clarifications to the DNS Specification", R. Elz et al, July 1997. [ASCII] "ANSI X3.4-1968. USA Standard Code for Information Interchange", ANSI. [RFC883] RFC 883, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", P. Mockapetris, November 1983. [RFC1035] RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", P. Mockapetris, November 1987. [ISO-10646] "ISO/IEC 10646-1:2000. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane" and "Part 2: Supplementary Planes", ISO. [UNICODE] "The Unicode Consortium, The Unicode Standard, Version 3.0", Addison-Wesley: Reading, MA, 2000. Update to version 3.1, 2001. Update to version 3.2, 2002. [PUNYCODE] Internet-Draft, "Punycode:An encoding of Unicode for use with IDNA", A. Costello, May 2002. Hall I-D Expires: December 2002 [page 36] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 [IDNA] Internet-Draft, "Internationalizing Domain Names In Applications (IDNA)", P. Faltstrom et al, May 2002. [STRINGPREP] Internet-Draft, "Preparation of Internationalized Strings", P. Hoffman et al, May 2002. [NAMEPREP] Internet-Draft, "Nameprep: A Stringprep Profile for Internationalized Domain Names", P. Hoffman et al, May 2002. [RFC1535] RFC 1535, "A Security Problem and Proposed Correction With Widely Deployed DNS Software", E. Gavron, October 1993. [RFC2821] RFC 2821, "Simple Mail Transfer Protocol", J. Klensin, April 2001. [RFC2822] RFC 2822, "Internet Message Format", P. Resnick, April 2001. [RFC2782] RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)", A. Gulbrandsen et al, February 2000. [RFC2277] RFC 2277, "IETF Policy on Character Sets and Languages", H. Alvestrand, January 1998. [RFC1183] RFC 1183, "New DNS RR Definitions", C. Everhart et al, October 1990. [RFC1706] RFC 1706, "DNS NSAP Resource Records", B. Manning et al, October 1994. [RFC2535] RFC 2535, "Domain Name System Security Extensions", D. Eastlake, March 1999. [RFC2931] RFC 2931, "DNS Request and Transaction Signatures ( SIG(0)s )", D. Eastlake, September 2000. [RFC2163] RFC 2163, "Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)", C. Allocchio, January 1998. [RFC1712] RFC 1712, "DNS Encoding of Geographical Location", C. Farrell et al, November 1994. Hall I-D Expires: December 2002 [page 37] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 [RFC1886] RFC 1886, "DNS Extensions to support IP version 6", S. Thomson et al, December 1995. [RFC1876] RFC 1876, "A Means for Expressing Location Information in the Domain Name System", C. Davis et al, January 1996. [RFC2915] RFC 2915, "The Naming Authority Pointer (NAPTR) DNS Resource Record", M. Mealling et al, September 2000. [RFC2230] RFC 2230, "Key Exchange Delegation Record for the DNS", R. Atkinson, November 1997. [RFC2538] RFC 2538, "Storing Certificates in the Domain Name System (DNS)", D. Eastlake et al, March 1999. [RFC2874] RFC 2874, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", M. Crawford et al, July 2000. [RFC2672] RFC 2672, "Non-Terminal DNS Name Redirection", M. Crawford, August 1999. [RFC2671] RFC 2671, "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August 1999. [RFC2930] RFC 2930, "Secret Key Establishment for DNS (TKEY RR)", D. Eastlake, September 2000. [RFC2845] RFC 2845, "Secret Key Transaction Authentication for DNS (TSIG)", P. Vixie et al, May 2000. [RFC1995] RFC 1995, "Incremental Zone Transfer in DNS", M. Ohta, August 1996. 10. Acknowledgements The author made multiple attempts at avoiding this work. David Hopwood and Mark Andrews are credited with arguing that it needed to be done, and John Klensin is credited with providing helpful feedback on how it should be done. Hall I-D Expires: December 2002 [page 38] INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002 11. Author's Address Eric A. Hall ehall@ehsco.com Hall I-D Expires: December 2002 [page 39] --------------090004000309030607030905-- From owner-idn@ops.ietf.org Fri Jun 28 12:08:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03618 for ; Fri, 28 Jun 2002 12:08:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ny1u-000LRy-00 for idn-data@psg.com; Fri, 28 Jun 2002 08:51:26 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ny1l-000LRm-00 for idn@ops.ietf.org; Fri, 28 Jun 2002 08:51:17 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA15018; Fri, 28 Jun 2002 08:56:39 -0700 Message-Id: <5.1.1.2.2.20020628080040.01fee3a8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Fri, 28 Jun 2002 08:51:09 -0700 To: iesg@ietf.org From: Dave Crocker Subject: [idn] Re: Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Cc: idn@ops.ietf.org, IETF@ietf.org In-Reply-To: <200205291439.KAA19580@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM, MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:39 AM 5/29/2002 -0400, The IESG wrote: > Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by June 6, 2002. Folks, As the IDN working group record shows, the full problem space for internationalized text is broad and messy. In spite of this, IDNA is a careful, constrained response to the key requirement for internationalization of Domain Names, namely enhancement of the Domain Name character set and definition of a means to encode those characters within the current DNS infrastructure. The architectural principal for IDNA is well established, being essentially identical to the MIME Base-64 character-encoding approach. Unfortunately, the current draft specification of IDNA (-idna-10) has some deficiencies that make it incomplete for the task it is intended to perform: 1. In addition to specifying an encoding scheme, IDNA makes a formal change to the DNS, by expanding the name space from a subset of ASCII to a subset of Unicode. This change is not clearly documented in the IDNA specification. The only relevant text is buried in a definition in the Terminology section and is easily missed. Also, it is tied to IDNA, which is a particular encoding scheme for general Domain Name enhancement. 2. The IDNA specification does not provide enough detail to permit its use for the most common Domain names, which is those used in URLs and email addresses. That is, the constraints that fall under the domain name profile for "host names" are not carried through in IDNA. Although the latest draft cites STD3, it does not provide the detail for applying it to IDN. Hence a user of IDNA cannot be certain which Unicode characters are safe for use in host names and which are not. 3. The specification imposes some user interface issues onto the protocol. In particular, it defines multiple dot seperator characters, which is equivalent to creating multiple newline definitions or multiple at-sign or multiple "slash" definitions. 4. The style of the current IDNA specification makes its use as a protocol specification challenging. It is primarily tailored to programming, at the expense of direct specification of the protocol. Throughout the document there are user interface and other non-normative comments such as discussion of the IDNA working group discussion history. In the aggregate, these are at best distracting to the specification of the IDNA protocol and may even introduce ambiguities to the reader, although they could be useful compiled as separate, non-normative implementation guidance. By way of suggesting a concrete means to quickly solve these deficiencies, I have issued two Internet Drafts: and These documents are intended as enhancements to the current IDN working group documents, rather than being replacements to those documents. That is, they are offered strictly as contributions to the working group effort. The majority of the text in these drafts are taken from the latest working group draft. The salient changes were to add definition of formal domain name changes, vs. IDNA encoding changes, to complete the specification of IDN-based host name syntax, and to modifify the text to improve readability. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Fri Jun 28 21:06:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00986 for ; Fri, 28 Jun 2002 21:06:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17O6Vx-0000Eg-00 for idn-data@psg.com; Fri, 28 Jun 2002 17:55:01 -0700 To: Dave Crocker From: Dave Crocker Subject: [idn] Re: Last Call: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Cc: iesg@ietf.org, idn@ops.ietf.org, IETF@ietf.org In-Reply-To: <5.1.1.2.2.20020628080040.01fee3a8@jay.songbird.com> References: <200205291439.KAA19580@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM, MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 28 Jun 2002 17:55:01 -0700 At 08:51 AM 6/28/2002 -0700, Dave Crocker wrote: >By way of suggesting a concrete means to quickly solve these deficiencies, >I have issued two Internet Drafts: > > >and > The second citation should be: d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Jun 30 09:05:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29978 for ; Sun, 30 Jun 2002 09:05:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Oe8p-000DBG-00 for idn-data@psg.com; Sun, 30 Jun 2002 05:49:23 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17Oe8j-000DAO-00 for idn@ops.ietf.org; Sun, 30 Jun 2002 05:49:17 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g5UCnFm09083 for ; Sun, 30 Jun 2002 14:49:15 +0200 (METDST) Received: from trab.se (terra.malmo.trab.se [131.115.48.22]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g5UCnEw09079 for ; Sun, 30 Jun 2002 14:49:14 +0200 (METDST) Message-ID: <3D1EFE46.41A8B29D@trab.se> Date: Sun, 30 Jun 2002 14:49:10 +0200 From: Dan Oscarsson X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: sv, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] Problems in normalisation and matching Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After having made a close look at IDNA and stringprep I see many problems in the handling of characters in domain names. - In IDNA it says that in domain names more than one dot (full stop) must be recognized as label separator. While this might be a natural thing to do in some cases, it is much cleaner if just U+002E is allowed. It simplifies parsing a lot and is more like programmes are used to. Also there are many more dots in UCS that could as well be used. In general I can see three basic contexts for domain names: 1) free text 2) standard form in protocols 3) comparing form. In 1) free form you could write the text any way you like. In 2) the form must be normalised. Here only one "dot" should be allowed to separate labels in a domain name so one one well defined character can separate labels. Stringprep/nameprep/idna defines one normalisation that do not fit to use here. Its NFKC, lower casing and character mapping does destroy to much of the original name. NFKC has several mappings, those related to letters are mostly well but those related to other types of characters like symbols or accents are doubtfull. If symbols and accents should be allowed in domain names, they should only use NFC. NFKC is irregular in its handling of accents, some are expanded from the compact form and some are retaind in the compact form. I would recommend NFC to be used, probably with some of the elementary compatibility mappings for letters added (like U+212B to U+00E5 and all fullwidth letters to standard width). In 3) I think Stringprep/nameprep/idna goes to far. Domain names should be compared case insesitivly using simple case folding instead of full+some Turkish folding as of IDNA today. For example small letter sharp s should not be folded into ss. This would simplify domain name matching a lot and make it quicker and easier to implement. ( though we need a way to do approximative matching in programs interacting with the user. In this case small letter sharp s could be matche to ss, and other complex matching rules be used. But this should not be the normal way for DNS ). Is it good that IDNA goes to far and make people think this is the way to go? It will make it difficult to fix later on. Dan From owner-idn@ops.ietf.org Sun Jun 30 21:22:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15785 for ; Sun, 30 Jun 2002 21:22:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17OpVK-000CqL-00 for idn-data@psg.com; Sun, 30 Jun 2002 17:57:22 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17OpVF-000Cq7-00 for idn@ops.ietf.org; Sun, 30 Jun 2002 17:57:17 -0700 Received: (qmail 30434 invoked from network); 1 Jul 2002 01:01:13 -0000 Received: from bb-203-125-6-29.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.6.29) by sentosa.post1.com with SMTP; 1 Jul 2002 01:01:13 -0000 Message-ID: <00ff01c2209a$25d4ca30$ad00a8c0@JAMESSONYVAIO> From: "James Seng" To: "Dan Oscarsson" , References: <3D1EFE46.41A8B29D@trab.se> Subject: Re: [idn] Problems in normalisation and matching Date: Mon, 1 Jul 2002 08:56:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.6 required=5.0 tests=DOUBLE_CAPSWORD,RCVD_IN_RFCI version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dan, I remember the "dot issues" was extensively discussed by the Nameprep Design Team. It is decided that dots (other than U+002E) should be included because there are IMEs which generate these dots in place of the normal dots (it become a hassy to switch in and out of IME just for the dot). Now, some may say IME is out of scope but on the other hand, we really dont need to rehash a topic which have been concluded. Lets move forward. If we can agreed on the above, then the "many problems" you point out are really just misunderstanding of the Nameprep/IDNA relationships. First, the Nameprep/Stringprep is designed to handle domain names on a _per label_ basis. Before some IDNs going thru Nameprep, it is already broken up into its individual labels so Nameprep arent the place to fixed. The place where IDNs get broken down into label is in IDNA. What IDNA now specify is that to break down IDNs into their label, you look for this set of separators (U+002E, U+3002, U+FF0E, U+FF61). (See IDNA Requirement 1) Comparison is also done on a per label basis. A IDN is considered equivalent if and only if all their individual labels are equivalent. The separators during comparison is also irrelevant. (See IDNA Requirement 4) If the individual labels need to piece back together into a FQDN, then IDNA have already clearly specified that U+002E should be used. (See IDNA Requirement 2) -James Seng ----- Original Message ----- From: "Dan Oscarsson" To: Sent: Sunday, June 30, 2002 8:49 PM Subject: [idn] Problems in normalisation and matching > After having made a close look at IDNA and stringprep > I see many problems in the handling of characters in domain names. > > - In IDNA it says that in domain names more than one dot (full stop) > must be recognized as label separator. > While this might be a natural thing to do in some cases, > it is much cleaner if just U+002E is allowed. It simplifies > parsing a lot and is more like programmes are used to. > Also there are many more dots in UCS that could as well > be used. > > In general I can see three basic contexts for domain names: > 1) free text > 2) standard form in protocols > 3) comparing form. > > In 1) free form you could write the text any way you like. > > In 2) the form must be normalised. > Here only one "dot" should be allowed to separate labels > in a domain name so one one well defined character can > separate labels. > Stringprep/nameprep/idna defines one normalisation that > do not fit to use here. Its NFKC, lower casing and character > mapping does destroy to much of the original name. > NFKC has several mappings, those related to letters > are mostly well but those related to other types > of characters like symbols or accents are doubtfull. > If symbols and accents should be allowed in domain names, > they should only use NFC. NFKC is irregular in its handling > of accents, some are expanded from the compact form and some > are retaind in the compact form. > I would recommend NFC to be used, probably with some of > the elementary compatibility mappings for letters > added (like U+212B to U+00E5 and all fullwidth letters > to standard width). > > > In 3) I think Stringprep/nameprep/idna goes to far. > Domain names should be compared case insesitivly > using simple case folding instead of full+some Turkish > folding as of IDNA today. For example small letter sharp s > should not be folded into ss. > This would simplify domain name matching a lot and > make it quicker and easier to implement. > ( though we need a way to do approximative matching > in programs interacting with the user. In this case > small letter sharp s could be matche to ss, and > other complex matching rules be used. But this > should not be the normal way for DNS ). > Is it good that IDNA goes to far and make people think > this is the way to go? It will make it difficult to > fix later on. > > > Dan > > From owner-idn@ops.ietf.org Sun Jun 30 22:17:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17131 for ; Sun, 30 Jun 2002 22:17:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17OqgU-000IRv-00 for idn-data@psg.com; Sun, 30 Jun 2002 19:12:58 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17OqgL-000IRk-00 for idn@ops.ietf.org; Sun, 30 Jun 2002 19:12:49 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA31204; Sun, 30 Jun 2002 19:18:18 -0700 Message-Id: <5.1.1.2.2.20020630185702.02b2fb00@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 30 Jun 2002 19:09:49 -0700 To: "James Seng" From: Dave Crocker Subject: Re: [idn] Problems in normalisation and matching Cc: In-Reply-To: <00ff01c2209a$25d4ca30$ad00a8c0@JAMESSONYVAIO> References: <3D1EFE46.41A8B29D@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM, MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:56 AM 7/1/2002 +0800, James Seng wrote: >I remember the "dot issues" was extensively discussed by the Nameprep Design >Team. It is decided that dots (other than U+002E) should be included because >there are IMEs which generate these dots in place of the normal dots (it >become a hassy to switch in and out of IME just for the dot). This is a confuses user interface issues with protocol issues. The IETF tries to stay away from user interface standardization, even though domain names do have a human representation. User interfaces must adapt to a wide range of usability issues. Protocols are not supposed to suffer that burden. It is the job of the user interface to map whatever typing codes it chooses to, into the constrained protocol codes. The theory behind typical Internet protocols -- and most other modern protocol standards -- is that the world chooses ONE way to do a thing and everyone with other ways maps to that one way. The concern for cut-and-paste is obviously valid, but it is not the job of the IETF protocol standards to operate well within a user cut-and-paste environment. > Now, some may >say IME is out of scope but on the other hand, we really dont need to rehash >a topic which have been concluded. Lets move forward. Introducing user interface issues into a protocol design is a good way to impair interoperability, because it adds variability. That makes the protocol not work. Moving forward is a good idea. Except when it is moving backward. >The place where IDNs get broken down into label is in IDNA. James. Forgive me, but I do not understand this statement. IDNs are ALREADY series of separate labels. IDNA does not "separate" a domain name into labels. Note that IDN maintains the same kind of dot separater as the "unaware" legacy domain name world, even if it uses multiple choices for the dot character. All IDNA does is to ENCODE those separate labels into a kind of UTF-7 (that is, ACE). >Comparison is also done on a per label basis. A IDN is considered equivalent >if and only if all their individual labels are equivalent. The separators >during comparison is also irrelevant. (See IDNA Requirement 4) One bit of confusion that I did not pursue with my suggested revisions is the idea that an IDN can only be compared it its IDNA form. In terms of formal specification, this cannot be correct. If there is another encoding for IDNs, then the IDNA specification is essentially saying that such encodings must be mapped to IDNA, first, in order to do comparisons. If that is what the working group really does mean, it should be stated as part of an IDN specifications, separate from the IDNA specification, because it is another formal change to the DNS. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-idn@ops.ietf.org Sun Jun 30 23:14:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18668 for ; Sun, 30 Jun 2002 23:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17OrTE-000MPu-00 for idn-data@psg.com; Sun, 30 Jun 2002 20:03:20 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17OrT5-000MPi-00 for idn@ops.ietf.org; Sun, 30 Jun 2002 20:03:11 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA32576 for ; Sun, 30 Jun 2002 20:08:49 -0700 Message-Id: <5.1.1.2.2.20020630200153.01f048d0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 30 Jun 2002 20:03:02 -0700 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] Problems in normalisation and matching In-Reply-To: <5.1.1.2.2.20020630185702.02b2fb00@jay.songbird.com> References: <00ff01c2209a$25d4ca30$ad00a8c0@JAMESSONYVAIO> <3D1EFE46.41A8B29D@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM, MSG_ID_ADDED_BY_MTA_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk At 07:09 PM 6/30/2002 -0700, Dave Crocker wrote: >This is a confuses user interface issues with protocol issues. and it confuses my typing. sorry. The sentence was supposed to read: This confuses user interface issues with protocol issues. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850