From owner-idn@ops.ietf.org Mon Jul 1 01:20: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 BAA22203 for ; Mon, 1 Jul 2002 01:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17OtLw-0005sa-00 for idn-data@psg.com; Sun, 30 Jun 2002 22:03:56 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17OtLq-0005sP-00 for idn@ops.ietf.org; Sun, 30 Jun 2002 22:03:50 -0700 Received: from MASTER ([211.106.175.81]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g6153cD07481 for ; Mon, 1 Jul 2002 14:03:42 +0900 Message-ID: <01c201c220bc$890dd200$0101010a@temp> From: "Soobok Lee" To: References: <3D1EFE46.41A8B29D@trab.se> <5.1.1.2.2.20020630185702.02b2fb00@jay.songbird.com> Subject: Re: [idn] Problems in normalisation and matching Date: Mon, 1 Jul 2002 14:01: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=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 Copy-and-paste *operation* is not only a user interface but also a trigger to a critical system service for interprocess communications between independant applications like unix & NT-pipe or socket ,and it transfers some data from one application to the other with conversions or transcodings. Some IETF protocols (TCP/IP) are often very strict at forcing on-the-wire communication octets streams to be little-endian and big-endian. Cut-and-paste is a popular communication tool and have much more stricter rules and conventions for various data formats (images, sounds , URLs and texts ). IDN specifications can recommends special treatements of IDN or IDN-like strings in text copy&paste operation. Identifier security and integrity issue around copy-and-paste operation still is of the concern of this WG. Soobok Lee ----- Original Message ----- From: "Dave Crocker" > > 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. From owner-idn@ops.ietf.org Mon Jul 1 11:25: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 LAA11989 for ; Mon, 1 Jul 2002 11:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P2ly-0004bC-00 for idn-data@psg.com; Mon, 01 Jul 2002 08:07:26 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17P2ls-0004aw-00 for idn@ops.ietf.org; Mon, 01 Jul 2002 08:07:20 -0700 Received: (qmail 42909 invoked from network); 1 Jul 2002 15:11:13 -0000 Received: from bb-203-125-13-148.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.13.148) by sentosa.post1.com with SMTP; 1 Jul 2002 15:11:13 -0000 Message-ID: <017701c22110$e6208740$ad00a8c0@JAMESSONYVAIO> From: "James Seng" To: "Soobok Lee" , References: <3D1EFE46.41A8B29D@trab.se> <5.1.1.2.2.20020630185702.02b2fb00@jay.songbird.com> <01c201c220bc$890dd200$0101010a@temp> Subject: Re: [idn] Problems in normalisation and matching Date: Mon, 1 Jul 2002 23:06:37 +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 Right. But IETF deals mostly with wire-protocols. UI issues such as cut-and-paste should be done more at a more appropriate forum e.g. POSIX. -James Seng ----- Original Message ----- From: "Soobok Lee" To: Sent: Monday, July 01, 2002 1:01 PM Subject: Re: [idn] Problems in normalisation and matching > Copy-and-paste *operation* is not only a user interface but also a trigger to > a critical system service for interprocess communications between independant applications > like unix & NT-pipe or socket ,and it transfers some data from one application to the other > with conversions or transcodings. > > Some IETF protocols (TCP/IP) are often very strict at forcing on-the-wire communication octets streams to be > little-endian and big-endian. Cut-and-paste is a popular communication tool and have much more > stricter rules and conventions for various data formats (images, sounds , URLs and texts ). > IDN specifications can recommends special treatements of IDN or IDN-like strings in text copy&paste operation. > > Identifier security and integrity issue around copy-and-paste operation still > is of the concern of this WG. > > Soobok Lee > > ----- Original Message ----- > From: "Dave Crocker" > > > > 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. > > > > From owner-idn@ops.ietf.org Mon Jul 1 12:06:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14940 for ; Mon, 1 Jul 2002 12:06:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P3bF-0009Ys-00 for idn-data@psg.com; Mon, 01 Jul 2002 09:00:25 -0700 Received: from postel3.postel.co.kr ([211.218.145.194]) by psg.com with esmtp (Exim 3.36 #1) id 17P3b6-0009Yf-00 for idn@ops.ietf.org; Mon, 01 Jul 2002 09:00:16 -0700 Received: from MASTER ([211.106.175.81]) by postel3.postel.co.kr (8.11.0/8.11.0) with SMTP id g61G0ED12343 for ; Tue, 2 Jul 2002 01:00:14 +0900 Message-ID: <023101c22118$3c618170$0101010a@temp> From: "Soobok Lee" To: References: <3D1EFE46.41A8B29D@trab.se> <5.1.1.2.2.20020630185702.02b2fb00@jay.songbird.com> <01c201c220bc$890dd200$0101010a@temp> <017701c22110$e6208740$ad00a8c0@JAMESSONYVAIO> Subject: Re: [idn] Problems in normalisation and matching Date: Tue, 2 Jul 2002 00:59:09 +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.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 To be more specific, double-click&drag&drop mouse operation is an UI for cut&paste data transfer *system* service. This will clarify my point. It's clear that only "IDN-compliant OS" can support "IDN-aware" applictions faithfully. Soobok Lee ----- Original Message ----- From: "James Seng" To: "Soobok Lee" ; Sent: Tuesday, July 02, 2002 12:06 AM Subject: Re: [idn] Problems in normalisation and matching > Right. But IETF deals mostly with wire-protocols. UI issues such as > cut-and-paste should be done more at a more appropriate forum e.g. POSIX. > > -James Seng > > ----- Original Message ----- > From: "Soobok Lee" > To: > Sent: Monday, July 01, 2002 1:01 PM > Subject: Re: [idn] Problems in normalisation and matching > > > > Copy-and-paste *operation* is not only a user interface but also a > trigger to > > a critical system service for interprocess communications between > independant applications > > like unix & NT-pipe or socket ,and it transfers some data from one > application to the other > > with conversions or transcodings. > > > > Some IETF protocols (TCP/IP) are often very strict at forcing on-the-wire > communication octets streams to be > > little-endian and big-endian. Cut-and-paste is a popular communication > tool and have much more > > stricter rules and conventions for various data formats (images, sounds , > URLs and texts ). > > IDN specifications can recommends special treatements of IDN or IDN-like > strings in text copy&paste operation. > > > > Identifier security and integrity issue around copy-and-paste operation > still > > is of the concern of this WG. > > > > Soobok Lee > > > > ----- Original Message ----- > > From: "Dave Crocker" > > > > > > 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. > > > > > > > > From owner-idn@ops.ietf.org Tue Jul 2 02:47: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 CAA26913 for ; Tue, 2 Jul 2002 02:47:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PHBm-000My8-00 for idn-data@psg.com; Mon, 01 Jul 2002 23:31:02 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17PHBh-000Mxh-00 for idn@ops.ietf.org; Mon, 01 Jul 2002 23:30:57 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g626Utm05322 for ; Tue, 2 Jul 2002 08:30:55 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g626Usw05316; Tue, 2 Jul 2002 08:30:54 +0200 (METDST) Message-ID: <3D21489D.8D734CB2@trab.se> Date: Tue, 02 Jul 2002 08:30:53 +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] Problems in normalisation and matching Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >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) > IDNA does define how to handle labels, not complete domain names. A domain name can be used in many places and are included in many protocols. For example it is used in HTTP, SMTP and HTML. Today there exist many restrictions on "hostnames" due to simplify handling of domain names by software and make them easier to identify by users. To make this possible the restrictions do not allow normal separator characters in a name and have labels separated by ONE separator character. Now when we expand the allowed characters in a domain name, then allowed characters and syntax should follow the same rules: - The labels of a domain name is separated by "full stop" U+002E and are written from left to right with least significant label first. Other characters or display form may be used in user interfaces but have to be converted into standard form in protocols. - Separator characters like SPACE (U+0020) may not be used. (this results in that a domain name cannot use NFKC as it decomposes non-spacing accents into a space character followed by a combining accent making simple parsing difficult). It is important to separate the standard way a domain name is written in protocols from the free form way it can be written when interacting with users. In protocols we want a form that can easily be parsed and identified. Dan From owner-idn@ops.ietf.org Tue Jul 2 10: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 KAA15403 for ; Tue, 2 Jul 2002 10:54:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17POlC-000PiD-00 for idn-data@psg.com; Tue, 02 Jul 2002 07:36:06 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17POl1-000Pcl-00 for idn@ops.ietf.org; Tue, 02 Jul 2002 07:35:55 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17POkz-0007KW-00 for ; Tue, 02 Jul 2002 07:35:53 -0700 Date: Tue, 2 Jul 2002 14:35:53 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Problems in normalisation and matching Message-ID: <20020702143553.GB27906@nicemice.net> Reply-To: IETF idn working group References: <3D21489D.8D734CB2@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D21489D.8D734CB2@trab.se> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Dan Oscarsson wrote: > Now when we expand the allowed characters in a domain name, then > allowed characters and syntax should follow the same rules: > - The labels of a domain name is separated by "full stop" U+002E > and are written from left to right with least significant label > first. > Other characters or display form may be used in user interfaces > but have to be converted into standard form in protocols. IDNA says virtually nothing about how IDNs are to be represented in new protocols. New protocols can use the ASCII representation, or an unconstrained Unicode representation (like UTF-8), or can define their own more restricted representation (for example, nameprepped UTF-8 using only U+002E as separator). Although IDNA says that the other dot characters must be recognized as dots, it does not say that they must be allowed in new protocols. If a new protocol forbids the other dot characters, recognizing them as dots will be a no-op. IDNA says that old protocols must use the ASCII representation, using only U+002E as dots. There has never been a consensus on a particular non-ASCII representation for use in new protocols, and we don't need one in order to start deploying IDNA. That's why IDNA is silent on that issue. AMC From owner-idn@ops.ietf.org Wed Jul 3 04:46: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 EAA01760 for ; Wed, 3 Jul 2002 04:46:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PfYa-000IvU-00 for idn-data@psg.com; Wed, 03 Jul 2002 01:32:12 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17PfYF-000Irp-00 for idn@ops.ietf.org; Wed, 03 Jul 2002 01:31:51 -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 CAA28279; Wed, 3 Jul 2002 02:31:49 -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 g638Vmb03032; Wed, 3 Jul 2002 10:31:48 +0200 (MEST) Date: Wed, 3 Jul 2002 10:28:51 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt To: "Eric A. Hall" Cc: idn@ops.ietf.org In-Reply-To: "Your message with ID" <3D1C7083.60704@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk > | 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 Searching for "unassigned" in nameprep-11 results in: 7. Unassigned Code Points in Internationalized Domain Names If the processing in [IDNA] specifies that a list of unassigned code npoints be used, the system uses table A.1 from [STRINGPREP] as its list of unassigned code points. What is the problem? > 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. When there are additional profiles for domain names, it might makes sense to have a standards track RFC that either updates the IDNA RFC to say when the new profile can be used, or (depending on how different things would be for the new usage) it might make sense to have a standards track RFC which uses "newprep" plus punycode. But such a future doesn't mean that IDNA can bypass the requirement that nameprep applies today - removing that requirement might lead folks to believe they can do non-standard prep and still be compliant with IDNA. That would lead to non-interoperability as far as I can tell. Erik From owner-idn@ops.ietf.org Wed Jul 3 11:14:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17870 for ; Wed, 3 Jul 2002 11:14:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PlGW-000GuW-00 for idn-data@psg.com; Wed, 03 Jul 2002 07:37:56 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17PlGO-000GuJ-00 for idn@ops.ietf.org; Wed, 03 Jul 2002 07:37:48 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 151595; Wed, 03 Jul 2002 09:34:51 -0500 Message-ID: <3D230C37.2090605@ehsco.com> Date: Wed, 03 Jul 2002 09:37: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: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/3/2002 3:28 AM Erik Nordmark wrote: >> | 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 > What is the problem? Anal types like me see StudlyCapped functions and flags and expect to find them documented. Other than that, none I suppose. >> Collectively this means that nameprep is still the gatekeeper, and >> that profiles other than nameprep cannot be encoded with IDNA. > > When there are additional profiles for domain names, [...] There are already profiles described for iSCSI names and Kerberos realms. > it might makes > sense to have a standards track RFC that either updates the IDNA RFC to > say when the new profile can be used, or (depending on how different > things would be for the new usage) it might make sense to have a > standards track RFC which uses "newprep" plus punycode. Requiring new codecs for new profiles is all cost and zero benefit. What possible value is there in forcing applications to define new codecs with different outputs for their alternative names? > But such a > future doesn't mean that IDNA can bypass the requirement that nameprep > applies today - removing that requirement might lead folks to believe > they can do non-standard prep and still be compliant with IDNA. Being "compliant" with IDNA is a matter of surviving a trip through ToASCII and back. As far as I can tell, any standards-track stringprep profile which uses label sequences can meet this requirement. > That would lead to non-interoperability as far as I can tell. If an organization starts using kerberos-prep for zone delegation or addressing purposes then yes, there would be interoperability problems with the applications that decode the sequences. In fact there would be so many problems that one is left to wonder how anybody would willfully do something that stupid. On the other hand, requiring new profiles to develop new codecs imposes its own interoperability problems. EG, all forms of network data are guaranteed to be opaque to everybody until all of the codecs have been installed on every machine on the planet. You can't encode/decode Kerberos names into a local text file until you've got the codec... This would be a significant negative development towards the notion of transparency. One codec for all domain name-like profiles of stringprep should be enough. I thought we had settled this argument a couple of weeks ago. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed Jul 3 19: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 TAA12307 for ; Wed, 3 Jul 2002 19:15:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Pt8Q-0009UI-00 for idn-data@psg.com; Wed, 03 Jul 2002 16:02:06 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Pt85-0009Tx-00 for idn@ops.ietf.org; Wed, 03 Jul 2002 16:01:45 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Pt80-0008vQ-00; Wed, 03 Jul 2002 23:01:40 +0000 Date: Wed, 03 Jul 2002 19:01:29 -0400 From: John C Klensin To: Erik Nordmark cc: "Eric A. Hall" , idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt Message-ID: <191693037.1025722889@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a3 (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.8 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,PORN_3 version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, 03 July, 2002 10:28 +0200 Erik Nordmark wrote: Erik, Let me try to explain what I think Eric is trying to get at, since I think we may be suffering from a rather basic disconnect, not about what should be done, but about how standards are defined. I also think a couple of separate issues are getting intertwined, adding to the confusion. You wrote... > When there are additional profiles for domain names, it might > makes sense to have a standards track RFC that either updates > the IDNA RFC to say when the new profile can be used, or > (depending on how different things would be for the new usage) > it might make sense to have a standards track RFC which uses > "newprep" plus punycode. But such a future doesn't mean that > IDNA can bypass the requirement that nameprep applies today - > removing that requirement might lead folks to believe they can > do non-standard prep and still be compliant with IDNA. That > would lead to non-interoperability as far as I can tell. First, to repeat something I tried to say some time ago, and which I think Dave Crocker and Eric have also tried to say, although from other perspectives and in different language: * we have had fairly good success with standards whose extensibility model is "for Case X, do Y; any other cases are prohibited entirely without standards-track action" * we have had repeated bad experiences when the model is "always do Y" on the assumption that we can change that into "always do Y unless the following case arises, then do Z" with a later document. Someone always comes along and claims it is an incompatible change that will wreck his environment, since he assumed that the language meant what it said, which is that the method applies to all cases, forever. Please observe that, for Case X, these two definitions are identical: the requirement is to "do Y", without alternatives, defaults, options, etc. In either case, the text has to be reasonably clear to avoid unintentional "creative" interpretations (and to make clear that someone who applies such an interpretation is in the wrong). But there is no difference in the requirement that, for whatever names we apply IDNA today (i.e., "Case X"), nameprep is required. Properly written, the question is only about whether we can use a different profile if and when "Case Y" is adequately defined and justified. I suggest that this difference in definitional model applies equally to the "this applies to all RRs in all Classes" language we discussed a week or so ago as it does to the "profiles with IDNA" issue that prompted this thread. The issue is the same, and my recommendation is that, in both cases, we define the cases which we require and understand and the actions for them, that we prohibit any action at all in other cases, and that we specify the mechanism (e.g., our usual handwaving about "standards track documents") by which the prohibition may be relaxed. >> 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 >>... >> Collectively this means that nameprep is still the >> gatekeeper, and that profiles other than nameprep cannot be >> encoded with IDNA. This is the other issue, and it is almost separate. I think what Eric is trying to suggest is that IDNA specifies a general mechanism that could reasonably be used with other stringprep profiles for other circumstances. Perhaps he is right --e.g., it might be useful for some "directory layer" approaches-- or perhaps not. But it is almost certainly useful to avoid having two nearly-identical documents at early maturity levels on the standards track: if we discover something wrong, we would have to make synchronous changes to both. As a user and sometime-implementor, I hate such things; as an AD who might end up having to coordinate the changes, I would assume you might hate it even more. I can think of two ways to accomodate Eric's objective. The first is to put language into IDNA similar to what I've suggested above (e.g., "use nameprep for this specific list of cases, all other cases are prohibited unless this section is updated by standards-track action"). The required language might, in practice, be a little convoluted and, if you are having a problem with the probable convolutions, perhaps the other alternative would be more attractive (although I think it involves more work, which I'm reluctant to call for at this stage). That other alternative says that we define, by copying most of idn-idna-11, a new protocol document. Let's call it ur-IDNA for the time being, with a title like "A Framework for Internationalizing Names in Applications". For this purpose, it makes no assertions at all about nameprep. Instead, where nameprep is invoked today, it would say something like "apply a stringprep profile as specified by the relevant applicability document". And we slice out the DNS-specific text as well: ur-IDNA becomes simply and purely a model for taking strings in Unicode form and making them into a canonical ASCII-based encoding (and vice versa) by applying a specific set of steps. Then we create a new document, IDNAbis, from what is left over. IDNAbis defines how to handle DNS hostnames -- labels for a specific set of RRs in Class=IN. In principle, it ought to be pretty short, since its essence should be "execute ur-IDNA, using the nameprep profile" along with a specification of its applicability. It would be somewhat longer and more complicated than that in practice, since it would need to define FQDN decomposition rules. Or, to translate where I think Dan's suggestions have been heading into this context, it might invoke a decomposition profile by a separate reference. Now, while I personally don't think it would be necessary (a brief flash of optimism), if we were worried about "creativity", ur-IDNA could contain an explicit statement that the thing is application-specific and that its use for _anything_ is prohibited without an application-specific, standards-track, profile and applicability statement. That would presumably avoid any loose ends. These two (or three) documents would provide a somewhat different decomposition than the split Dave recommended. Combining both splitting models, if desired, would presumably create a lot of documents. But I wonder whether the right approach for now would be to slip the prohibition and "standards track expansion" language into idn-idna-XX, and then sort this out into a better form when the docs come up for Draft. If, of course, IESG decides to advance this work at all. Is that helpful in at least clarifying the issue? john From owner-idn@ops.ietf.org Thu Jul 4 10:52: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 KAA18806 for ; Thu, 4 Jul 2002 10:52:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q7kv-0009va-00 for idn-data@psg.com; Thu, 04 Jul 2002 07:38:49 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17Q7kr-0009vP-00 for idn@ops.ietf.org; Thu, 04 Jul 2002 07:38:45 -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 HAA21599; Thu, 4 Jul 2002 07:38:43 -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 g64Ecgb07171; Thu, 4 Jul 2002 16:38:42 +0200 (MEST) Date: Thu, 4 Jul 2002 16:37:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt To: "Eric A. Hall" Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <3D230C37.2090605@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk > There are already profiles described for iSCSI names and Kerberos realms. > Correct me if I am wrong, ut I didn't think they were going to use IDNA; neither iSCSI names or kerberos realms are domain names (they have different syntactic restrictions as far as I knpw) and IDNA is about domain names. Thus they might use punycode if they need an ASCII encoding, but not IDNA. > Requiring new codecs for new profiles is all cost and zero benefit. What > possible value is there in forcing applications to define new codecs with > different outputs for their alternative names? The "codec" is punycode, right? If not, what is your definition of "codec"? Erik From owner-idn@ops.ietf.org Thu Jul 4 11:14: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 LAA19364 for ; Thu, 4 Jul 2002 11:14:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q8Az-000AbO-00 for idn-data@psg.com; Thu, 04 Jul 2002 08:05:45 -0700 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by psg.com with esmtp (Exim 3.36 #1) id 17Q8Ah-000Ab6-00 for idn@ops.ietf.org; Thu, 04 Jul 2002 08:05:27 -0700 Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g64F4bV6025726; Thu, 4 Jul 2002 17:04:38 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 4 Jul 2002 16:05:22 +0100 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 4 Jul 2002 17:05:22 +0200 Date: Thu, 04 Jul 2002 17:04:59 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Erik Nordmark , "Eric A. Hall" cc: Erik Nordmark , idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt Message-ID: <36108454.1025802299@localhost> In-Reply-To: References: 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: 04 Jul 2002 15:05:22.0632 (UTC) FILETIME=[38365480:01C2236C] X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 2002-07-04 16.37 +0200 Erik Nordmark wrote: > Correct me if I am wrong, ut I didn't think they were going to use IDNA; > neither iSCSI names or kerberos realms are domain names (they have > different syntactic restrictions as far as I knpw) and IDNA is > about domain names. Thus they might use punycode if they need an > ASCII encoding, but not IDNA. They have done their own profiles of stringprep. See for example draft-ietf-ips-iscsi-string-prep-02.txt. paf From owner-idn@ops.ietf.org Thu Jul 4 11:27: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 LAA19583 for ; Thu, 4 Jul 2002 11:27:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q8KJ-000Aof-00 for idn-data@psg.com; Thu, 04 Jul 2002 08:15:23 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Q8KD-000AoO-00 for idn@ops.ietf.org; Thu, 04 Jul 2002 08:15: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 151888; Thu, 04 Jul 2002 10:12:19 -0500 Message-ID: <3D246681.3020602@ehsco.com> Date: Thu, 04 Jul 2002 10:15: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: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/4/2002 9:37 AM Erik Nordmark wrote: >> There are already profiles described for iSCSI names and Kerberos >> realms. > Correct me if I am wrong, ut I didn't think they were going to use > IDNA; neither iSCSI names or kerberos realms are domain names (they > have different syntactic restrictions as far as I knpw) and IDNA is > about domain names. I don't know about iSCSI but Kerberos can be used with a new RR quite effectively. Google for draft-ietf-krb-wg-krb-dns-locate-02.txt for an example of how they were using TXT RRs to determine the realm associated with a domain. Although they use TXT (this was to avoid compression which would cause case-conversion, and is avoidable through other means) but it is still a domain name and gets used to seed subsequent lookups. As to whether or not these are valid domain names, sure they are. A domain name is any series of labels that can be exchanged in a DNS message (resulting in either a referral, an answer or an error). Certainly these are more valid than the pseudo names generated with TKEY and TSIG. As to your comment that these are not domain names since they are not defined by nameprep, my position is that nameprep is misdefined. In its current form, IDNA is about i18n hostnames, and there are other kinds of domain names which can be exchanged but which cannot be represented with nameprep (see the TKEY and TSIG logical domain names again). >> Requiring new codecs for new profiles is all cost and zero benefit. >> What possible value is there in forcing applications to define new >> codecs with different outputs for their alternative names? > > The "codec" is punycode, right? If not, what is your definition of > "codec"? The IDNA codec is punycode with the IDNA prefix identifier. Without the identifier, the data is not IDNA. It's really simple: IDNA should just be a codec that generates IDNA label output from UCS input (and vice-versa) and which supports any Stringprep profile, while Nameprep should just define the i18n hostname profile. I've been saying this for two years now. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jul 4 12:41: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 MAA21010 for ; Thu, 4 Jul 2002 12:41:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q9Wc-000CmS-00 for idn-data@psg.com; Thu, 04 Jul 2002 09:32:10 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17Q9WD-000Cm4-00 for idn@ops.ietf.org; Thu, 04 Jul 2002 09:31:45 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02176; Thu, 4 Jul 2002 10:31:43 -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 g64GVgb19824; Thu, 4 Jul 2002 18:31:42 +0200 (MEST) Date: Thu, 4 Jul 2002 18:30:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt To: "Eric A. Hall" Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <3D246681.3020602@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk > I don't know about iSCSI but Kerberos can be used with a new RR quite > effectively. Google for draft-ietf-krb-wg-krb-dns-locate-02.txt for an > example of how they were using TXT RRs to determine the realm associated > with a domain. Thanks for the pointer - I could only find draft-ietf-ips-iscsi-string-prep > Although they use TXT (this was to avoid compression which > would cause case-conversion, and is avoidable through other means) but it > is still a domain name and gets used to seed subsequent lookups. The RDATA of the TXT record is a kerberos realm name according to the draft. > As to whether or not these are valid domain names, sure they are. A domain > name is any series of labels that can be exchanged in a DNS message > (resulting in either a referral, an answer or an error). Certainly these > are more valid than the pseudo names generated with TKEY and TSIG. The QNAME is clearly a domain name. The RDATA in the text record is not - it is a case sensitive realm name. Thus QNAME would be subject to nameprep when IDNA is used. TXT records are not domain name slots thus IDNA does not apply. [Note that I don't think that the use of _kerberos. names and txt records have been discussed on namedroppers, and nothing in this email should be construed as I think this is a good idea.] Thus the kerberos folks can choose to standardize I18N realm names and define a new stringprep profile (or use an existing one) and specify that this applies to their TXT records at _kerberos. I wouldn't be surprised if they wanted a profile of stringprep that does not do case folding. > As to your comment that these are not domain names since they are not What does "these" refer to? The NAME or the content of the TXT RDATA? > defined by nameprep, my position is that nameprep is misdefined. In its > current form, IDNA is about i18n hostnames, and there are other kinds of > domain names which can be exchanged but which cannot be represented with > nameprep (see the TKEY and TSIG logical domain names again). SRV is a better example since it explicitly violates the STD3 host name rules with the leading underscore. TKEY and TSIG doesn't require domain names to be outside the host name rules, nor does it require that they follow the host name rules. > >> Requiring new codecs for new profiles is all cost and zero benefit. > >> What possible value is there in forcing applications to define new > >> codecs with different outputs for their alternative names? > > > > The "codec" is punycode, right? If not, what is your definition of > > "codec"? > > The IDNA codec is punycode with the IDNA prefix identifier. Without the > identifier, the data is not IDNA. Then I don't understand why you claim that a new codec is needed for new profiles. The IDNA prefix and punycode could be used for other profiles as well. > It's really simple: IDNA should just be a codec that generates IDNA label > output from UCS input (and vice-versa) and which supports any Stringprep > profile, while Nameprep should just define the i18n hostname profile. I've > been saying this for two years now. While I understand the need for different profiles of stringprep for different types of names, identifiers, and protocol elements, I still don't see a clear case where a different profile would be required for *textual domain names*. The textual domain names that do not conform to the STD3 host name syntax rules (such as the NAME for SRV records) can be accomodated by not setting the UseSTD3ASCIIRules in IDNA. I'm concerned that having a standard which leaves the door completely open with "use any stringprep profile" is exactly the type of loose definitions that have gotten us into trouble in the past. Specifying different profiles for different usage doesn't have this problem. Erik From owner-idn@ops.ietf.org Thu Jul 4 13:28:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21660 for ; Thu, 4 Jul 2002 13:28:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QAJO-000E5n-00 for idn-data@psg.com; Thu, 04 Jul 2002 10:22:34 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17QAJE-000E4R-00 for idn@ops.ietf.org; Thu, 04 Jul 2002 10:22: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 151911; Thu, 04 Jul 2002 12:19:27 -0500 Message-ID: <3D24844E.8000705@ehsco.com> Date: Thu, 04 Jul 2002 12:22: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: Erik Nordmark CC: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.6 required=5.0 tests=DOUBLE_CAPSWORD,PORN_3 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/4/2002 11:30 AM Erik Nordmark wrote: >> Although they use TXT (this was to avoid compression which would >> cause case-conversion, and is avoidable through other means) but it >> is still a domain name and gets used to seed subsequent lookups. > > The RDATA of the TXT record is a kerberos realm name according to the > draft. From what I understand, the realm is sucked out of the TXT RR, and is then used to generate the SRV lookups. | Overview - KDC location information | | KDC location information is to be stored using the DNS SRV RR [RFC | 2052]. The format of this RR is as follows: | | Service.Proto.Realm TTL Class SRV Priority Weight Port Target | The Realm is the Kerberos realm that this record corresponds to. This is a very problematic design on multiple fronts, but I bring it up to demonstrate the point that people want to use Kerberos realm names as domain names. By the same token, people will want to store NetBIOS names in the DNS as well (see STD19). And so forth. > The QNAME is clearly a domain name. The RDATA in the text record is not > - it is a case sensitive realm name. Thus QNAME would be subject to > nameprep when IDNA is used. TXT records are not domain name slots thus > IDNA does not apply. IDNA does not apply to this model *YET*, but if they go to a custom RRtype that stored the realm then the question of using IDNA would apply. As for the qname question, note that the STD13 model would preserve the capitalization on subsequent queries, while the IDNA model will burn the capitalization during mutation if IDNA always requires nameprep. Furthermore, see draft-hall-dns-datatypes for an inventory of currently registered RRs. There are several RRs which do not use hostnames for the owner name. These kinds of uses have to be allowed for. >> The IDNA codec is punycode with the IDNA prefix identifier. Without >> the identifier, the data is not IDNA. > > Then I don't understand why you claim that a new codec is needed for > new profiles. The IDNA prefix and punycode could be used for other > profiles as well. > I'm concerned that having a standard which leaves the door completely > open with "use any stringprep profile" is exactly the type of loose > definitions that have gotten us into trouble in the past. Specifying > different profiles for different usage doesn't have this problem. Under the current wording, only the nameprep profile is allowed. I am strongly in favor of profiles. What I am specifically arguing against is the restriction in IDNA which prohibits the use of the codec with anything other than nameprep: | 2. Perform the steps specified in [NAMEPREP] and fail if there is | an error. | IDNA requires that implementations process input strings with | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], | and then with Punycode [PUNYCODE]. Nameprep is the only profile which can be used with IDNA. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jul 4 17:50: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 RAA25615 for ; Thu, 4 Jul 2002 17:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QEM9-000Kpc-00 for idn-data@psg.com; Thu, 04 Jul 2002 14:41:41 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 17QELo-000KoL-00 for idn@ops.ietf.org; Thu, 04 Jul 2002 14:41:21 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/35JjsyYF4m3P7/1rDGOjfw=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G6WF5QKW; Thu, 04 Jul 2002 17:40:32 EDT To: ehall@ehsco.com Cc: idn@ops.ietf.org Date: Thu, 4 Jul 2002 14:39:58 -0700 Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt Message-ID: <20020704.143959.160.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=0.0 required=5.0 tests=none version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Nameprep is the only profile which can be used with IDNA. > If Nameprep can exchange with many other codec, then this is not a bad idea. IDNA is enough to be the only interface with any input string. Liana ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Fri Jul 5 06:32: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 GAA16787 for ; Fri, 5 Jul 2002 06:32:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QQ4K-000C8r-00 for idn-data@psg.com; Fri, 05 Jul 2002 03:12:04 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17QQ4G-000C8g-00 for idn@ops.ietf.org; Fri, 05 Jul 2002 03:12:00 -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 DAA10035; Fri, 5 Jul 2002 03:11:58 -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 g65ABvb13023; Fri, 5 Jul 2002 12:11:57 +0200 (MEST) Date: Fri, 5 Jul 2002 10:35:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt To: "Eric A. Hall" Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <3D24844E.8000705@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD,PORN_3 version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk > From what I understand, the realm is sucked out of the TXT RR, and is then > used to generate the SRV lookups. The kerberos client needs know the (case sensitive) realm name to use it in the kerberos protocol. This must be what drives the requirement that the RDATA of the TXT not be case folded. In addition, the kerberos client can use it to form SRV lookups, but if that was the only use there would be no requirement that the RDATA preserved case. Hence the RDATA is a realm name. The realm name can be usd to form a SRV lookup. > IDNA does not apply to this model *YET*, but if they go to a custom RRtype > that stored the realm then the question of using IDNA would apply. It the RDATA in such an RR said it was a domain name, then IDNA would apply. If the RDATA in such an RR was specified to be a realm name, then IDNA would not apply. Thus in the latter case (which is what would make sense due to the sensitivity of the realm names) then the definition of such a record could choose to whatever it wants (including use realmprep and punycode with the IDNA prefix; or use realmprepped UTF-8). > As for the qname question, note that the STD13 model would preserve the > capitalization on subsequent queries, while the IDNA model will burn the > capitalization during mutation if IDNA always requires nameprep. But IDNA (ToASCII) doesn't always require nameprep; it isn't required for all-ASCII labels. So I don't understand the point about "if IDNA always requires nameprep". > Furthermore, see draft-hall-dns-datatypes for an inventory of currently > registered RRs. There are several RRs which do not use hostnames for the > owner name. These kinds of uses have to be allowed for. Agreed. Which ones do not work with IDNA in practise as IDNA is currently defined? As far as I can tell all textual labels work with IDNA and IDNA explicitly does not apply to non-textual labels. > Under the current wording, only the nameprep profile is allowed. > > I am strongly in favor of profiles. What I am specifically arguing against > is the restriction in IDNA which prohibits the use of the codec with > anything other than nameprep: > > | 2. Perform the steps specified in [NAMEPREP] and fail if there is > | an error. > > | IDNA requires that implementations process input strings with > | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], > | and then with Punycode [PUNYCODE]. > > Nameprep is the only profile which can be used with IDNA. Perhaps you could suggest alternate wording. I'd like to understand how you can state something different without resorting to "anything goes" given that there aren't other standardized (or ready to standardize) profiles to which IDNA could have a normative reference. Erik From owner-idn@ops.ietf.org Sun Jul 7 04:25: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 EAA17516 for ; Sun, 7 Jul 2002 04:25:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17R75j-0003VJ-00 for idn-data@psg.com; Sun, 07 Jul 2002 01:08:23 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17R75a-0003V2-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 01:08:14 -0700 Received: (qmail 28468 invoked from network); 7 Jul 2002 08:13:54 -0000 Received: from bb-203-125-8-173.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.8.173) by sentosa.post1.com with SMTP; 7 Jul 2002 08:13:54 -0000 Message-ID: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> From: "James Seng" To: "IETF/IDN WG" Subject: [idn] IDN WG Last Call on two major changes to Stringprep Date: Sun, 7 Jul 2002 16:06:58 +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.5 required=5.0 tests=RCVD_IN_RFCI version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IETF last call have been concluded and the latest version of Stringprep is in the I-D directory: http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt Other then editorial changes, there are two significant changes*: - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. - Additional Bidirection characters handling, Section 6 and Appendix D. The co-chairs is conducting a working group last call on these two significant changes. Please send any proposed modification of text to the wg mailing list as well as the wg co-chairs, stating clearly the text to be modified and the new text. This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. (We have a three weeks last call instead of the usual two weeks for those who is busy preparing for IETF Yokohama) Marc & James co-chairs * The previous of Stringprep can be found at http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt From owner-idn@ops.ietf.org Sun Jul 7 06:21:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18608 for ; Sun, 7 Jul 2002 06:21:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17R94u-0006PI-00 for idn-data@psg.com; Sun, 07 Jul 2002 03:15:40 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17R94q-0006P7-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 03:15:36 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g67AFYm02430 for ; Sun, 7 Jul 2002 12:15:34 +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 g67AFXw02423 for ; Sun, 7 Jul 2002 12:15:33 +0200 (METDST) Message-ID: <3D2814CD.8EC26F6B@trab.se> Date: Sun, 07 Jul 2002 12:15:41 +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] Is space allowed in a hostname? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have looked att parsing of hostname or domain name, and there are some areas I think may give problems. Today a hostname can be made of A-Z,-,0-9 and a domain name A-Z,-,0-9 and . When we go over to UCS we will have many more characters. Looking at the handling of combining code points in UCS, Unicode do not handle them in a way that will be easy to hande for many programmers. For example: SPACE which is not allowed in a ASCII hostname and should probably not be allowed in a UCS hostname, can easily be checked and parsed as a separator in ASCII. But in UCS it is possible to represent spacing accents as SPACE + combining accent. This means that the UTF-8 form may contain the SPACE code point which do not represent the SPACE character. That will make parsing much more difficult. Looking at the Unicode normalisation forms and trying IBM's ICU, NFC do not normalise SPACE + combining accent into the "spacing accent" code point. NFKC does decompose instead of compose, spacing accents. To make things a little bit easier for software handling hostnames we could forbidd all accents, or we could allow spacing accents but not "SPACE+combining accent". In short: the SPACE code point is only allowed when not followed by a combining character. While NFKC may be a good idea for matching names, it is not a good idea for normalised form of a name. NFKC removes duplicate forms of single characters (like wide A and circled A) which is good. But it also replaces code points representing many characters by many characters. In some cases that may be well (makes no semantic difference) but in others the resulting name is not the same (for example: superscript 2 (U+00B2) is replaced by character 2 (U+0032)). From what I have found out, the best normalised form of a domain name is to use NFC with the alternative code points for those LETTERS that have more than one code point forbidden, and all code point sequences that can be represented by a single code point be combined into that code point. (Note: the IDNA nampreprepped name is a form used for domain name matching. It is not the same as the normalised form above.) Dan From owner-idn@ops.ietf.org Sun Jul 7 10:10:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21607 for ; Sun, 7 Jul 2002 10:10:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RCYg-000Brm-00 for idn-data@psg.com; Sun, 07 Jul 2002 06:58:38 -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 17RCYZ-000Brb-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 06:58:31 -0700 Message-ID: <035601c225be$59962020$6501a8c0@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IETF/IDN WG" References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Date: Sun, 7 Jul 2002 09:58: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=2.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A minor change: > Other examples are > simplified Chinese spellings of names (for example, > "") vs. the equivalent traditional Chinese > spelling (for example, ""). I dont think Chinese phrases should be called "spelling". I would suggest using the word "representation" instead of "spelling" so that it makes more sense. -----Update to----- Other examples are simplified Chinese representation of names (for example, "") vs. the equivalent traditional Chinese representation (for example, ""). ----- Edmon ----- Original Message ----- From: "James Seng" To: "IETF/IDN WG" Sent: Sunday, July 07, 2002 4:06 AM Subject: [idn] IDN WG Last Call on two major changes to Stringprep > The IETF last call have been concluded and the latest version of > Stringprep is in the I-D directory: > > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt > > Other then editorial changes, there are two significant changes*: > - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. > - Additional Bidirection characters handling, Section 6 and Appendix D. > > The co-chairs is conducting a working group last call on these two > significant changes. Please send any proposed modification of text to the > wg mailing list as well as the wg co-chairs, stating clearly the text to > be modified and the new text. > > This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. > (We have a three weeks last call instead of the usual two weeks for those > who is busy preparing for IETF Yokohama) > > Marc & James > co-chairs > > * The previous of Stringprep can be found at > http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt > > > From owner-idn@ops.ietf.org Sun Jul 7 10:46: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 KAA22128 for ; Sun, 7 Jul 2002 10:46:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RDAW-000FsE-00 for idn-data@psg.com; Sun, 07 Jul 2002 07:37:44 -0700 Received: from [202.27.17.78] (helo=mars.post1.com) by psg.com with esmtp (Exim 3.36 #1) id 17RDAR-000Fs2-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 07:37:39 -0700 Received: from localhost (pobox@localhost) by mars.post1.com (8.10.2/8.10.2) with SMTP id g67EbO359961 for idn@ops.ietf.org; Sun, 7 Jul 2002 22:37:24 +0800 (SGT) Date: Sun, 7 Jul 2002 22:37:24 +0800 (SGT) Message-Id: <200207071437.g67EbO359961@mars.post1.com> X-Mailer: PostOne Client v0.1b X-Sender: jseng@pobox.org.sg From: James Seng To: "'IETF/IDN WG'" Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Please take note that this is _not_ a working group last call for Stringprep. It is a last call for the two major changes in Stringprep, namely, Unicode 3.2 and bidi. Please review these two major changes carefully. It is likely that this will be published as RFC after this last call. Thank you. -James Seng owner-idn@ops.ietf.org wrote: > A minor change: > > > Other examples are > > simplified Chinese spellings of names (for example, > > "") vs. the equivalent traditional Chinese > > spelling (for example, ""). > > I dont think Chinese phrases should be called "spelling". > I would suggest using the word "representation" instead of "spelling" so > that it makes more sense. > > -----Update to----- > Other examples are simplified Chinese representation of names (for example, > "") vs. the equivalent traditional Chinese > representation (for example, ""). > ----- > > Edmon > > > > ----- Original Message ----- > From: "James Seng" > To: "IETF/IDN WG" > Sent: Sunday, July 07, 2002 4:06 AM > Subject: [idn] IDN WG Last Call on two major changes to Stringprep > > > > The IETF last call have been concluded and the latest version of > > Stringprep is in the I-D directory: > > > > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt > > > > Other then editorial changes, there are two significant changes*: > > - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. > > - Additional Bidirection characters handling, Section 6 and Appendix D. > > > > The co-chairs is conducting a working group last call on these two > > significant changes. Please send any proposed modification of text to the > > wg mailing list as well as the wg co-chairs, stating clearly the text to > > be modified and the new text. > > > > This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. > > (We have a three weeks last call instead of the usual two weeks for those > > who is busy preparing for IETF Yokohama) > > > > Marc & James > > co-chairs > > > > * The previous of Stringprep can be found at > > http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt > > > > > > > > From owner-idn@ops.ietf.org Sun Jul 7 12:16: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 MAA24658 for ; Sun, 7 Jul 2002 12:16:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17REdJ-000ITG-00 for idn-data@psg.com; Sun, 07 Jul 2002 09:11:33 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17REcy-000ISQ-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 09:11: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 MAA24319; Sun, 7 Jul 2002 12:10:14 -0400 (EDT) Message-Id: <200207071610.MAA24319@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-uri-02.txt Date: Sun, 07 Jul 2002 12:10:14 -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 : Internationalized Domain Names in URIs Author(s) : M. Duerst Filename : draft-ietf-idn-uri-02.txt Pages : 8 Date : 05-Jul-02 This document proposes to upgrade the definition of URIs (RFC 2396) [RFC2396] to work consistently with internationalized domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-uri-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-uri-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705142136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-uri-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-uri-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142136.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sun Jul 7 13:18: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 NAA27038 for ; Sun, 7 Jul 2002 13:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RFak-000Nnf-00 for idn-data@psg.com; Sun, 07 Jul 2002 10:12:58 -0700 Received: from smtprelay1.dc3.adelphia.net ([24.50.78.4]) by psg.com with esmtp (Exim 3.36 #1) id 17RFae-000Nmc-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 10:12:52 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.189]) by smtprelay1.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GYW2HF0A.801; Sun, 7 Jul 2002 13:12:51 -0400 Message-ID: <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> From: "Doug Ewell" To: Cc: "Dan Oscarsson" References: <3D2814CD.8EC26F6B@trab.se> Subject: Re: [idn] Is space allowed in a hostname? Date: Sun, 7 Jul 2002 10:11:07 -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.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dan Oscarsson wrote: > While NFKC may be a good idea for matching names, it is not a good > idea for normalised form of a name. NFKC removes duplicate forms of > single characters (like wide A and circled A) which is good. But it > also replaces code points representing many characters by many > characters. In some cases that may be well (makes no semantic > difference) but in others the resulting name is not the same (for > example: superscript 2 (U+00B2) is replaced by character 2 (U+0032)). Does the semantic distinction between 2 and ² really need to be preserved in domain names? Suppose you have a company called Foo² ("foo-squared"). How much damage is caused if your Web site can be accessed not only through www.foo².com but also through www.foo2.com? Can it really be possible that this whole NFKC issue was not adequately considered and we need to stop everything to revisit it? -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Sun Jul 7 17:55: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 RAA07462 for ; Sun, 7 Jul 2002 17:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RJpe-0006QH-00 for idn-data@psg.com; Sun, 07 Jul 2002 14:44: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 17RJpR-0006Pu-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 14:44:25 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17RJpM-000Mfc-00; Sun, 07 Jul 2002 21:44:20 +0000 Date: Sun, 07 Jul 2002 17:44:20 -0400 From: John C Klensin To: Doug Ewell , idn@ops.ietf.org cc: Dan Oscarsson Subject: Re: [idn] Is space allowed in a hostname? Message-ID: <330302450.1026063860@localhost> In-Reply-To: <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> References: <3D2814CD.8EC26F6B@trab.se> <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07462 --On Sunday, 07 July, 2002 10:11 -0700 Doug Ewell wrote: > Does the semantic distinction between 2 and ² really need to > be preserved in domain names? Suppose you have a company > called Foo² ("foo-squared"). How much damage is caused if > your Web site can be accessed not only through www.foo².com > but also through www.foo2.com? Doug, I don't know the answer to your question, but it takes us onto a slippery slope. If that site is accessible in either of those ways, does the organization whose name is really "Foo2" have any special claims? Is it best to keep them separate so that both have a shot at their names as they really write them? And, if the answer is "no, they should be combined", how is that position ultimately different from arguing that Foo and Fo are really the same name? Does this cause a whole new variety of name dispute and dispute resolution problems? > Can it really be possible that this whole NFKC issue was not > adequately considered and we need to stop everything to > revisit it? Doug, this is more a response to Dan, since I think we may agree. But, since I think the question is too important to be brushed off... I think there is a case to be made that only a very small percentage of the WG (and still less of the IETF) has actually understood all (or most) of that decision and its consequences. The percentage is clearly rising at this late date and I always get concerned when the whole IETF seems to be taking the word of a very small number of people that a decision that may have far-reaching impact is correct. But, is it worth revisiting the decision? Much as I am concerned about the potential for damage to the Internet resulting from putting this stuff into the DNS, I haven't seen a lot of justification for going around this particular loop again. I would feel more positive about doing so had matching and mapping issues with pairs of characters not come up before, but they have and people who didn't read themselves in have to bear some of the blame. And, worse, we know enough about them to know that there aren't any fixes: if superscript "2" and "2" match, then the people who thinks they should be differentiated will scream that one can't use one's proper name. If they don't match, then people will worry, with some justification, about consumer confusion and similar problems. There is really no correct choice, or, ultimately, a non-arbitrary one, unless one concludes that _DNS_ internationalization is a bad idea and that it needs to be accomplished elsewhere. In that context, using NFKC has a huge advantage, which is that all of the essentially-arbitrary decisions are made at once; the main alternative seems to be for us to try to make our own decisions about every pair (or small group) of characters in the Unicode set. And one of the few things I'm certain about in this situation is that going down that path leads to madness. john From owner-idn@ops.ietf.org Sun Jul 7 19:02: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 TAA10028 for ; Sun, 7 Jul 2002 19:02:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RKuD-0007SJ-00 for idn-data@psg.com; Sun, 07 Jul 2002 15:53:25 -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 17RKu1-0007Rc-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 15:53:14 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g67Mr6wF031594; Mon, 8 Jul 2002 00:53:06 +0200 To: John C Klensin Cc: Doug Ewell , idn@ops.ietf.org, Dan Oscarsson Subject: [idn] Re: Is space allowed in a hostname? References: <3D2814CD.8EC26F6B@trab.se> <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> <330302450.1026063860@localhost> From: Simon Josefsson X-Hashcash: 020707:klensin@jck.com:eebd3f9a97169b27 X-Hashcash: 020707:dewell@adelphia.net:8e770239295fb793 X-Hashcash: 020707:idn@ops.ietf.org:e5c9000dcfa8e5f6 X-Hashcash: 020707:Dan.Oscarsson@trab.se:5e63328bc9e44064 Date: Mon, 08 Jul 2002 00:53:06 +0200 In-Reply-To: <330302450.1026063860@localhost> (John C Klensin's message of "Sun, 07 Jul 2002 17:44:20 -0400") Message-ID: Lines: 45 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit John C Klensin writes: >> Does the semantic distinction between 2 and ² really need to >> be preserved in domain names? Suppose you have a company >> called Foo² ("foo-squared"). How much damage is caused if >> your Web site can be accessed not only through www.foo².com >> but also through www.foo2.com? > > Doug, I don't know the answer to your question, but it takes us > onto a slippery slope. If that site is accessible in either of > those ways, does the organization whose name is really "Foo2" > have any special claims? Is it best to keep them separate so > that both have a shot at their names as they really write them? > And, if the answer is "no, they should be combined", how is that > position ultimately different from arguing that Foo and Fo are > really the same name? Does this cause a whole new variety of > name dispute and dispute resolution problems? All these questions can be asked given the current framework too. Consider a company name containing the word Mae and another containing Masse (which are distinct words with distinct meanings). These words are the same after IDN processing. So the scheme Doug is proposing is already implemented, although happens to not be canonicalized into 2. > I think there is a case to be made that only a very small > percentage of the WG (and still less of the IETF) has actually > understood all (or most) of that decision and its consequences. > The percentage is clearly rising at this late date and I always > get concerned when the whole IETF seems to be taking the word of > a very small number of people that a decision that may have > far-reaching impact is correct. > > But, is it worth revisiting the decision? Much as I am > concerned about the potential for damage to the Internet > resulting from putting this stuff into the DNS, I haven't seen a > lot of justification for going around this particular loop > again. I would feel more positive about doing so had matching > and mapping issues with pairs of characters not come up before, > but they have and people who didn't read themselves in have to > bear some of the blame. I agree, the current solution is not well understood, and there seems to be no time to revisit all issues and wait for people to understand the consequences. From owner-idn@ops.ietf.org Sun Jul 7 21:38: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 VAA16211 for ; Sun, 7 Jul 2002 21:38:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RNO9-000A7r-00 for idn-data@psg.com; Sun, 07 Jul 2002 18:32:29 -0700 To: idn@ops.ietf.org Subject: [idn] Comment on draft-hoffman-stringprep-04.txt From: Simon Josefsson Date: Fri, 05 Jul 2002 12:28:15 +0200 Message-ID: Lines: 23 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Quoting section 1.2 "Each profile MUST state the character repertoire on which the profile will operate. Appendix A lists the Unicode repertoires that can be selected." Quoting section 7 "Using two different policies for where unassigned code points can appear removes the need for versioning in protocols that use stringprep profiles. This is very useful since it makes the overall processing simpler and does not impose a "protocol" to handle versioning. It is expected that the ISO/IEC 10646 and Unicode repertoires will be updated fairly frequently; at the time that this document is being written, it has happened approximately once a year. Each time a new version of a repertoire appears, a new version of a profile MAY be created. Some end users will want to use the new code points as soon as they are defined." In section 7, one is lead to believe that profiles can chose to adopt more recent versions of the Unicode standard, but this cannot happen until stringprep itself is updated, by the MUST in section 1.2. Suggested new text in section 7: .. Each time a new version of a repertoire is offered by an updated version of this specification, a new version of a profile MAY be created. ... From owner-idn@ops.ietf.org Sun Jul 7 23:23:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20964 for ; Sun, 7 Jul 2002 23:23:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ROtd-000C7s-00 for idn-data@psg.com; Sun, 07 Jul 2002 20:09:05 -0700 Received: from smtprelay3.dc3.adelphia.net ([24.50.78.6]) by psg.com with esmtp (Exim 3.36 #1) id 17ROtJ-000C7N-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 20:08:45 -0700 Received: from DouglasEwell.anhmca.adelphia.net ([68.66.66.189]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GYWU2H05.Y0X; Sun, 7 Jul 2002 23:08:41 -0400 Message-ID: <022e01c2262c$8cdceae0$bd424244@anhmca.adelphia.net> From: "Doug Ewell" To: "John C Klensin" , "Simon Josefsson" Cc: , "Dan Oscarsson" References: <3D2814CD.8EC26F6B@trab.se><020501c225d9$4aa12180$bd424244@anhmca.adelphia.net><330302450.1026063860@localhost> Subject: [idn] Re: Is space allowed in a hostname? Date: Sun, 7 Jul 2002 20:07:08 -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.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > But, is it worth revisiting the decision? Much as I am > concerned about the potential for damage to the Internet > resulting from putting this stuff into the DNS, I haven't seen a > lot of justification for going around this particular loop > again. I would feel more positive about doing so had matching > and mapping issues with pairs of characters not come up before, > but they have and people who didn't read themselves in have to > bear some of the blame. to which Simon Josefsson replied: > I agree, the current solution is not well understood, and there seems > to be no time to revisit all issues and wait for people to understand > the consequences. This must be a new sense of the phrase "I agree" which I was previously unaware of. John's point was that the NKFC topic had already been discussed and decisions made, and that bringing those people up to speed who had not been part of the original discussions would be unlikely to shed new light on the situation, but would simply cause old issues and questions to be needlessly replayed. This is very different from saying that the decisions were made without sufficient input or knowledge, and that people are being kept in the dark because of an inflexible and overly ambitious WG schedule. -Doug Ewell Fullerton, California From owner-idn@ops.ietf.org Mon Jul 8 00:27: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 AAA23041 for ; Mon, 8 Jul 2002 00:27:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RQ0A-000Dq4-00 for idn-data@psg.com; Sun, 07 Jul 2002 21:19:54 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17RPzo-000Dpn-00 for idn@ops.ietf.org; Sun, 07 Jul 2002 21:19:32 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17RPzT-000NUa-00; Mon, 08 Jul 2002 04:19:11 +0000 Date: Mon, 08 Jul 2002 00:19:09 -0400 From: John C Klensin To: Doug Ewell , Simon Josefsson cc: idn@ops.ietf.org, Dan Oscarsson Subject: Re: [idn] Re: Is space allowed in a hostname? Message-ID: <353994829.1026087549@localhost> In-Reply-To: <022e01c2262c$8cdceae0$bd424244@anhmca.adelphia.net> References: <3D2814CD.8EC26F6B@trab.se> <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> <330302450.1026063860@localhost> <022e01c2262c$8cdceae0$bd424244@anhmca.adelphia.net> X-Mailer: Mulberry/3.0.0a3 (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.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Sunday, 07 July, 2002 20:07 -0700 Doug Ewell wrote: > John C Klensin wrote: > >> But, is it worth revisiting the decision? Much as I am >> concerned about the potential for damage to the Internet >> resulting from putting this stuff into the DNS, I haven't >> seen a lot of justification for going around this particular >> loop again. I would feel more positive about doing so had >> matching and mapping issues with pairs of characters not come >> up before, but they have and people who didn't read >> themselves in have to bear some of the blame. > > to which Simon Josefsson org> replied: > >> I agree, the current solution is not well understood, and >> there seems to be no time to revisit all issues and wait for >> people to understand the consequences. > > This must be a new sense of the phrase "I agree" which I was > previously unaware of. Actually, probably not. > John's point was that the NKFC topic had already been > discussed and decisions made, and that bringing those people > up to speed who had not been part of the original discussions > would be unlikely to shed new light on the situation, but > would simply cause old issues and questions to be needlessly > replayed. Yes, but, this is partially due to my not being able to muster as much sympathy for those who were "not part of the original discussions" because they sat them out and who are now raising old issues as I might have for someone who arrived now and started raising new issues that challenged the conclusions. And, more important,... > This is very different from saying that the decisions were > made without sufficient input or knowledge, and that people > are being kept in the dark because of an inflexible and overly > ambitious WG schedule. Ah. But I think the decisions _were_ made without sufficient input, knowledge, and understanding from sufficiently many people to constitute a legitimate _working group_ decision. I don't see that as desirable, and I think an accurate report of the number of people in the WG who constitute the personally-informed consensus on this issue --either as an absolute number or as a percentage of active participants in the WG-- would be an embarrassment. That said, I claim that I do understand the issues and that several other people in the WG also understand them and have understood them more or less all along. And, based on that understanding, I don't believe that revisiting NFKC is going to get us anywhere. That isn't because NFKC is right or wrong, but because its selection involves tradeoffs, that _no_ alternative is without similar tradeoffs, and that there are no rational criteria for selecting one set of tradeoffs over another. NFKC is, IMO, guilty of one severe sin, and it is the one I believe Simon was pointing out (but it isn't a new observation either): it is not consistent when examined on a language by language and code-point by code-point basis. If a single meta-rule could be made up that would identify the "right" choice for IETF and DNS purposes, it would handle some sets of characters consistently with the rule and some inconsistently. But, again, no better solution is on the table, and, in all likelihood, no objectively better solution is possible: no single, simple, statement can be made that accurately predicts whether characters are duplicated or unified in the Unicode/10646 code set itself. The allocation decisions may well have been made rationally, but enough different rules were applied, and generic enough rules were applied, that it would be unreasonable to expect complete consistency with any simple rule, much less an IETF-optimized one. It is all going to come down to arbitrary choices at some stage. Some of those arbitrary choices are going to irritate some groups of people and seem harmless to others. If they were made a different way, different people would be irritated. If we were to apply the test of whether NFKC (and many of the other stringprep/ nameprep decisions) made everyone who had studied it carefully about equally unhappy, it would almost certainly pass that test. So I don't think this one is worth revisiting, not because the consensus is solid, or because I am feeling serious constraints from a rigid schedule, but because I see absolutely no reason to believe that going around the loop again would produce, a different decision that was objectively better when viewed globally. I do believe that there is, plausibly, a different conclusion that can be reached from this, but reexamining NFKC isn't going to help with it one way or the other. That conclusion is, essentially, the null hypothesis, i.e., that true, global, internationalization that is language-sensitive and sensitive to the semantics commonly attached to various characters is incompatible with the DNS and the way it is organized and does lookups. If one reaches that conclusion, there are then, I believe, only two choices: * one is to decide, explicitly, that some languages (or scripts, or sets of choices about normalization and canonicalization) are "more equal than others" and that the others just lose. * and the other is to decide that internationalization using the DNS is technically infeasible given all of the constraints. I believe the first of these choices is an inappropriate and impossible one for the IETF to make (whether explicitly or implicitly). And I believe that the second has been insufficiently discussed in the WG, only partially because some WG members have taken the position that the WG's returning an answer of "don't do it", rather than a protocol, is so untenable that it cannot be discussed. john From owner-idn@ops.ietf.org Mon Jul 8 07:56: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 HAA11242 for ; Mon, 8 Jul 2002 07:56:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RWrd-0000MA-00 for idn-data@psg.com; Mon, 08 Jul 2002 04:39:33 -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 17RWrX-0000Lr-00 for idn@ops.ietf.org; Mon, 08 Jul 2002 04:39:27 -0700 Message-ID: <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> From: "Edmon Chung" To: "James Seng" , "IETF/IDN WG" References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Date: Mon, 8 Jul 2002 07:37: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=2.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I dont quite understand why we need to have 3. Isnt 3 a subset of 2? Also ----- 2) If a string contains any Right-to-Left character (defined as belonging to Unicode bidirectional categories "R" and "AL"), the string MUST NOT contain any Left-to-Right character (defined as belonging to Unicode bidirectional category "L"). 3) If a string contains any Right-to-Left character (as defined above), a Right-to-Left character MUST be the first character of the string, and a Right-to-Left character MUST be the last character of the string. ----- Also this will mean that there cannot be a mixture between RTL and LTR characters. While I am not familiar with Arabic, I sure have seen English words mixed with Arabic in phrases, albeit rare. I didnt see much discussion on the list before on bidi issues, but I did see an example used: > Assume there were two labels inside the DNS, one reading ABCdef > and the other reading defABC, and both would be displayed > CBAdef. Who would consider that usable for the DNS? Why would both be displayed the same? Shouldn't defABC be displayed as defCBA? Given the context of a domain name within a DNS. Furthermore, the section for bidi in Nameprep should be updated to specify that it is meant to say within a label there cannot be both RTL and LTR characters (eventhough it is mentioned early in the doc that Nameprep deals with labels), because in Stringprep that wasnt clear and also a given "string" can be a "part" of a label, so there could be two "strings", one containing LTR one RTL in the same label. Edmon ----- Original Message ----- From: "James Seng" To: "IETF/IDN WG" Sent: Sunday, July 07, 2002 4:06 AM Subject: [idn] IDN WG Last Call on two major changes to Stringprep > The IETF last call have been concluded and the latest version of > Stringprep is in the I-D directory: > > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt > > Other then editorial changes, there are two significant changes*: > - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. > - Additional Bidirection characters handling, Section 6 and Appendix D. > > The co-chairs is conducting a working group last call on these two > significant changes. Please send any proposed modification of text to the > wg mailing list as well as the wg co-chairs, stating clearly the text to > be modified and the new text. > > This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. > (We have a three weeks last call instead of the usual two weeks for those > who is busy preparing for IETF Yokohama) > > Marc & James > co-chairs > > * The previous of Stringprep can be found at > http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt > > > From owner-idn@ops.ietf.org Mon Jul 8 10:11:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15540 for ; Mon, 8 Jul 2002 10:11:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RZ8j-0004Fb-00 for idn-data@psg.com; Mon, 08 Jul 2002 07:05:21 -0700 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #1) id 17RZ8J-0004Es-00 for idn@ops.ietf.org; Mon, 08 Jul 2002 07:04:56 -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 g68E4ow29061 for ; Mon, 8 Jul 2002 07:04:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> Date: Mon, 8 Jul 2002 07:04:47 -0700 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk At 7:37 AM -0400 7/8/02, Edmon Chung wrote: >I dont quite understand why we need to have 3. >Isnt 3 a subset of 2? No. There are many categories, not just R, AL, and L, as detailed in the Unicode standard. >. . . Why would both be displayed the same? Read the Unicode standard for information on this. >Furthermore, the section for bidi in Nameprep should be updated to specify >that it is meant to say within a label there cannot be both RTL and LTR >characters That's not true. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jul 8 11:07: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 LAA18488 for ; Mon, 8 Jul 2002 11:07:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RZzT-00059D-00 for idn-data@psg.com; Mon, 08 Jul 2002 07:59:51 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 17RZyz-00058J-00 for idn@ops.ietf.org; Mon, 08 Jul 2002 07:59:21 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/4dp61EQYmuCfg22UOX4g1A=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G672LKV4; Mon, 08 Jul 2002 10:56:23 EDT To: klensin@jck.com Cc: dewell@adelphia.net, simon+idn@josefsson.org, idn@ops.ietf.org, Dan.Oscarsson@trab.se Date: Mon, 8 Jul 2002 07:55:06 -0700 Subject: Re: [idn] Re: Is space allowed in a hostname? Message-ID: <20020708.075506.616.2.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > NFKC is, IMO, guilty of one severe sin, and it is the one I > believe Simon was pointing out (but it isn't a new observation > either): it is not consistent when examined on a language by > language and code-point by code-point basis. If a single > meta-rule could be made up that would identify the "right" > choice for IETF and DNS purposes, it would handle some sets of > characters consistently with the rule and some inconsistently. > But, again, no better solution is on the table, and, in all > likelihood, no objectively better solution is possible: no > single, simple, statement can be made that accurately predicts > whether characters are duplicated or unified in the > Unicode/10646 code set itself. The allocation decisions may > well have been made rationally, but enough different rules were > applied, and generic enough rules were applied, that it would be > unreasonable to expect complete consistency with any simple > rule, much less an IETF-optimized one. > > It is all going to come down to arbitrary choices at some stage. > Some of those arbitrary choices are going to irritate some > groups of people and seem harmless to others. If they were made > a different way, different people would be irritated. If we > were to apply the test of whether NFKC (and many of the other > stringprep/ nameprep decisions) made everyone who had studied it > carefully about equally unhappy, it would almost certainly pass > that test. > This is a general case when dealing with characters. Any rule can be appliable only to a subset of characters. Simplification will result to unhappy groups. If the group number is small, then it can be brushed off. But the group number is large, it is supported at this moment by the CJK communities. The CJK community dealing with this issue by table lookup. Please reconsider their working experiences. Liana ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Mon Jul 8 11:38: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 LAA20121 for ; Mon, 8 Jul 2002 11:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RaUy-0005pj-00 for idn-data@psg.com; Mon, 08 Jul 2002 08:32:24 -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 17RaTk-0005o4-00 for idn@ops.ietf.org; Mon, 08 Jul 2002 08:31:08 -0700 Message-ID: <05a501c22694$06405590$6501a8c0@neteka.inc> From: "Edmon Chung" To: , "Paul Hoffman / IMC" References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Date: Mon, 8 Jul 2002 11:27:49 -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.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think I am lost. (which also suggests that the wordings need to be improved) Please clarify two simple things: a. Are mixed RTL and LTR characters allowed within a label? b. If there are more categories than R, AL and L that we are discussing, then in point 3 it should not say "As defined above": ----- 2) If a string contains any Right-to-Left character (defined as belonging to Unicode bidirectional categories "R" and "AL"), the string MUST NOT contain any Left-to-Right character (defined as belonging to Unicode bidirectional category "L"). 3) If a string contains any Right-to-Left character (as defined above), a Right-to-Left character MUST be the first character of the string, and a Right-to-Left character MUST be the last character of the string. ----- Edmon ----- Original Message ----- From: "Paul Hoffman / IMC" To: Sent: Monday, July 08, 2002 10:04 AM Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep > At 7:37 AM -0400 7/8/02, Edmon Chung wrote: > >I dont quite understand why we need to have 3. > >Isnt 3 a subset of 2? > > No. There are many categories, not just R, AL, and L, as detailed in > the Unicode standard. > > >. . . Why would both be displayed the same? > > Read the Unicode standard for information on this. > > >Furthermore, the section for bidi in Nameprep should be updated to specify > >that it is meant to say within a label there cannot be both RTL and LTR > >characters > > That's not true. > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-idn@ops.ietf.org Tue Jul 9 10:13: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 KAA26244 for ; Tue, 9 Jul 2002 10:13:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RvKx-000Fu6-00 for idn-data@psg.com; Tue, 09 Jul 2002 06:47:27 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17RvJy-000Frr-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 06:46:27 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g69DkOm12451 for ; Tue, 9 Jul 2002 15:46:24 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g69DkKw12414; Tue, 9 Jul 2002 15:46:20 +0200 (METDST) Message-ID: <3D2AE92B.6E3700A@trab.se> Date: Tue, 09 Jul 2002 15:46: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: dewell@adelphia.net, simon+idn@josefsson.org, klensin@jck.com, idn@ops.ietf.org Subject: Re: [idn] Re: Is space allowed in a hostname? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >From: John C Klensin >That said, I claim that I do understand the issues and that >several other people in the WG also understand them and have >understood them more or less all along. And, based on that >understanding, I don't believe that revisiting NFKC is going to >get us anywhere. That isn't because NFKC is right or wrong, but >because its selection involves tradeoffs, that _no_ alternative >is without similar tradeoffs, and that there are no rational >criteria for selecting one set of tradeoffs over another. It may be to late to do something about NFKC. NFKC is difficult and at least I have never gotten any answer from those I have asked what NFKC changed compared to NFC. I have therefore tried to read the Unicode tables to see what it means, and I do think it goes to far for domain names. As IDNA combines this with lower caseing using the Unicode "full lower casing" which results in for example German s sharp into ss, we get an even worse situation. While it could be OK for IDNA to use this definition of domain names and matching of them, I is bad if makes it impossible to use a standard based on NFC and rules allowing for example German s sharp to not match ss, in a new class or other technique to get UCS into DNS. I have seen drafts refering to IDNA/NAMEPREP to define what characters are allowed in a domain name. That is bad as it makes it difficult for us to change things later on. Dan From owner-idn@ops.ietf.org Tue Jul 9 11:17: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 LAA28884 for ; Tue, 9 Jul 2002 11:17:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RwYF-000IBo-00 for idn-data@psg.com; Tue, 09 Jul 2002 08:05:15 -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 17RwY4-000IBT-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 08:05:04 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g69F4swF021701; Tue, 9 Jul 2002 17:04:57 +0200 To: John C Klensin Cc: Doug Ewell , idn@ops.ietf.org, Dan Oscarsson Subject: [idn] Re: Is space allowed in a hostname? References: <3D2814CD.8EC26F6B@trab.se> <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> <330302450.1026063860@localhost> <022e01c2262c$8cdceae0$bd424244@anhmca.adelphia.net> <353994829.1026087549@localhost> X-Hashcash: 020709:klensin@jck.com:703db6b393caaca0 X-Hashcash: 020709:dewell@adelphia.net:939f57c332cf2923 X-Hashcash: 020709:idn@ops.ietf.org:ec1e6587e84b860a X-Hashcash: 020709:Dan.Oscarsson@trab.se:1658195fa278f8b2 From: Simon Josefsson Date: Tue, 09 Jul 2002 17:04:53 +0200 In-Reply-To: <353994829.1026087549@localhost> (John C Klensin's message of "Mon, 08 Jul 2002 00:19:09 -0400") Message-ID: Lines: 40 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) 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,SUBJ_ENDS_IN_Q_MARK version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk John C Klensin writes: [snip] > NFKC is, IMO, guilty of one severe sin, and it is the one I > believe Simon was pointing out (but it isn't a new observation > either): it is not consistent when examined on a language by > language and code-point by code-point basis. If a single > meta-rule could be made up that would identify the "right" > choice for IETF and DNS purposes, it would handle some sets of > characters consistently with the rule and some inconsistently. > But, again, no better solution is on the table, and, in all > likelihood, no objectively better solution is possible: no > single, simple, statement can be made that accurately predicts > whether characters are duplicated or unified in the > Unicode/10646 code set itself. The allocation decisions may > well have been made rationally, but enough different rules were > applied, and generic enough rules were applied, that it would be > unreasonable to expect complete consistency with any simple > rule, much less an IETF-optimized one. > > It is all going to come down to arbitrary choices at some stage. > Some of those arbitrary choices are going to irritate some > groups of people and seem harmless to others. If they were made > a different way, different people would be irritated. [snip] This was a good summary. I think the reason that I and others are bringing up old questions is that several of us did participate when this working group started, raising these questions. We are now expecting that the documents answer the questions, or where they cannot be answered to everyone's agreement, at least say what inherent problems and risks are caused by not solving the problems completely. Since internationalized strings is a tricky subject, it is IMHO as important to carefully describe what problems are _not_ solved as to describe what problems actually are solved. Admittedly, the latest document revision fixed several of my pet problems (thanks!), but being new to the topic and not having read the specifications all that carefully makes me worry about there being other inherent problems that aren't documented or discussed. From owner-idn@ops.ietf.org Tue Jul 9 11:24:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29072 for ; Tue, 9 Jul 2002 11:24:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rwj0-000IZC-00 for idn-data@psg.com; Tue, 09 Jul 2002 08:16: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 17Rwhs-000IXB-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 08:15:12 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17RwgC-0001pk-00; Tue, 09 Jul 2002 15:13:29 +0000 Date: Tue, 09 Jul 2002 11:13:29 -0400 From: John C Klensin To: Dan Oscarsson , dewell@adelphia.net, simon+idn@josefsson.org, idn@ops.ietf.org Subject: Re: [idn] Re: Is space allowed in a hostname? Message-ID: <34054797.1026213209@localhost> In-Reply-To: <3D2AE92B.6E3700A@trab.se> References: <3D2AE92B.6E3700A@trab.se> X-Mailer: Mulberry/3.0.0a3 (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.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Tuesday, 09 July, 2002 15:46 +0200 Dan Oscarsson wrote: > While it could be OK for IDNA to use this definition of > domain names and matching of them, I is bad if makes it > impossible to use a standard based on NFC and rules > allowing for example German s sharp to not match ss, in > a new class or other technique to get UCS into DNS. Dan, It seems to me that there are two separate issues here, which ought to be separated. Let's suppose we go down the "new class" path, more or less as outlined in my draft (just because it is the only I-D in the pile, not because it is either complete or correct). Other examples could fit equally well, but would be harder for me to explain. Issue #1 is whether we can have internationalization in that Class and not use IDNA (or, given Eric's distinction, not using IDNA-with-nameprep). The answer had better be "yes", or we are in serious trouble. I have made repeated suggestions that IDNA be explicitly narrowed so that it does not apply to Classes (and maybe RR labels) that have not been invented yet. That change is intended to make sure we don't run into "I already have a conforming legacy use that your changing away from IDNA will destroy" complaints or other problems with defining such a Class in an appropriate way. I think that fix is easy, beneficial, and, with regard to anything now being contemplated, harmless and that we should just make it. Issue #2 is whether such a new Class specification would be stuck with the current definition of stringprep, even if it didn't use IDNA (or IDNA-with-nameprep). While I would hope that the answer would be that stringprep would be usable, it is ultimately just a reference list of tables and transformations. That implies that a new protocol specification could, if needed, reference a different (not-in-stringprep) table if that were sufficiently important, or we could harmlessly add more tables to a stringprep-bis without impacting nameprep at all. So, while I am worried about the first issue --i.e., making sure we don't overconstrain ourselves for no good reason-- I don't see the second as being a big issue right now. When there are proposals to do other things, let's see what they need and act accordingly. And, if NFKC doesn't seem to be appropriate for those hypothetical future approaches, then I would encourage you, and anyone else who is interested, to try to convince the Unicode Consortium of that observation and to try to get them started on a different normalization table with different rules and different applicability. I don't think it is likely that the IETF will be convinced to base a protocol on a table no one has produced, nor that it will be willing to start producing its own tables of this sort, but, if there were a different choice that were well-defined, I think you could get people to look at it. john From owner-idn@ops.ietf.org Tue Jul 9 11:48:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00057 for ; Tue, 9 Jul 2002 11:48:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rx6m-000JS4-00 for idn-data@psg.com; Tue, 09 Jul 2002 08:40:56 -0700 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by psg.com with esmtp (Exim 3.36 #1) id 17Rx62-000JQO-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 08:40:10 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Rx5v-0001t0-00; Tue, 09 Jul 2002 15:40:03 +0000 Date: Tue, 09 Jul 2002 11:40:02 -0400 From: John C Klensin To: Simon Josefsson cc: Doug Ewell , idn@ops.ietf.org, Dan Oscarsson , iesg@ietf.org Subject: [idn] Re: Is space allowed in a hostname? Message-ID: <35648671.1026214802@localhost> In-Reply-To: References: <3D2814CD.8EC26F6B@trab.se> <020501c225d9$4aa12180$bd424244@anhmca.adelphia.net> <330302450.1026063860@localhost> <022e01c2262c$8cdceae0$bd424244@anhmca.adelphia.net> <353994829.1026087549@localhost> X-Mailer: Mulberry/3.0.0a3 (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.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (I've added the IESG back into this note, as I think we finally have a problem statement worth bothering them with) --On Tuesday, 09 July, 2002 17:04 +0200 Simon Josefsson wrote: > John C Klensin writes: > > [snip] >> NFKC is, IMO, guilty of one severe sin, and it is the one I >> believe Simon was pointing out (but it isn't a new observation >> either): it is not consistent when examined on a language by >> language and code-point by code-point basis. If a single >> meta-rule could be made up that would identify the "right" >> choice for IETF and DNS purposes, it would handle some sets of >> characters consistently with the rule and some inconsistently. >> But, again, no better solution is on the table, and, in all >> likelihood, no objectively better solution is possible: no >> single, simple, statement can be made that accurately predicts >> whether characters are duplicated or unified in the >> Unicode/10646 code set itself. The allocation decisions may >> well have been made rationally, but enough different rules >> were applied, and generic enough rules were applied, that it >> would be unreasonable to expect complete consistency with >> any simple rule, much less an IETF-optimized one. >> >> It is all going to come down to arbitrary choices at some >> stage. Some of those arbitrary choices are going to irritate >> some groups of people and seem harmless to others. If they >> were made a different way, different people would be >> irritated. > [snip] > > This was a good summary. > > I think the reason that I and others are bringing up old > questions is that several of us did participate when this > working group started, raising these questions. We are now > expecting that the documents answer the questions, or where > they cannot be answered to everyone's agreement, at least say > what inherent problems and risks are caused by not solving the > problems completely. Since internationalized strings is a > tricky subject, it is IMHO as important to carefully describe > what problems are _not_ solved as to describe what problems > actually are solved. Admittedly, the latest document revision > fixed several of my pet problems (thanks!), but being new to > the topic and not having read the specifications all that > carefully makes me worry about there being other inherent > problems that aren't documented or discussed. We are in violent agreement. My understanding, when we gave up on the "Requirements" document (for what I still believe were good reasons), was that it would be replaced by an exact statement of the problem the WG thought it was solving and, ideally, a review of problems that seemed to fall within the IDN space that it was not trying to solve. Implicit in that was the assumption that the WG's outputs would be narrowed and focused to that statement and tested, where appropriate, against it. Instead, we are missing that statement and, without it, seem to have a collection of specifications that are underspecified in some areas and that overreach in others. Given that, as you say, internationalized strings are a tricky subject, that isn't a good situation. And it leads me to conclude that, even if I believed that IDNA, as now defined from a protocol standpoint, were a perfect match for the critical problem being solved, it would still be vitally important to carefully describe that problem and then to trim, narrow, and focus the relevant documents. john From owner-idn@ops.ietf.org Tue Jul 9 12:18:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01587 for ; Tue, 9 Jul 2002 12:18:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RxXx-000KZv-00 for idn-data@psg.com; Tue, 09 Jul 2002 09:09:01 -0700 Received: from [211.104.177.97] (helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #1) id 17RxWz-000KYW-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 09:08:02 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by localhost.localdomain (8.11.6/8.11.6) id g69G7ue07031 for idn@ops.ietf.org; Wed, 10 Jul 2002 01:07:56 +0900 Content-Type: text/plain; charset="iso-8859-1" From: Soobok Lee To: idn@ops.ietf.org Subject: Re: [idn] Re: Is space allowed in a hostname? Date: Wed, 10 Jul 2002 01:07:54 +0900 User-Agent: KMail/1.4.1 References: <3D2AE92B.6E3700A@trab.se> In-Reply-To: <3D2AE92B.6E3700A@trab.se> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207100107.55132.lsb@postel.co.kr> X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Tuesday 09 July 2002 22:46, Dan Oscarsson wrote: > It may be to late to do something about NFKC. NFKC is difficult and > at least I have never gotten any answer from those I have asked what > NFKC changed compared to NFC. I have therefore tried to read the > Unicode tables to see what it means, and I do think it goes to > far for domain name. By definition, NFKC = "compatibility decomposition" + NFC . This "compatibility decomposition" can be partitioned into groups of script-specific compatibility equivalences, and IMO, each group has its own degree of appropriateness in the context of domain name. For example, only with NFKC, compatibility ideographic character (Kc) can be mapped to its equivalent unified ideographic character (Ku). Kc and Ku share the same glyph, but often have different readings and origins. That mapping is OK. However, NFKC does not unify a certain pairs of TC/SC which are purely in font-variant relations (like between italic/subscript A and normal A) and share the same meanings and readings. When applied to hangul compat jamos (u+33??), NFKC makes errors. When NFKC maps circled "A" into bare "A", it may be useless or unnecessary in domain name context. Ideal IDN name normalization was carved to fit in NFKC. "if you sleep in a bed which is shorter than you, you should bend your legs every night ? or buy new bed ?" Stringprep/nameprep teach us to bend our legs. :-) Soobok Lee > I have seen drafts refering to IDNA/NAMEPREP to define > what characters are allowed in a domain name. That is bad as > it makes it difficult for us to change things later on. > > Dan From owner-idn@ops.ietf.org Tue Jul 9 13:06:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03611 for ; Tue, 9 Jul 2002 13:06:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RyMw-000MZd-00 for idn-data@psg.com; Tue, 09 Jul 2002 10:01: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 17RyLu-000MXB-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 10:00:39 -0700 Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17RyLg-00023D-00; Tue, 09 Jul 2002 17:00:24 +0000 Date: Tue, 09 Jul 2002 13:00:25 -0400 From: John C Klensin To: Soobok Lee , idn@ops.ietf.org Subject: Re: [idn] Re: Is space allowed in a hostname? Message-ID: <40472161.1026219625@localhost> In-Reply-To: <200207100107.55132.lsb@postel.co.kr> References: <3D2AE92B.6E3700A@trab.se> <200207100107.55132.lsb@postel.co.kr> X-Mailer: Mulberry/3.0.0a3 (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.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, 10 July, 2002 01:07 +0900 Soobok Lee wrote: >.... > By definition, NFKC = "compatibility decomposition" + NFC . > This "compatibility decomposition" can be partitioned into > groups of script-specific compatibility equivalences, and IMO, > each group has its own degree of appropriateness in the > context of domain name. For example, only with NFKC, > compatibility ideographic character (Kc) can be mapped to its > equivalent unified ideographic character (Ku). Kc and Ku share > the same glyph, but often have different readings and origins. > That mapping is OK. However, NFKC does not unify a certain > pairs of TC/SC which are purely in font-variant relations > (like between italic/subscript A and normal A) and share the > same meanings and readings. When applied to hangul compat > jamos (u+33??), NFKC makes errors. When NFKC maps circled "A" > into bare "A", it may be useless or unnecessary in domain name > context. Ok. We have established, if it wasn't obvious already, that NFKC is an easy target. That doesn't make it "wrong", it just means that, in the tradeoff decisions that were made, some of the consequences may be unfortunate for particular applications and/or languages. But being able to explain what is wrong with it when viewed from particular perspectives does not, ultimately, help. There are two things that are much more important: (i) Demonstrating that there is a variant of NFKC (or something else that does the same job) that is better across the entire range of scripts and languages, not just a scripts or two or a handful of characters. (ii) Getting that variant reviewed and approved by a recognized standards body with global scope and competence to do this type of evaluation. My guess is that the IETF is no closer to taking on that role than it was a half-dozen years ago, i.e., no chance at all (and for the same good reasons). Absent such a proposal, in written form, and significant motion toward approval by such a standards body, it is nearly a waste of time to complain about NFKC: "no alternative" unfortunately outvotes all other possible answers. > Ideal IDN name normalization was carved to fit in NFKC. > "if you sleep in a bed which is shorter than you, you should > bend your legs every night ? or buy new bed ?" > Stringprep/nameprep teach us to bend our legs. :-) Bending is far better than the version in which your legs are simply cut off to fit. regards, john From owner-idn@ops.ietf.org Wed Jul 10 02:42: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 CAA22782 for ; Wed, 10 Jul 2002 02:42:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SAvG-0004DM-00 for idn-data@psg.com; Tue, 09 Jul 2002 23:25:58 -0700 Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se) by psg.com with esmtp (Exim 3.36 #1) id 17SAv2-0004BN-00 for idn@ops.ietf.org; Tue, 09 Jul 2002 23:25:44 -0700 Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g6A6Pem24343 for ; Wed, 10 Jul 2002 08:25:40 +0200 (METDST) Received: from trab.se (valinor.malmo.trab.se [131.115.48.20]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g6A6Pbw24326; Wed, 10 Jul 2002 08:25:37 +0200 (METDST) Message-ID: <3D2BD360.BD234696@trab.se> Date: Wed, 10 Jul 2002 08:25: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: simon+idn@josefsson.org, dewell@adelphia.net, klensin@jck.com, idn@ops.ietf.org Subject: [idn] Re: Is space allowed in a hostname? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.2 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,WEIRD_PORT version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >To: Dan Oscarsson >Cc: dewell@adelphia.net, klensin@jck.com, idn@ops.ietf.org >Subject: Re: Is space allowed in a hostname? >X-Hashcash: 020709:Dan.Oscarsson@trab.se:6a0136bb72edce86 >X-Hashcash: 020709:dewell@adelphia.net:43f94292c523c78c >X-Hashcash: 020709:klensin@jck.com:4f511128bbb871d5 >X-Hashcash: 020709:idn@ops.ietf.org:ed630ef750c2ac24 >From: Simon Josefsson >Since NFKC is used in stringprep too, this is not only for domain >names but internationalized strings in many environments (such as >authentication identities and passwords). The use of NFKC is optional >in stringprep though, but the alternative is to use no normalization >at all. > >Stringprep furthermore warns profile authors against using the >no-normalization alternative because it may confuse users. In all >honesty, I think stringprep should also say that using NFKC may also >confuse users, altough perhaps different users and different kind of >confusion. > I do not know why stringprep only have NFKC or unnormalised as possible choices. NFC is a very suitable choice to use for UCS. It is the choice of W3C and is the required choice in IRI/URIs. NFC have the nice properties that it preserves all information and is compact. It is a very good choice to use for interoperability. Unnormalised is only useful locally on a system, never for interoperability. NFKC is a possible choice when matching text but may go to far when related to identifiers (names). Dan From owner-idn@ops.ietf.org Thu Jul 11 20:35:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15728 for ; Thu, 11 Jul 2002 20:35:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17So6D-000HIw-00 for idn-data@psg.com; Thu, 11 Jul 2002 17:15:53 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.36 #1) id 17So5u-000HIg-00 for idn@ops.ietf.org; Thu, 11 Jul 2002 17:15:35 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 0B143DDB; Fri, 12 Jul 2002 09:15:18 +0900 (JST) Message-Id: <4.2.0.58.J.20020710155711.053f6368@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 10 Jul 2002 16:07:05 +0900 To: Dan Oscarsson , simon+idn@josefsson.org, dewell@adelphia.net, klensin@jck.com, idn@ops.ietf.org From: Martin Duerst Subject: Re: [idn] Re: Is space allowed in a hostname? In-Reply-To: <3D2BD360.BD234696@trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,DATE_IN_PAST_24_48 version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:25 02/07/10 +0200, Dan Oscarsson wrote: >I do not know why stringprep only have NFKC or unnormalised as possible >choices. NFC is a very suitable choice to use for UCS. >It is the choice of W3C Yes, the most important point here being that W3C deals with all kinds of text rather than just identifiers. >and is the required choice in IRI/URIs. Please read the newest draft, at http://www.ietf.org/internet-drafts/draft-duerst-iri-01.txt NFC is indeed the default choice. Something like this is needed because otherwise, you don't know what UCS codepoints you get for e.g. an 'a' with two dots above. But NFC is not applied everywhere; if you get an IRI already encoded in Unicode, it's not normalized again, and there is even the option that a user enters something unnormalized on purpose. The main reason for this is that URIs/IRIs are 'greatest common denominators' for a lot of other identifiers. It's rather clear that we don't need a circled 'A' in IDN. But we don't want to eliminate circled 'A's from all other identifiers. For non-normalized text, we don't want to disallow the following: http://example.com/normalize.cgi?input= Regards, Martin. >NFC have the nice properties that it preserves all information and is >compact. It is a very good choice to use for interoperability. >Unnormalised is only useful locally on a system, never for >interoperability. >NFKC is a possible choice when matching text but may go to far when >related to identifiers (names). > > Dan From owner-idn@ops.ietf.org Tue Jul 16 04:03:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13246 for ; Tue, 16 Jul 2002 04:03:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UN3a-000MDH-00 for idn-data@psg.com; Tue, 16 Jul 2002 00:47:38 -0700 Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17UN3P-000MCu-00 for idn@ops.ietf.org; Tue, 16 Jul 2002 00:47:27 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17UN3L-0007hn-00 for ; Tue, 16 Jul 2002 00:47:23 -0700 Date: Tue, 16 Jul 2002 07:47:23 +0000 From: "Adam M. Costello" To: IETF/IDN WG Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Message-ID: <20020716074722.GD25019@nicemice.net> Reply-To: IETF idn working group References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> <05a501c22694$06405590$6501a8c0@neteka.inc> <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05a501c22694$06405590$6501a8c0@neteka.inc> <04bd01c22673$ddd259c0$6501a8c0@neteka.inc> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon Chung wrote: > ----- > 2) If a string contains any Right-to-Left character (defined as > belonging to Unicode bidirectional categories "R" and "AL"), the string > MUST NOT contain any Left-to-Right character (defined as belonging to > Unicode bidirectional category "L"). > > 3) If a string contains any Right-to-Left character (as defined above), > a Right-to-Left character MUST be the first character of the string, and > a Right-to-Left character MUST be the last character of the string. > ----- > > I dont quite understand why we need to have 3. > Isnt 3 a subset of 2? No, because there are characters that are neither Right-to-Left nor Left-to-Right. > Also this will mean that there cannot be a mixture between RTL and LTR > characters. Correct. That is exactly rule 2 above. "If X appears then Y must not appear" is exactly equivalent to "X and Y must not both appear". > While I am not familiar with Arabic, I sure have seen English words > mixed with Arabic in phrases, albeit rare. I don't doubt that. I know almost nothing about the bidi algorithm, but the bidi experts concluded that this was the price that needed to be paid to prevent distinct labels from being displayed identically. > I didn't see much discussion on the list before on bidi issues, but I > did see an example used: > > > Assume there were two labels inside the DNS, one reading ABCdef and > > the other reading defABC, and both would be displayed CBAdef. Who > > would consider that usable for the DNS? > > Why would both be displayed the same? I don't know. :) The answer can presumably be inferred from the bidi tech report. > a given "string" can be a "part" of a label, so there could be two > "strings", one containing LTR one RTL in the same label. Nameprep doesn't need to know whether it's input string is a label or part of a label or whatever. Nameprep could operate on any string. But in IDNA, the IDNA spec specifies that nameprep is applied to labels, not to substrings of labels. Therefore a label cannot contain both LTR and RTL characters. > Please clarify two simple things: > a. Are mixed RTL and LTR characters allowed within a label? No. > b. If there are more categories than R, AL and L that we are discussing, > then in point 3 it should not say "As defined above": Yes it should. Rule 3 is using the same definition of Right-to-Left character as stated in rule 2: 'belonging to Unicode bidirectional categories "R" and "AL"'. AMC From owner-idn@ops.ietf.org Mon Jul 22 00:12:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16133 for ; Mon, 22 Jul 2002 00:12:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WUKP-000MXa-00 for idn-data@psg.com; Sun, 21 Jul 2002 20:57:45 -0700 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #1) id 17WUKK-000MXF-00 for idn@ops.ietf.org; Sun, 21 Jul 2002 20:57:41 -0700 Received: (qmail 25614 invoked from network); 22 Jul 2002 04:03:40 -0000 Received: from bb-203-125-5-91.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.5.91) by sentosa.post1.com with SMTP; 22 Jul 2002 04:03:40 -0000 Message-ID: <01f801c23133$d00c10e0$5400a8c0@JAMESSONYVAIO> From: "James Seng" To: "IETF/IDN WG" Subject: Fw: [idn] IDN WG Last Call on two major changes to Stringprep Date: Mon, 22 Jul 2002 11:56:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit this is a reminder that this wg last call will end on 28th july 2002, 23h59 GMT-5 -James Seng ----- Original Message ----- From: "James Seng" To: "IETF/IDN WG" Sent: Sunday, July 07, 2002 4:06 PM Subject: [idn] IDN WG Last Call on two major changes to Stringprep > The IETF last call have been concluded and the latest version of > Stringprep is in the I-D directory: > > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt > > Other then editorial changes, there are two significant changes*: > - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. > - Additional Bidirection characters handling, Section 6 and Appendix D. > > The co-chairs is conducting a working group last call on these two > significant changes. Please send any proposed modification of text to the > wg mailing list as well as the wg co-chairs, stating clearly the text to > be modified and the new text. > > This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. > (We have a three weeks last call instead of the usual two weeks for those > who is busy preparing for IETF Yokohama) > > Marc & James > co-chairs > > * The previous of Stringprep can be found at > http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt > > > From owner-idn@ops.ietf.org Mon Jul 22 08:38:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02512 for ; Mon, 22 Jul 2002 08:38:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WcCh-000BTf-00 for idn-data@psg.com; Mon, 22 Jul 2002 05:22:19 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.36 #1) id 17WcBr-000BQr-00 for idn@ops.ietf.org; Mon, 22 Jul 2002 05:21:33 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id AA5CDD51; Mon, 22 Jul 2002 21:19:47 +0900 (JST) Message-Id: <4.2.0.58.J.20020722014322.03dae318@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 22 Jul 2002 01:54:14 +0900 To: "Larry Masinter" , From: Martin Duerst Subject: [idn] Re: proposed charter items for possible URI working group Cc: "Roy Fielding" , idn@ops.ietf.org In-Reply-To: <001e01c2301d$3ae2eb90$6ace8642@masinter> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.6 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,HTTP_ESCAPED_HOST, DATE_IN_PAST_12_24 version=2.30 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Larry, I had some discussions on this at the IETF last week. It wasn't clear whether we would need a WG for this, and one idea was to first wait to see Roy's update to be able to judge the nature of the changes. My take is that if it's just simple updates/cleanup of RFC 2396, a WG may not be necessary. But if we are going to work on other documents, too, then maybe it's better to have a WG. I propose to add one additional item: Update the syntax of host names: Currently, this is one of the only places where %hh-escaping isn't allowed. Implementations are mixed, some browsers e.g. accept http://www.w%33.org while others don't. So this may go under "(b) document variations in current practice, as warnings to implementors." below. With Internationalized Domain Names, allowing %hh in host names is necessary for consistency. The actual text is currently in http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-02.txt, and there is some chance that the IDN WG moves this forward. But in either way, it should be folded into the URI spec. Regards, Martin. At 11:42 02/07/20 -0700, Larry Masinter wrote: >I've been asked to propose a charter for a possible URI working >group to work on next phase topics. The working group should >be narrowly focused to insure viability and keep us from wandering >into unsolvable problems. For this purpose, I propose the >following items to be in scope: > >(1) update RFC 2396 as follows: > Focus is to be consistent with existing, current widespread > deployment. The goal is to prepare to move RFC 2396 to > Standard. (A few exceptions to this noted below.) > > (a) Fix bugs already noted in errata (bugs in the BNF?) > (b) document variations in current practice, as warnings > to implementors. > (c) fold in changes proposed for IPv6 addresses > (this may not be exactly 'current practice') > (d) include additional terminology definitions for common > words used with URIs ('resolution'), and update the > description of URI/URN/URL language in accordance with > current usage. > > > >(2) update RFC 2717 (Registration Procedures) and RFC 2718 > (Guidelines for new schemes) to take into account current > practice. > >NOT IN SCOPE > >I propose to NOT fold in the IRI definition, but to allow >it to proceed along standards track at its own pace. The >revised URI standard can note the IRI work as a separate >effort. > >OTHER TOPICS > >I think it would be good to finally 'obsolete' RFC 1738, >but it's necessary to do something, I think, with the >URI scheme definitions that are only documented there: >"file" is used widely but documented correctly nowhere. >"http" was defined in the HTTP spec and "mailto" has its >own RFC, "telnet" is still used, "news" and "gopher" >less so, and I haven't seen a "nttp", "wais" or "prospero" >in years. > > >I think Roy Fielding has started on some of this update work, >but I haven't heard status in a while. Roy? > >Larry From owner-idn@ops.ietf.org Mon Jul 22 13:06:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17038 for ; Mon, 22 Jul 2002 13:06:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WgPd-000Hzz-00 for idn-data@psg.com; Mon, 22 Jul 2002 09:51:57 -0700 Received: from m2.boston.juno.com ([64.136.24.65]) by psg.com with esmtp (Exim 3.36 #1) id 17WgPY-000Hzm-00 for idn@ops.ietf.org; Mon, 22 Jul 2002 09:51:53 -0700 Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH/s0P4kkZ9V/VR8gHRfLEIjqa+REzyyuzA=="> Received: (from liana.ydisg@juno.com) by m2.boston.juno.com (jqueuemail) id G8CAPBQA; Mon, 22 Jul 2002 12:50:21 EDT To: duerst@w3.org Cc: LMM@acm.org, uri@w3.org, fielding@apache.org, idn@ops.ietf.org Date: Mon, 22 Jul 2002 09:49:23 -0700 Subject: Re: [idn] Re: proposed charter items for possible URI working group Message-ID: <20020722.094924.184.0.liana.ydisg@juno.com> X-Mailer: Juno 4.0.11 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: liana Ye X-Spam-Status: No, hits=2.2 required=5.0 tests=HTTP_ESCAPED_HOST version=2.30 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I propose to add one additional item: > > Update the syntax of host names: Currently, this is one of the > only places where %hh-escaping isn't allowed. Implementations > are mixed, some browsers e.g. accept http://www.w%33.org while > others don't. So this may go under "(b) document variations in > current practice, as warnings to implementors." below. > With Internationalized Domain Names, allowing %hh in host names > is necessary for consistency. Allow this in IDN label makes the string compare more complex at this time. Liana ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-idn@ops.ietf.org Mon Jul 22 16:35:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06714 for ; Mon, 22 Jul 2002 16:35:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Wjjk-000N5i-00 for idn-data@psg.com; Mon, 22 Jul 2002 13:24:56 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.36 #1) id 17Wjjg-000N5R-00 for idn@ops.ietf.org; Mon, 22 Jul 2002 13:24:52 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id DEAB7560; Tue, 23 Jul 2002 05:24:48 +0900 (JST) Message-Id: <4.2.0.58.J.20020723023723.03db0cd0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 23 Jul 2002 02:39:47 +0900 To: liana Ye From: Martin Duerst Subject: Re: [idn] Re: proposed charter items for possible URI working group Cc: LMM@acm.org, uri@w3.org, fielding@apache.org, idn@ops.ietf.org In-Reply-To: <20020722.094924.184.0.liana.ydisg@juno.com> 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 version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:49 02/07/22 -0700, liana Ye wrote: > > With Internationalized Domain Names, allowing %hh in host names > > is necessary for consistency. > >Allow this in IDN label makes the string compare more complex >at this time. - It doesn't really add that much complexity given that the upper case/lower case comparison is already complex enough. - Comparing URIs is a different thing from comparing IDNs. Nobody is proposing adding %hh to the IDN labels; it's just for URIs. Regards, Martin. From owner-idn@ops.ietf.org Mon Jul 22 17:09:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09503 for ; Mon, 22 Jul 2002 17:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WkJs-000OFc-00 for idn-data@psg.com; Mon, 22 Jul 2002 14:02:16 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17WkJi-000OFE-00 for idn@ops.ietf.org; Mon, 22 Jul 2002 14:02:07 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17WkJh-0001ZW-00 for ; Mon, 22 Jul 2002 14:02:05 -0700 Date: Mon, 22 Jul 2002 21:02:05 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: proposed charter items for possible URI working group Message-ID: <20020722210205.GC5643@nicemice.net> Reply-To: IETF idn working group References: <20020722.094924.184.0.liana.ydisg@juno.com> <4.2.0.58.J.20020723023723.03db0cd0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20020723023723.03db0cd0@localhost> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_MX_FOR_FROM version=2.30 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst wrote: > Nobody is proposing adding %hh to the IDN labels; it's just for > URIs. I was not aware of that. I was under the impression that IRIs were supposed to be a superset of URIs, that is, every valid URI is also a valid IRI, for backward compatibility. Are you sure you don't want that model? AMC From owner-idn@ops.ietf.org Wed Jul 24 10:22:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18539 for ; Wed, 24 Jul 2002 10:22:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XMVo-000634-00 for idn-data@psg.com; Wed, 24 Jul 2002 06:49:08 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17XMVk-00062n-00 for idn@ops.ietf.org; Wed, 24 Jul 2002 06:49:04 -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 HAA08506 for ; Wed, 24 Jul 2002 07:49:02 -0600 (MDT) Received: from lillen (hobo076.Eng.Sun.COM [129.146.31.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6ODmxg20647 for ; Wed, 24 Jul 2002 15:49:00 +0200 (MEST) Date: Wed, 24 Jul 2002 15:47:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep To: IETF/IDN WG In-Reply-To: "Your message with ID" <01f801c23133$d00c10e0$5400a8c0@JAMESSONYVAIO> 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 version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Folks, I'd like to make sure that these changes to stringprep have been well-reviewed. There hasn't been much discussion on the list which could be due to at least two different reasons: - the changes are good, well understood, etc. thus there is nothing to comment on - not many people have read and understood the changes In order to be able to tell the difference I'd appreciate a note (to the list or directly to me) saying you've reviewed and understood the changes. Thanks, Erik ----- Original Message ----- From: "James Seng" To: "IETF/IDN WG" Sent: Sunday, July 07, 2002 4:06 PM Subject: [idn] IDN WG Last Call on two major changes to Stringprep > The IETF last call have been concluded and the latest version of > Stringprep is in the I-D directory: > > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt > > Other then editorial changes, there are two significant changes*: > - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. > - Additional Bidirection characters handling, Section 6 and Appendix D. > > The co-chairs is conducting a working group last call on these two > significant changes. Please send any proposed modification of text to the > wg mailing list as well as the wg co-chairs, stating clearly the text to > be modified and the new text. > > This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. > (We have a three weeks last call instead of the usual two weeks for those > who is busy preparing for IETF Yokohama) > > Marc & James > co-chairs > > * The previous of Stringprep can be found at > http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt > > > From owner-idn@ops.ietf.org Wed Jul 24 10:28:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18875 for ; Wed, 24 Jul 2002 10:28:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XMtX-0007i1-00 for idn-data@psg.com; Wed, 24 Jul 2002 07:13:39 -0700 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by psg.com with esmtp (Exim 3.36 #1) id 17XMtR-0007hj-00 for idn@ops.ietf.org; Wed, 24 Jul 2002 07:13:33 -0700 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id XAA01989 for ; Wed, 24 Jul 2002 23:13:31 +0900 (JST) (envelope-from yone@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id g6OEDUg07480 for ; Wed, 24 Jul 2002 23:13:30 +0900 (JST) (envelope-from yone@po.ntts.co.jp) Received: (qmail 62996 invoked by alias); 24 Jul 2002 23:13:29 +0900 Received: (qmail 62973 invoked from network); 24 Jul 2002 23:13:29 +0900 Received: from daemon.inl.ntts.co.jp (HELO localhost) by daemon.inl.ntts.co.jp with SMTP; 24 Jul 2002 23:13:29 +0900 To: Erik.Nordmark@sun.com Cc: idn@ops.ietf.org Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep In-Reply-To: References: <01f801c23133$d00c10e0$5400a8c0@JAMESSONYVAIO> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020724231325N.yone@po.ntts.co.jp> Date: Wed, 24 Jul 2002 23:13:25 +0900 (JST) From: Yoshiro YONEYA X-Dispatcher: imput version 20000414(IM141) Lines: 20 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear AD and all, > I'd like to make sure that these changes to stringprep have been well-reviewed. > There hasn't been much discussion on the list which could be due to at least > two different reasons: > - the changes are good, well understood, etc. thus there is nothing > to comment on > - not many people have read and understood the changes > > In order to be able to tell the difference I'd appreciate a note (to the > list or directly to me) saying you've reviewed and understood the > changes. I've reviewed the new I-Ds and understood the changes. I think the changes are good. Regards, -- Yoshiro YONEYA From owner-idn@ops.ietf.org Wed Jul 24 10:49:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19959 for ; Wed, 24 Jul 2002 10:49:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XNHi-0009RN-00 for idn-data@psg.com; Wed, 24 Jul 2002 07:38:38 -0700 Received: from heron.verisign.com ([216.168.233.95]) by psg.com with esmtp (Exim 3.36 #1) id 17XNHd-0009R9-00 for idn@ops.ietf.org; Wed, 24 Jul 2002 07:38:34 -0700 Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA27450; Wed, 24 Jul 2002 10:39:17 -0400 (EDT) Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 10:38:32 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189BCA4@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Erik Nordmark'" , IETF/IDN WG Subject: RE: [idn] IDN WG Last Call on two major changes to Stringprep Date: Wed, 24 Jul 2002 10:38:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk > I'd like to make sure that these changes to stringprep have > been well-reviewed. > There hasn't been much discussion on the list which could be > due to at least > two different reasons: > - the changes are good, well understood, etc. thus there is nothing > to comment on > - not many people have read and understood the changes > > In order to be able to tell the difference I'd appreciate a > note (to the > list or directly to me) saying you've reviewed and understood the > changes. I've reviewed and am comfortable with the changes. -Scott- From owner-idn@ops.ietf.org Wed Jul 24 21:11:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08567 for ; Wed, 24 Jul 2002 21:11:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XWy7-000D5S-00 for idn-data@psg.com; Wed, 24 Jul 2002 17:59:03 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17XWxw-000D3q-00 for idn@ops.ietf.org; Wed, 24 Jul 2002 17:58:52 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17XWxu-00024H-00 for ; Wed, 24 Jul 2002 17:58:50 -0700 Date: Thu, 25 Jul 2002 00:58:50 +0000 From: "Adam M. Costello" To: IETF/IDN WG Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Message-ID: <20020725005850.GB6347@nicemice.net> Reply-To: IETF idn working group References: <01f801c23133$d00c10e0$5400a8c0@JAMESSONYVAIO> 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=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik Nordmark wrote: > In order to be able to tell the difference I'd appreciate a note (to > the list or directly to me) saying you've reviewed and understood the > changes. I have reviewed and understood the changes to Stringprep, and approve of them, with the following disclaimer: While I understand the new bidi rules and their implications, I do not fully understand the motivation for the new rules, because I don't understand the Unicode bidi algorithm. I am trusting the opinion of the bidi experts that the rules are needed. AMC From owner-idn@ops.ietf.org Thu Jul 25 18:10:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22958 for ; Thu, 25 Jul 2002 18:10:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XqN6-0005ns-00 for idn-data@psg.com; Thu, 25 Jul 2002 14:42:08 -0700 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #1) id 17XqMs-0005nS-00 for idn@ops.ietf.org; Thu, 25 Jul 2002 14:41:54 -0700 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 17XqMs-0004Me-00 for ; Thu, 25 Jul 2002 14:41:54 -0700 Date: Thu, 25 Jul 2002 21:41:54 +0000 From: "Adam M. Costello" To: IETF/IDN WG Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep Message-ID: <20020725214153.GA16568@nicemice.net> Reply-To: IETF idn working group References: <01f801c23133$d00c10e0$5400a8c0@JAMESSONYVAIO> <20020725005850.GB6347@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020725005850.GB6347@nicemice.net> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk I wrote: > I have reviewed and understood the changes to Stringprep, and approve > of them... I forgot about one minor technical issue that I starting discussing with the authors a while back, but that discussion fizzled out. One of the changes to Stringprep is the addition of two new prohibited characters, U+0340 and U+0341 (combining grave/acute tone marks). These characters are prohibited because they are deprecated, and for no other reason. The previous draft of Stringprep also prohibited deprecated characters, but the reason for their prohibition was something else (they "change display properties"), and the fact that they were deprecated was incidental. I see no real harm in prohibiting these two characters, and no real need to prohibit them either. But Nameprep (or any other profile) will not be able to follow this precedent of prohibiting deprecated characters in the future. If subsequent versions of Unicode deprecate more characters, Nameprep will not be able to prohibit them, because section 7.1 forbids later versions of a profile from prohibiting characters that were allowed in earlier versions of the profile. Why start down a path that you can't stay on? Perhaps deprecation alone should not be considered sufficient reason for including a character in the prohibition lists. As I said, this is a minor issue. I don't think it really matters whether these two characters are prohibited or not, I just think they might end up looking like anomalies in the future. There is a related issue that is purely editorial, not technical. If these two characters are prohibited, I don't see why the categories "change display properties" and "deprecated" should be merged into a single section, as they are in the current draft. They have nothing to do with each other, except that there happen to be some characters that could fall into either category. This is not the only instance of overlap. The "change display properties" category overlaps with the "control characters" category, and yet those two are not merged. Similarly, the "inappropriate for plain text" category overlaps with the "control characters" category, and those two are not merged. For consistency, I think the "deprecated" category, if it is retained, should get its own section. AMC From owner-idn@ops.ietf.org Fri Jul 26 20:38:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13149 for ; Fri, 26 Jul 2002 20:38:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YFJn-0000rZ-00 for idn-data@psg.com; Fri, 26 Jul 2002 17:20:23 -0700 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 17YFJj-0000rM-00 for idn@ops.ietf.org; Fri, 26 Jul 2002 17:20:19 -0700 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 17:20:18 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Jul 2002 17:20:18 -0700 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 26 Jul 2002 17:20:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [idn] IDN WG Last Call on two major changes to Stringprep Date: Fri, 26 Jul 2002 17:20:17 -0700 Message-ID: <9805B5E65CD0D0479D08B7EB832B369F01E27A6E@red-msg-08.redmond.corp.microsoft.com> Thread-Topic: [idn] IDN WG Last Call on two major changes to Stringprep Thread-Index: AcIzGeUN3T9pkqXuSWKC3ngP3fJ2HwB59x1g From: "Michel Suignard" To: "Erik Nordmark" Cc: "IETF/IDN WG" X-OriginalArrivalTime: 27 Jul 2002 00:20:18.0284 (UTC) FILETIME=[630E22C0:01C23503] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA13149 I have reviewed and understood the changes and really appreciate that bidi is now part of Stringprep. My only concern is that the restrictions put on bidi labels (indirectly by usage of Stringprep in IDNA) are not felt as being excessive by the Bidi user community. Furthermore, Strinprep is likely to be used in other contexts, so it is important that Bidi users realize what they are getting. Michel From owner-idn@ops.ietf.org Fri Jul 26 23:38:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16760 for ; Fri, 26 Jul 2002 23:38:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YIGK-00085r-00 for idn-data@psg.com; Fri, 26 Jul 2002 20:29: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 17YIGC-00085L-00 for idn@ops.ietf.org; Fri, 26 Jul 2002 20:28:53 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6R3Sikd004787; Sat, 27 Jul 2002 05:28:44 +0200 To: paul.hoffman@imc.org, Marc.Blanchet@viagenie.qc.ca Cc: "IETF/IDN WG" Subject: [idn] Re: IDN WG Last Call on two major changes to Stringprep References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> X-Hashcash: 020727:paul.hoffman@imc.org:b2222f2f664d1f88 X-Hashcash: 020727:Marc.Blanchet@viagenie.qc.ca:f39d500f2202c676 X-Hashcash: 020727:idn@ops.ietf.org:b79cd0dda71bebdd From: Simon Josefsson Date: Sat, 27 Jul 2002 05:28:44 +0200 In-Reply-To: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> ("James Seng"'s message of "Sun, 7 Jul 2002 16:06:58 +0800") Message-ID: Lines: 28 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=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Quoting the draft: ,---- | In any profile that specifies bidirectional character handling, all | three of the following requirements MUST be met: ... | 2) If a string contains any Right-to-Left character (defined as | belonging to Unicode bidirectional categories "R" and "AL"), the string | MUST NOT contain any Left-to-Right character (defined as belonging to | Unicode bidirectional category "L"). | | 3) If a string contains any Right-to-Left character (as defined above), | a Right-to-Left character MUST be the first character of the string, and | a Right-to-Left character MUST be the last character of the string. `---- There is little rationale for the last two requirements. Without knowing the rationale, it is difficult to understand how to implement this, not to speak of understanding and evaluating the specification. It is not difficult to construct various strings that violates these requirements, but seem like valid identifiers to me (e.g., U+05D0 U+0966, contemplate it being written by a mathematically inclined writer in India). Why is U+05D0 a R/AL character but U+2135 not? U+2135 is NFKC'd into U+05D0. It thus seems like the identifier is a valid IDN if NFKC is not used, but if NFKC is used, it is not a valid identifier. A bidi user thus seem to require NFKC not to be used in order to have the bidi string accepted. From owner-idn@ops.ietf.org Sat Jul 27 00:27:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17439 for ; Sat, 27 Jul 2002 00:27:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YIzt-000A93-00 for idn-data@psg.com; Fri, 26 Jul 2002 21:16:05 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #1) id 17YIzm-000A86-00 for idn@ops.ietf.org; Fri, 26 Jul 2002 21:15:58 -0700 Received: (qmail 89907 invoked from network); 27 Jul 2002 04:15:56 -0000 Received: from 12-234-224-41.client.attbi.com (HELO c1340594a) (12.234.224.41) by relay1.pair.com with SMTP; 27 Jul 2002 04:15:56 -0000 X-pair-Authenticated: 12.234.224.41 Message-ID: <013301c23524$90f475b0$8900a8c0@c1340594a> From: "Mark Davis" To: , , "Simon Josefsson" Cc: "IETF/IDN WG" , "Matitiahu Allouche" References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> Subject: Re: [idn] Re: IDN WG Last Call on two major changes to Stringprep Date: Fri, 26 Jul 2002 21:17:47 -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=2.1 required=5.0 tests=DOUBLE_CAPSWORD,PORN_10,GAPPY_TEXT version=2.31 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit There are two issues. (a) rationale, (b) NFKC interaction. For the rationale, I include at the bottom an old email. It proposed a somewhat more complicated solution than eventually appeared in the text; I think what is in StringPrep is better (just for simplicity). For the NFKC interaction, you bring up a good point. The conditions on the string, if the goal is to always have a consistent appearance (both on keyboard entry, and when displaying a name fetched from the server) should be in effect for the string both before and after StringPrep. In practice, it only has any effect in a few isolated cases, since there are very few characters whose BIDI class changes. Mark ----- Original Message ----- From: "Mark Davis" To: ; "Paul Hoffman / IMC" Sent: Saturday, September 15, 2001 19:03 Subject: Re: First attempt at problem statement BIDI IDN I will try to recap some of the discussions in the ad hoc on BIDI IDN last week. The BIDI algorithm is designed to deal with normal text. Within any string, sequences of LTR (left to right) and RTL characters will always appear in the correct order. However, the order of other characters (such as a period) will depend on their context. For details, see http://www.unicode.org/reports/tr9/. URLs are not normal text, and thus may have odd display. This is complicated by the fact that the overall paragraph direction has an effect on the display. Whether the URL is displayed in a RTL or LTR context will change the order of the components. [In this and other examples we will use the convention that uppercase letters stand for right-to-left characters: Arabic, Hebrew, etc.] Example: Memory: http://SOME.LARGE.mixed.CORP.org Display (LTR): http://EGRAL.EMOS.mixed.PROC.org Display (RTL): org.PROC.mixed.EGRAL.EMOS//:http Notice that "SOME.LARGE" always appears from RTL: the period adopts the order of the surrounding characters. Characters on boundaries (such as "//:" take on the overall display direction. For example: (1) characters in different fields may mix across fields: Memory: http://SOME.veryLARGE.CORP.org Display (LTR): http://EMOS.veryPROC.EGRAL.org Display (RTL): org.PROC.EGRALvery.EMOS//:http (2) two different sequences of characters in the same field can have the same order when displayed. Thus a user would not know how to type a URL that he sees printed. Memory1: http://123CORP.org Memory2: http://CORP123.org Display (LTR): http://123PROC.org The following are proposed requirements. 1. Consistent fields. (a) If you have fields such as http://XXX.YYY.ZZZ, characters from the same field should not be displayed in different fields and vice versa. (b) It should be possible to deduce the order of the backing-store fields from the order of the display fields. 2. Order within fields. Within a field, tt should be possible to deduce the order of the backing-store characters from the order of the display fields. 3. No algorithm change This should require no change to BIDI algorithm. Using a separate algorithm for display of URLs would be difficult, since they are found within flowing text. Getting people to update the BIDI algorithm would also be quite difficult (and changes to make URLs work might have repercussions on other text). 4. Simplicity Whatever solution we have should have a simple algorithm (according to Paul). Ideally, some reasonable restrictions on the contents of a field would meet all of these requirements. * * * During the meeting, I thought that the most straightforward method was to force the periods to be LTR. However, after looking at the results in both a RTL and LTR context, I concluded that Mati's approach would be better. The results both in terms of field order and order within a field would still be determinate. With any complete URL (with http://, ftp://, etc.) it would be easy to recognize the order in context, since the position of those initial letters would show the order. The only bad case would be where the end of the string reversed because of its surroundings, e.g.: Memory: the url http://SOME.LARGE.mixed.CORP.org is the one Display (LTR): the url http://EGRAL.EMOS.mixed.PROC.org is the one Display (RTL): org is the one.PROC.mixed.EGRAL.EMOS//: the url http Thus in flowing text, users would be recommended to bracket any BIDI URL with RLM (or embed the URL). E.g. Memory: the url http://SOME.LARGE.mixed.CORP.org is the one Display (LTR): the url http://EGRAL.EMOS.mixed.PROC.org is the one Display (RTL): is the one org.PROC.mixed.EGRAL.EMOS//:http the url Software, such as email clients, that recognizes URLs could do this automatically. Here is what I have now for an explicit algorithm to be added as a step to NamePrep, after the regular Prohibition step. A. Characters are classified into RTL, LTR, DIGIT, OTHER. These categories are drawn from the BIDI algorithm. The precise lists of characters in each category would be added to NamePrep as an appendix. The composition is as follows (See http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types). LTR := L ; # including LRM RTL := R | AL ; DIG := EN | AN ; OTH := all other characters: NSM, ON, etc. Note: The characters in categories LRM, RLM, LRO, RLO, LRE, RLE, PDF, B, S, and some other BIDI categories are prohibited anyway. B. In any field that contains any RTL characters: B0. no LTR characters can occur. C1. a sequence of characters of type DIG can only occur at the end. C2. a sequence of characters of type OTHER can occur only between characters of type RTL. The following is an example of an algorithm that implements (B). EOS stands for "end of string". 1. Let S be 0 2. Get the next character, then get its numeric type T 3. Let S be Map[S, T] 4. If S = T or F, exit with OK or FAIL respectively 5. Goto Step 2 Map is defined by the following table: T LTR RTL DIG OTH EOS S +--------------------- B | L, R, L, L, F // begin L | L, F, L, L, T // left R | F, R, D, O, T // right O | F, R, F, O, F // right + other D | F, F, D, F, T // right + digit Mark __________ http://www.macchiato.com ◄ “Eppur si muove” ► ----- Original Message ----- From: "Simon Josefsson" To: ; Cc: "IETF/IDN WG" Sent: Friday, July 26, 2002 20:28 Subject: [idn] Re: IDN WG Last Call on two major changes to Stringprep > Quoting the draft: > > ,---- > | In any profile that specifies bidirectional character handling, all > | three of the following requirements MUST be met: > ... > | 2) If a string contains any Right-to-Left character (defined as > | belonging to Unicode bidirectional categories "R" and "AL"), the string > | MUST NOT contain any Left-to-Right character (defined as belonging to > | Unicode bidirectional category "L"). > | > | 3) If a string contains any Right-to-Left character (as defined above), > | a Right-to-Left character MUST be the first character of the string, and > | a Right-to-Left character MUST be the last character of the string. > `---- > > There is little rationale for the last two requirements. Without > knowing the rationale, it is difficult to understand how to implement > this, not to speak of understanding and evaluating the specification. > > It is not difficult to construct various strings that violates these > requirements, but seem like valid identifiers to me (e.g., U+05D0 > U+0966, contemplate it being written by a mathematically inclined > writer in India). Why is U+05D0 a R/AL character but U+2135 not? > U+2135 is NFKC'd into U+05D0. It thus seems like the identifier is a > valid IDN if NFKC is not used, but if NFKC is used, it is not a valid > identifier. A bidi user thus seem to require NFKC not to be used in > order to have the bidi string accepted. > > > From owner-idn@ops.ietf.org Sat Jul 27 01:12:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17913 for ; Sat, 27 Jul 2002 01:12:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YJdx-000Bvn-00 for idn-data@psg.com; Fri, 26 Jul 2002 21:57:29 -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 17YJdq-000BvY-00 for idn@ops.ietf.org; Fri, 26 Jul 2002 21:57:22 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6R4v3kd005721; Sat, 27 Jul 2002 06:57:03 +0200 To: "Mark Davis" Cc: , , "IETF/IDN WG" , "Matitiahu Allouche" Subject: [idn] Re: IDN WG Last Call on two major changes to Stringprep References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO> <013301c23524$90f475b0$8900a8c0@c1340594a> X-Hashcash: 020727:mark@macchiato.com:d4a8df31aa1f662e X-Hashcash: 020727:paul.hoffman@imc.org:32d85c810485fcc7 X-Hashcash: 020727:Marc.Blanchet@viagenie.qc.ca:9f4254ce0bc35130 X-Hashcash: 020727:idn@ops.ietf.org:fd5aba409ec146d9 X-Hashcash: 020727:matial@il.ibm.com:0c6132ee00cf7a5a From: Simon Josefsson Date: Sat, 27 Jul 2002 06:57:03 +0200 In-Reply-To: <013301c23524$90f475b0$8900a8c0@c1340594a> ("Mark Davis"'s message of "Fri, 26 Jul 2002 21:17:47 -0700") Message-ID: Lines: 248 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=utf-8 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,PORN_10,GAPPY_TEXT version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA17913 "Mark Davis" writes: > There are two issues. (a) rationale, (b) NFKC interaction. > > For the rationale, I include at the bottom an old email. Thanks. (If people want to look at more discussions, I found an archive at .) > It proposed a somewhat more complicated solution than eventually > appeared in the text; I think what is in StringPrep is better (just > for simplicity). Somehow I wish this was discussed in the specification, if people are supposed to understand it without digging in mailing lists archives. The fact that bidi is difficult to understand (as is normalization and other IDN topics) isn't an excuse to be sparse with details, rationale and examples; on the contrary. > For the NFKC interaction, you bring up a good point. The conditions on > the string, if the goal is to always have a consistent appearance > (both on keyboard entry, and when displaying a name fetched from the > server) should be in effect for the string both before and after > StringPrep. In practice, it only has any effect in a few isolated > cases, since there are very few characters whose BIDI class changes. What could a solution be? Perform the bidi step before NFKC too? If the intention is to not ignore the issue, that is. > > > Mark > > ----- Original Message ----- > From: "Mark Davis" > To: ; "Paul Hoffman / IMC" > Sent: Saturday, September 15, 2001 19:03 > Subject: Re: First attempt at problem statement > > > BIDI IDN > > I will try to recap some of the discussions in the ad hoc on BIDI IDN > last week. > > The BIDI algorithm is designed to deal with normal text. Within any > string, sequences of LTR (left to right) and RTL characters will > always appear in the correct order. However, the order of other > characters (such as a period) will depend on their context. For > details, see http://www.unicode.org/reports/tr9/. > > URLs are not normal text, and thus may have odd display. This is > complicated by the fact that the overall paragraph direction has an > effect on the display. Whether the URL is displayed in a RTL or LTR > context will change the order of the components. [In this and other > examples we will use the convention that uppercase letters stand for > right-to-left characters: Arabic, Hebrew, etc.] Example: > > Memory: http://SOME.LARGE.mixed.CORP.org > Display (LTR): http://EGRAL.EMOS.mixed.PROC.org > Display (RTL): org.PROC.mixed.EGRAL.EMOS//:http > > Notice that "SOME.LARGE" always appears from RTL: the period adopts > the order of the surrounding characters. Characters on boundaries > (such as "//:" take on the overall display direction. > > For example: > > (1) characters in different fields may mix across fields: > > Memory: http://SOME.veryLARGE.CORP.org > Display (LTR): http://EMOS.veryPROC.EGRAL.org > Display (RTL): org.PROC.EGRALvery.EMOS//:http > > > (2) two different sequences of characters in the same field can have > the same order when displayed. Thus a user would not know how to type > a URL that he sees printed. > > Memory1: http://123CORP.org > Memory2: http://CORP123.org > Display (LTR): http://123PROC.org > > > The following are proposed requirements. > > 1. Consistent fields. > > (a) If you have fields such as http://XXX.YYY.ZZZ, characters from the > same field should not be displayed in different fields and vice versa. > (b) It should be possible to deduce the order of the backing-store > fields from the order of the display fields. > > 2. Order within fields. > > Within a field, tt should be possible to deduce the order of the > backing-store characters from the order of the display fields. > > 3. No algorithm change > > This should require no change to BIDI algorithm. Using a separate > algorithm for display of URLs would be difficult, since they are found > within flowing text. Getting people to update the BIDI algorithm would > also be quite difficult (and changes to make URLs work might have > repercussions on other text). > > 4. Simplicity > > Whatever solution we have should have a simple algorithm (according to > Paul). > > Ideally, some reasonable restrictions on the contents of a field would > meet all of these requirements. > > > * * * > > During the meeting, I thought that the most straightforward method was > to force the periods to be LTR. However, after looking at the results > in both a RTL and LTR context, I concluded that Mati's approach would > be better. The results both in terms of field order and order within a > field would still be determinate. With any complete URL (with http://, > ftp://, etc.) it would be easy to recognize the order in context, > since the position of those initial letters would show the order. The > only bad case would be where the end of the string reversed because of > its surroundings, e.g.: > > Memory: the url http://SOME.LARGE.mixed.CORP.org is the one > Display (LTR): the url http://EGRAL.EMOS.mixed.PROC.org is the one > Display (RTL): org is the one.PROC.mixed.EGRAL.EMOS//: the url http > > Thus in flowing text, users would be recommended to bracket any BIDI > URL with RLM (or embed the URL). E.g. > > Memory: the url http://SOME.LARGE.mixed.CORP.org is > the one > Display (LTR): the url http://EGRAL.EMOS.mixed.PROC.org is the one > Display (RTL): is the one org.PROC.mixed.EGRAL.EMOS//:http the url > > Software, such as email clients, that recognizes URLs could do this > automatically. > > > Here is what I have now for an explicit algorithm to be added as a > step to NamePrep, after the regular Prohibition step. > > A. Characters are classified into RTL, LTR, DIGIT, OTHER. > > These categories are drawn from the BIDI algorithm. The precise lists > of characters in each category would be added to NamePrep as an > appendix. The composition is as follows (See > http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types). > > LTR := L ; # including LRM > > RTL := R | AL ; > > DIG := EN | AN ; > > OTH := all other characters: NSM, ON, etc. > > Note: The characters in categories LRM, RLM, LRO, RLO, LRE, RLE, PDF, > B, S, and some other BIDI categories are prohibited anyway. > > > B. In any field that contains any RTL characters: > B0. no LTR characters can occur. > C1. a sequence of characters of type DIG can only occur at the end. > C2. a sequence of characters of type OTHER can occur only between > characters of type RTL. > > > The following is an example of an algorithm that implements (B). EOS > stands for "end of string". > > 1. Let S be 0 > 2. Get the next character, then get its numeric type T > 3. Let S be Map[S, T] > 4. If S = T or F, exit with OK or FAIL respectively > 5. Goto Step 2 > > Map is defined by the following table: > > T LTR RTL DIG OTH EOS > S +--------------------- > B | L, R, L, L, F // begin > L | L, F, L, L, T // left > R | F, R, D, O, T // right > O | F, R, F, O, F // right + other > D | F, F, D, F, T // right + digit > > > Mark > __________ > http://www.macchiato.com > ◄ “Eppur si muove” ► > > ----- Original Message ----- > From: "Simon Josefsson" > To: ; > Cc: "IETF/IDN WG" > Sent: Friday, July 26, 2002 20:28 > Subject: [idn] Re: IDN WG Last Call on two major changes to Stringprep > > >> Quoting the draft: >> >> ,---- >> | In any profile that specifies bidirectional character handling, > all >> | three of the following requirements MUST be met: >> ... >> | 2) If a string contains any Right-to-Left character (defined as >> | belonging to Unicode bidirectional categories "R" and "AL"), the > string >> | MUST NOT contain any Left-to-Right character (defined as belonging > to >> | Unicode bidirectional category "L"). >> | >> | 3) If a string contains any Right-to-Left character (as defined > above), >> | a Right-to-Left character MUST be the first character of the > string, and >> | a Right-to-Left character MUST be the last character of the > string. >> `---- >> >> There is little rationale for the last two requirements. Without >> knowing the rationale, it is difficult to understand how to > implement >> this, not to speak of understanding and evaluating the > specification. >> >> It is not difficult to construct various strings that violates these >> requirements, but seem like valid identifiers to me (e.g., U+05D0 >> U+0966, contemplate it being written by a mathematically inclined >> writer in India). Why is U+05D0 a R/AL character but U+2135 not? >> U+2135 is NFKC'd into U+05D0. It thus seems like the identifier is > a >> valid IDN if NFKC is not used, but if NFKC is used, it is not a > valid >> identifier. A bidi user thus seem to require NFKC not to be used in >> order to have the bidi string accepted. >> >> >> From owner-idn@ops.ietf.org Sat Jul 27 11:09:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02819 for ; Sat, 27 Jul 2002 11:09:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YSso-0005zp-00 for idn-data@psg.com; Sat, 27 Jul 2002 07:49:26 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #1) id 17YSsi-0005zc-00 for idn@ops.ietf.org; Sat, 27 Jul 2002 07:49:20 -0700 Received: (qmail 68632 invoked from network); 27 Jul 2002 14:49:19 -0000 Received: from 12-234-224-41.client.attbi.com (HELO c1340594a) (12.234.224.41) by relay1.pair.com with SMTP; 27 Jul 2002 14:49:19 -0000 X-pair-Authenticated: 12.234.224.41 Message-ID: <001201c2357d$0c38fa40$8900a8c0@c1340594a> From: "Mark Davis" To: "Simon Josefsson" Cc: , , "IETF/IDN WG" , "Matitiahu Allouche" References: <012501c2258d$44c78ca0$7400a8c0@JAMESSONYVAIO><013301c23524$90f475b0$8900a8c0@c1340594a> Subject: Re: [idn] Re: IDN WG Last Call on two major changes to Stringprep Date: Sat, 27 Jul 2002 07:51:09 -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=2.1 required=5.0 tests=DOUBLE_CAPSWORD,PORN_10,GAPPY_TEXT version=2.31 X-Spam-Level: ** Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit That would be a solution, if it was felt to be important that the input also obey the conditions. Whether it is important or not, I would defer to Mati. Mark __________ http://www.macchiato.com ◄ “Eppur si muove” ► ----- Original Message ----- From: "Simon Josefsson" To: "Mark Davis" Cc: ; ; "IETF/IDN WG" ; "Matitiahu Allouche" Sent: Friday, July 26, 2002 21:57 Subject: [idn] Re: IDN WG Last Call on two major changes to Stringprep "Mark Davis" writes: > There are two issues. (a) rationale, (b) NFKC interaction. > > For the rationale, I include at the bottom an old email. Thanks. (If people want to look at more discussions, I found an archive at .) > It proposed a somewhat more complicated solution than eventually > appeared in the text; I think what is in StringPrep is better (just > for simplicity). Somehow I wish this was discussed in the specification, if people are supposed to understand it without digging in mailing lists archives. The fact that bidi is difficult to understand (as is normalization and other IDN topics) isn't an excuse to be sparse with details, rationale and examples; on the contrary. > For the NFKC interaction, you bring up a good point. The conditions on > the string, if the goal is to always have a consistent appearance > (both on keyboard entry, and when displaying a name fetched from the > server) should be in effect for the string both before and after > StringPrep. In practice, it only has any effect in a few isolated > cases, since there are very few characters whose BIDI class changes. What could a solution be? Perform the bidi step before NFKC too? If the intention is to not ignore the issue, that is. > > > Mark > > ----- Original Message ----- > From: "Mark Davis" > To: ; "Paul Hoffman / IMC" > Sent: Saturday, September 15, 2001 19:03 > Subject: Re: First attempt at problem statement > > > BIDI IDN > > I will try to recap some of the discussions in the ad hoc on BIDI IDN > last week. > > The BIDI algorithm is designed to deal with normal text. Within any > string, sequences of LTR (left to right) and RTL characters will > always appear in the correct order. However, the order of other > characters (such as a period) will depend on their context. For > details, see http://www.unicode.org/reports/tr9/. > > URLs are not normal text, and thus may have odd display. This is > complicated by the fact that the overall paragraph direction has an > effect on the display. Whether the URL is displayed in a RTL or LTR > context will change the order of the components. [In this and other > examples we will use the convention that uppercase letters stand for > right-to-left characters: Arabic, Hebrew, etc.] Example: > > Memory: http://SOME.LARGE.mixed.CORP.org > Display (LTR): http://EGRAL.EMOS.mixed.PROC.org > Display (RTL): org.PROC.mixed.EGRAL.EMOS//:http > > Notice that "SOME.LARGE" always appears from RTL: the period adopts > the order of the surrounding characters. Characters on boundaries > (such as "//:" take on the overall display direction. > > For example: > > (1) characters in different fields may mix across fields: > > Memory: http://SOME.veryLARGE.CORP.org > Display (LTR): http://EMOS.veryPROC.EGRAL.org > Display (RTL): org.PROC.EGRALvery.EMOS//:http > > > (2) two different sequences of characters in the same field can have > the same order when displayed. Thus a user would not know how to type > a URL that he sees printed. > > Memory1: http://123CORP.org > Memory2: http://CORP123.org > Display (LTR): http://123PROC.org > > > The following are proposed requirements. > > 1. Consistent fields. > > (a) If you have fields such as http://XXX.YYY.ZZZ, characters from the > same field should not be displayed in different fields and vice versa. > (b) It should be possible to deduce the order of the backing-store > fields from the order of the display fields. > > 2. Order within fields. > > Within a field, tt should be possible to deduce the order of the > backing-store characters from the order of the display fields. > > 3. No algorithm change > > This should require no change to BIDI algorithm. Using a separate > algorithm for display of URLs would be difficult, since they are found > within flowing text. Getting people to update the BIDI algorithm would > also be quite difficult (and changes to make URLs work might have > repercussions on other text). > > 4. Simplicity > > Whatever solution we have should have a simple algorithm (according to > Paul). > > Ideally, some reasonable restrictions on the contents of a field would > meet all of these requirements. > > > * * * > > During the meeting, I thought that the most straightforward method was > to force the periods to be LTR. However, after looking at the results > in both a RTL and LTR context, I concluded that Mati's approach would > be better. The results both in terms of field order and order within a > field would still be determinate. With any complete URL (with http://, > ftp://, etc.) it would be easy to recognize the order in context, > since the position of those initial letters would show the order. The > only bad case would be where the end of the string reversed because of > its surroundings, e.g.: > > Memory: the url http://SOME.LARGE.mixed.CORP.org is the one > Display (LTR): the url http://EGRAL.EMOS.mixed.PROC.org is the one > Display (RTL): org is the one.PROC.mixed.EGRAL.EMOS//: the url http > > Thus in flowing text, users would be recommended to bracket any BIDI > URL with RLM (or embed the URL). E.g. > > Memory: the url http://SOME.LARGE.mixed.CORP.org is > the one > Display (LTR): the url http://EGRAL.EMOS.mixed.PROC.org is the one > Display (RTL): is the one org.PROC.mixed.EGRAL.EMOS//:http the url > > Software, such as email clients, that recognizes URLs could do this > automatically. > > > Here is what I have now for an explicit algorithm to be added as a > step to NamePrep, after the regular Prohibition step. > > A. Characters are classified into RTL, LTR, DIGIT, OTHER. > > These categories are drawn from the BIDI algorithm. The precise lists > of characters in each category would be added to NamePrep as an > appendix. The composition is as follows (See > http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types). > > LTR := L ; # including LRM > > RTL := R | AL ; > > DIG := EN | AN ; > > OTH := all other characters: NSM, ON, etc. > > Note: The characters in categories LRM, RLM, LRO, RLO, LRE, RLE, PDF, > B, S, and some other BIDI categories are prohibited anyway. > > > B. In any field that contains any RTL characters: > B0. no LTR characters can occur. > C1. a sequence of characters of type DIG can only occur at the end. > C2. a sequence of characters of type OTHER can occur only between > characters of type RTL. > > > The following is an example of an algorithm that implements (B). EOS > stands for "end of string". > > 1. Let S be 0 > 2. Get the next character, then get its numeric type T > 3. Let S be Map[S, T] > 4. If S = T or F, exit with OK or FAIL respectively > 5. Goto Step 2 > > Map is defined by the following table: > > T LTR RTL DIG OTH EOS > S +--------------------- > B | L, R, L, L, F // begin > L | L, F, L, L, T // left > R | F, R, D, O, T // right > O | F, R, F, O, F // right + other > D | F, F, D, F, T // right + digit > > > Mark > __________ > http://www.macchiato.com > ◄ “Eppur si muove” ► > > ----- Original Message ----- > From: "Simon Josefsson" > To: ; > Cc: "IETF/IDN WG" > Sent: Friday, July 26, 2002 20:28 > Subject: [idn] Re: IDN WG Last Call on two major changes to Stringprep > > >> Quoting the draft: >> >> ,---- >> | In any profile that specifies bidirectional character handling, > all >> | three of the following requirements MUST be met: >> ... >> | 2) If a string contains any Right-to-Left character (defined as >> | belonging to Unicode bidirectional categories "R" and "AL"), the > string >> | MUST NOT contain any Left-to-Right character (defined as belonging > to >> | Unicode bidirectional category "L"). >> | >> | 3) If a string contains any Right-to-Left character (as defined > above), >> | a Right-to-Left character MUST be the first character of the > string, and >> | a Right-to-Left character MUST be the last character of the > string. >> `---- >> >> There is little rationale for the last two requirements. Without >> knowing the rationale, it is difficult to understand how to > implement >> this, not to speak of understanding and evaluating the > specification. >> >> It is not difficult to construct various strings that violates these >> requirements, but seem like valid identifiers to me (e.g., U+05D0 >> U+0966, contemplate it being written by a mathematically inclined >> writer in India). Why is U+05D0 a R/AL character but U+2135 not? >> U+2135 is NFKC'd into U+05D0. It thus seems like the identifier is > a >> valid IDN if NFKC is not used, but if NFKC is used, it is not a > valid >> identifier. A bidi user thus seem to require NFKC not to be used in >> order to have the bidi string accepted. >> >> >> From owner-idn@ops.ietf.org Sat Jul 27 18:12:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08068 for ; Sat, 27 Jul 2002 18:12:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YZZ3-000LbU-00 for idn-data@psg.com; Sat, 27 Jul 2002 14:57:29 -0700 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.36 #1) id 17YZYz-000LbJ-00 for idn@ops.ietf.org; Sat, 27 Jul 2002 14:57:25 -0700 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id B27CBD29; Sun, 28 Jul 2002 06:57:15 +0900 (JST) Message-Id: <4.2.0.58.J.20020728065445.04a02710@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 28 Jul 2002 06:57:08 +0900 To: Erik Nordmark , IETF/IDN WG From: Martin Duerst Subject: Re: [idn] IDN WG Last Call on two major changes to Stringprep In-Reply-To: References: <"Your message with ID" <01f801c23133$d00c10e0$5400a8c0@JAMESSONYVAIO> 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 version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk I have reviewed the new draft, and am very happy with the update to Unicode 3.2 and with the inclusion of rules for bidi, which will avoid confusions for conversion between visual and logical order (i.e. display and digital representation). I have not checked the new Unicode 3.2-based data in detail. Regards, Martin. At 15:47 02/07/24 +0200, Erik Nordmark wrote: >Folks, > >I'd like to make sure that these changes to stringprep have been >well-reviewed. >There hasn't been much discussion on the list which could be due to at least >two different reasons: > - the changes are good, well understood, etc. thus there is nothing > to comment on > - not many people have read and understood the changes > >In order to be able to tell the difference I'd appreciate a note (to the >list or directly to me) saying you've reviewed and understood the >changes. > >Thanks, > Erik > >----- Original Message ----- >From: "James Seng" >To: "IETF/IDN WG" >Sent: Sunday, July 07, 2002 4:06 PM >Subject: [idn] IDN WG Last Call on two major changes to Stringprep > > > > The IETF last call have been concluded and the latest version of > > Stringprep is in the I-D directory: > > > > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-04.txt > > > > Other then editorial changes, there are two significant changes*: > > - Reference Unicode 3.2, updating all the tables from 3.1 to 3.2. > > - Additional Bidirection characters handling, Section 6 and Appendix D. > > > > The co-chairs is conducting a working group last call on these two > > significant changes. Please send any proposed modification of text to the > > wg mailing list as well as the wg co-chairs, stating clearly the text to > > be modified and the new text. > > > > This three weeks WG last call will end on 28th July 2002, 23h59 GMT-5. > > (We have a three weeks last call instead of the usual two weeks for those > > who is busy preparing for IETF Yokohama) > > > > Marc & James > > co-chairs > > > > * The previous of Stringprep can be found at > > http://www.potaroo.net/ietf/old-ids/draft-hoffman-stringprep-03.txt > > > > > > > > > From owner-idn@ops.ietf.org Sat Jul 27 18:49:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08390 for ; Sat, 27 Jul 2002 18:49:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YaIF-000NX1-00 for idn-data@psg.com; Sat, 27 Jul 2002 15:44: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 17YaI9-000NWT-00 for idn@ops.ietf.org; Sat, 27 Jul 2002 15:44:05 -0700 Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17YaHS-000Eh5-00; Sat, 27 Jul 2002 22:43:27 +0000 Date: Sat, 27 Jul 2002 12:20:54 -0400 From: John C Klensin To: Mark Davis cc: Simon Josefsson , paul.hoffman@imc.org, Marc.Blanchet@viagenie.qc.ca, "IETF/IDN WG" , Matitiahu Allouche Subject: Re: [idn] Re: IDN WG Last Call on two major changes to Stringprep Message-ID: <9808774.1027772454@localhost> In-Reply-To: <001201c2357d$0c38fa40$8900a8c0@c1340594a> References: <001201c2357d$0c38fa40$8900a8c0@c1340594a> 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.7 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,DATE_IN_PAST_06_12 version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, 27 July, 2002 07:51 -0700 Mark Davis wrote: >... >> During the meeting, I thought that the most straightforward >> method was >> to force the periods to be LTR. However, after looking at the >> results >> in both a RTL and LTR context, I concluded that Mati's approach >> would >> be better. The results both in terms of field order and order >> within a >> field would still be determinate. With any complete URL (with >> http://, ftp://, etc.) it would be easy to recognize the order >> in context, since the position of those initial letters would >> show the order. >> The >> only bad case would be where the end of the string reversed >> because of >> its surroundings, e.g.: >> >> Memory: the url http://SOME.LARGE.mixed.CORP.org is >> the one Display (LTR): the url >> http://EGRAL.EMOS.mixed.PROC.org is the one Display (RTL): >> org is the one.PROC.mixed.EGRAL.EMOS//: the url http >> >> Thus in flowing text, users would be recommended to bracket >> any BIDI URL with RLM (or embed the URL). E.g. >... Mark, As I understand it, this essentially implies that an IDN, or at least an IDN that might contain RTL characters, is not interpretable unambiguously unless it appears as part of a fully-spelled-out URL. I can't imagine that being acceptable. I can't even imagine it being acceptable to require that IDNs appear in URLs at all to be valid. To repeat something I seem to need to say in every talk I give about these issues, "the web is not the net". This WG is tasked with internationalizing _domain names_, not URLs. An acceptable URL solution may also be a requirement, but that is a side-effect. john From owner-idn@ops.ietf.org Sat Jul 27 20:11:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09081 for ; Sat, 27 Jul 2002 20:11:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YbYN-0000r8-00 for idn-data@psg.com; Sat, 27 Jul 2002 17:04:55 -0700 Received: from relay1.pair.com ([209.68.1.20] helo=relay.pair.com) by psg.com with smtp (Exim 3.36 #1) id 17YbYJ-0000qx-00 for idn@ops.ietf.org; Sat, 27 Jul 2002 17:04:51 -0700 Received: (qmail 33654 invoked from network); 28 Jul 2002 00:04:50 -0000 Received: from 12-234-224-41.client.attbi.com (HELO c1340594a) (12.234.224.41) by relay1.pair.com with SMTP; 28 Jul 2002 00:04:50 -0000 X-pair-Authenticated: 12.234.224.41 Message-ID: <002d01c235ca$a79215b0$8900a8c0@c1340594a> From: "Mark Davis" To: "John C Klensin" Cc: "Simon Josefsson" , , , "IETF/IDN WG" , "Matitiahu Allouche" References: <001201c2357d$0c38fa40$8900a8c0@c1340594a> <9808774.1027772454@localhost> Subject: Re: [idn] Re: IDN WG Last Call on two major changes to Stringprep Date: Sat, 27 Jul 2002 17:06:41 -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=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > As I understand it, this essentially implies that an IDN, or at > least an IDN that might contain RTL characters, is not > interpretable unambiguously unless it appears as part of a > fully-spelled-out URL. No, it is the converse. > This WG is tasked with internationalizing _domain names_, not > URLs. An acceptable URL solution may also be a requirement, but > that is a side-effect. Understood. However, having these restrictions in domain names is a step towards internationizing URLs, and one without which it would be difficult. Mark __________ http://www.macchiato.com ◄ “Eppur si muove” ► ----- Original Message ----- From: "John C Klensin" To: "Mark Davis" Cc: "Simon Josefsson" ; ; ; "IETF/IDN WG" ; "Matitiahu Allouche" Sent: Saturday, July 27, 2002 09:20 Subject: Re: [idn] Re: IDN WG Last Call on two major changes to Stringprep > > > --On Saturday, 27 July, 2002 07:51 -0700 Mark Davis > wrote: > > >... > >> During the meeting, I thought that the most straightforward > >> method was > >> to force the periods to be LTR. However, after looking at the > >> results > >> in both a RTL and LTR context, I concluded that Mati's approach > >> would > >> be better. The results both in terms of field order and order > >> within a > >> field would still be determinate. With any complete URL (with > >> http://, ftp://, etc.) it would be easy to recognize the order > >> in context, since the position of those initial letters would > >> show the order. > >> The > >> only bad case would be where the end of the string reversed > >> because of > >> its surroundings, e.g.: > >> > >> Memory: the url http://SOME.LARGE.mixed.CORP.org is > >> the one Display (LTR): the url > >> http://EGRAL.EMOS.mixed.PROC.org is the one Display (RTL): > >> org is the one.PROC.mixed.EGRAL.EMOS//: the url http > >> > >> Thus in flowing text, users would be recommended to bracket > >> any BIDI URL with RLM (or embed the URL). E.g. > >... > > Mark, > > As I understand it, this essentially implies that an IDN, or at > least an IDN that might contain RTL characters, is not > interpretable unambiguously unless it appears as part of a > fully-spelled-out URL. I can't imagine that being acceptable. I > can't even imagine it being acceptable to require that IDNs > appear in URLs at all to be valid. > > To repeat something I seem to need to say in every talk I give > about these issues, > "the web is not the net". > This WG is tasked with internationalizing _domain names_, not > URLs. An acceptable URL solution may also be a requirement, but > that is a side-effect. > > john > > > From owner-idn@ops.ietf.org Wed Jul 31 20:21:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22361 for ; Wed, 31 Jul 2002 20:21:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17a3UO-000Mhj-00 for idn-data@psg.com; Wed, 31 Jul 2002 17:06:48 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17a3UI-000MhN-00 for idn@ops.ietf.org; Wed, 31 Jul 2002 17:06:42 -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 SAA11154 for ; Wed, 31 Jul 2002 18:06:41 -0600 (MDT) Received: from lillen (d-umpk17-99-214.Eng.Sun.COM [129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g7106dg23277 for ; Thu, 1 Aug 2002 02:06:39 +0200 (MEST) Date: Thu, 1 Aug 2002 02:04:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [idn] Comment on Nameprep To: idn@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-idn@ops.ietf.org Precedence: bulk Forwarded with permission. >----- Begin Included Message -----< Date: Mon, 3 Jun 2002 09:51:10 +0300 From: "Matitiahu Allouche" Subject: Comment on Nameprep To: iesg@ietf.org Despite some discussion about restrictions that should be set on Bidi characters in internationalized domain names, none of those have been integrated in the document. I therefore propose to add the following section. ===== Start of proposed additional text ===== 5.2 Inappropriate combinations involving Right-to-Left characters 5.2.1 If a domain name label contains any Right-to-Left character (defined as belonging to Unicode Bidirectional categories R and AL), it MUST NOT contain any Left-to-Right character (defined as belonging to Unicode Bid irectional category L). 5.2.2 If a domain name label contains any Right-to-Left character (as defined above), a Right-to-Left character MUST be the first character of the label, and a Right-to-Left character MUST be the last character of the label. ===== End of proposed additional text ===== The objective of these restrictions is to avoid ambiguities (one label display which may correspond to different character sequences) and "blending" of text across label boundaries due to the Bidirectional display algorithm. In the example below, upper case Latin letters represent Right-to-Left characters, lower case Latin letters represent Left-to-Right characters. Example 1 Storage: www.travel.madridTOparis.com Display (assuming a Left-to-Right context): www.travel.madridOTparis.com Display (assuming a Right-to-Left context): paris.comOT.www.travel.madrid Part of the confusion is avoided by restriction 5.2.1. Example 2 (assuming a Left-to-Right context): Display: www.123ABC.com Storage: www.123CBA.com OR www.CBA123.com OR www.1CBA23.com etc... Such ambiguity is avoided by restriction 5.2.2. Example 3 (assuming a Left-to-Right context): Storage: www.abcDEF.GHIjkl.com Display: www.abcIHG.FEDjkl.com The blending of parts of different labels is avoided by restriction 5.2.1. These restrictions do not prevent all possible confusions and ambiguities when Right-to-Left characters are used in domain names. However, this is the most that can be achieved when the rules are applied to each label separately, as defined in Nameprep introduction. They are also very easy to understand and to implement. Shalom (Regards), Mati Bidi Architect Globalization Center Of Competency - Bidirectional Scripts IBM Israel Phone: +972 2 5870999 ext. 1202 Fax: +972 2 5870333 Mobile: +972 52 554160 >----- End Included Message -----<