From owner-idn@ops.ietf.org Thu Feb 1 09:10:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27472 for ; Thu, 1 Feb 2001 09:10:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OJnR-000NsJ-00 for idn-data@psg.com; Thu, 01 Feb 2001 05:29:09 -0800 Received: from mail-gw.im.se ([193.14.22.222] helo=mail-gw.imt.im.se) by psg.com with esmtp (Exim 3.16 #1) id 14OJnQ-000NsC-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 05:29:08 -0800 Received: from MSXSTH1.im.se (msxsth1.im.se [193.14.16.108]) by mail-gw.imt.im.se (8.11.0/8.11.0) with ESMTP id f11DMmD127406 for ; Thu, 1 Feb 2001 14:22:48 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 14:27:59 +0100 Message-ID: From: Karlsson Kent - keka To: idn@ops.ietf.org Subject: RE: [idn] Fast nameprep vs. slow nameprep Date: Thu, 1 Feb 2001 14:25:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA27472 I'm not sure where the idea of doing "nameprepping" in the keyboard 'interface' came from. I'm not sure what interface is meant here, but it appears that "the same level(s) as where dead key handling and IME switching is done" is what's intended. I find any suggestion to do "nameprepping" or even "ACE"ing in the 'keyboard interface' to be out of the question. Do you expect system providers to make a special "IDN mode" for the keyboards? Why? And why would that solve anything? If you paste in text, the keyboard handling is not involved after the "cmd-v" (or whatever). Why should the keyboard handling be changed to map out soft hyphens (alt-- on some keyboards), and map to in some new "IDN mode"? Do you expect some "automagic" switching between these modes? Or is Joe User expected to change to "IDN mode" for entering IDNs (and out again after)? Neither will work! Can please the keyboard interfaces be left out of this discussion. It's far out of scope for the IDN WG. "nameprepping" must be done at some other place than in the keyboard handling! /kent k > -----Original Message----- > From: D. J. Bernstein [mailto:djb@cr.yp.to] > Sent: Tuesday, January 30, 2001 10:22 AM > To: idn@ops.ietf.org > Subject: Re: [idn] Fast nameprep vs. slow nameprep > > > There are five possible approaches under discussion: > > (1) [...] > The keyboard interface has to help users type good names. ... > > (2) [...] > This lets us leave the keyboard interface alone, at the expense > of putting nameprep into a huge number of programs. Yuck. ... > (3) [...] > The keyboard interface has to help users type good names. ... > (4) [...] > The keyboard interface has to help users type good names and > convert them to ACE. ... > (5) [...] > This lets us leave the keyboard interface alone. From owner-idn@ops.ietf.org Thu Feb 1 12:26:08 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03764 for ; Thu, 1 Feb 2001 12:26:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OMyX-0002jm-00 for idn-data@psg.com; Thu, 01 Feb 2001 08:52:49 -0800 Received: from femail2.sdc1.sfba.home.com ([24.0.95.82]) by psg.com with esmtp (Exim 3.16 #1) id 14OMyW-0002je-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 08:52:48 -0800 Received: from c1340594a ([65.11.104.12]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010201165218.TWUA27594.femail2.sdc1.sfba.home.com@c1340594a>; Thu, 1 Feb 2001 08:52:18 -0800 Message-ID: <00b201c08c6f$90929d40$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Karlsson Kent - keka" , References: Subject: Re: [idn] Fast nameprep vs. slow nameprep Date: Thu, 1 Feb 2001 08:53:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I agree that the term is confusing. I think part of the issue is that different people may have different usage models in mind. Let's look at some specific scenarios, starting with a browser. This might reveal where we have different models in mind. Scenario A. User opens browser, types in the URL in the Address field, hits return. - S/he has typed in using some default character set. Browser takes contents of Address field, and: 1. Converts to UTF-8 if not already 2. Applies NamePrep to the results, field at a time. - If something is wrong, signals to user and stops. 3. Applies *ACE to result, field at a time. - If something is wrong, signals to user and stops. 4. Uses the results as it would have formerly. Scenario B. A web page contains a link such as Hotel Reservation Form [The non-latin text examples are not real -- just for the sake of example.] When the user clicks on the visual representation of this link, the browser will take the URL and apply NamePrep/*ACE (signalling if the result is invalid) as above. Scenario C. A web page contains a link such as Hotel Reservation Form [The ACE examples are not real -- just for the sake of example.] This is an interesting case. In processing a URL field by field, if a field already contains an ACEd result, the browser could leave it alone. If it is not valid, it will not match a host name. A somewhat user-friendlier approach would be to check it for NamePrep/ACE validity and signal that at an earlier stage. Note: From what I recall of the discussion, given a URL like href="http://標準萬國碼.Юникод.org/Ιούνικοντ.html">, the browser would only apply NamePrep/ACE to "標準萬國碼.Юникод.org", and NOT to "Ιούνικοντ.html". The segment "Ιούνικοντ.html" would represented by encoded in UTF-8, with any bytes outside of [21..7E] using %xx notation. [http://www.w3.org/TR/charmod/#sec-URIs] Mark ----- Original Message ----- From: "Karlsson Kent - keka" To: Sent: Thursday, February 01, 2001 05:25 Subject: RE: [idn] Fast nameprep vs. slow nameprep I'm not sure where the idea of doing "nameprepping" in the keyboard 'interface' came from. I'm not sure what interface is meant here, but it appears that "the same level(s) as where dead key handling and IME switching is done" is what's intended. I find any suggestion to do "nameprepping" or even "ACE"ing in the 'keyboard interface' to be out of the question. Do you expect system providers to make a special "IDN mode" for the keyboards? Why? And why would that solve anything? If you paste in text, the keyboard handling is not involved after the "cmd-v" (or whatever). Why should the keyboard handling be changed to map out soft hyphens (alt-- on some keyboards), and map Å to å in some new "IDN mode"? Do you expect some "automagic" switching between these modes? Or is Joe User expected to change to "IDN mode" for entering IDNs (and out again after)? Neither will work! Can please the keyboard interfaces be left out of this discussion. It's far out of scope for the IDN WG. "nameprepping" must be done at some other place than in the keyboard handling! /kent k > -----Original Message----- > From: D. J. Bernstein [mailto:djb@cr.yp.to] > Sent: Tuesday, January 30, 2001 10:22 AM > To: idn@ops.ietf.org > Subject: Re: [idn] Fast nameprep vs. slow nameprep > > > There are five possible approaches under discussion: > > (1) [...] > The keyboard interface has to help users type good names. ... > > (2) [...] > This lets us leave the keyboard interface alone, at the expense > of putting nameprep into a huge number of programs. Yuck. ... > (3) [...] > The keyboard interface has to help users type good names. ... > (4) [...] > The keyboard interface has to help users type good names and > convert them to ACE. ... > (5) [...] > This lets us leave the keyboard interface alone. From owner-idn@ops.ietf.org Thu Feb 1 13:27:09 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05821 for ; Thu, 1 Feb 2001 13:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OO3a-0004WV-00 for idn-data@psg.com; Thu, 01 Feb 2001 10:02:06 -0800 Received: from mail-gw.im.se ([193.14.22.222] helo=mail-gw.imt.im.se) by psg.com with esmtp (Exim 3.16 #1) id 14OO3Y-0004WO-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 10:02:05 -0800 Received: from MSXSTH1.im.se (msxsth1.im.se [193.14.16.108]) by mail-gw.imt.im.se (8.11.0/8.11.0) with ESMTP id f11HtiD126448 for ; Thu, 1 Feb 2001 18:55:44 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 19:00:55 +0100 Message-ID: From: Karlsson Kent - keka To: idn@ops.ietf.org Subject: RE: [idn] Fast nameprep vs. slow nameprep Date: Thu, 1 Feb 2001 18:58:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="UTF-8" Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05821 I agree (nearly) with your examples (usage scenarios), though they only cover the browser/e-mail program/... user side; not the DNS manager side (which I think D.J. and Patrik were more concerned with). However, none of your usage scenarios have anything to do with the keyboard interface at any level (which is good). Even in the first one, the user is done typing the entier URL well before any nameprep or ACE processing is done. Similarly for the DNS manager side, whether one uses a GUI program specific for DNS management or uses plain text zone files or whatever, the keyboard handling is far removed from any nameprep or ACE processing in any reasonable system. Regarding scenario A: neither "nameprepping" or "ACE"ing requires the input to be UTF-8 do they? It may be, e.g., UTF-16 at that stage. Regarding scenario C: "nameprepping" should be done on the entire IDN, which can then map fullwidth full stop to full stop (and possibly ideographic full stop to full stop) before parsing into name "parts". /kent k > -----Original Message----- > From: Mark Davis [mailto:markdavis34@home.com] > Sent: Thursday, February 01, 2001 5:54 PM > To: Karlsson Kent - keka; idn@ops.ietf.org > Subject: Re: [idn] Fast nameprep vs. slow nameprep > > > I agree that the term is confusing. I think part of the issue is that > different people may have different usage models in mind. > Let's look at some > specific scenarios, starting with a browser. This might > reveal where we have > different models in mind. > > > Scenario A. > User opens browser, types in the URL in the Address field, > hits return. > - S/he has typed in using some default character set. > Browser takes contents of Address field, and: > 1. Converts to UTF-8 if not already > 2. Applies NamePrep to the results, field at a time. > - If something is wrong, signals to user and stops. > 3. Applies *ACE to result, field at a time. > - If something is wrong, signals to user and stops. > 4. Uses the results as it would have formerly. > > > Scenario B. > A web page contains a link such as > > Hotel > Reservation Form > > [The non-latin text examples are not real -- just for the > sake of example.] > > When the user clicks on the visual representation of this > link, the browser > will take the URL and apply NamePrep/*ACE (signalling if the result is > invalid) as above. > > > Scenario C. > A web page contains a link such as > > Hotel > Reservation > Form > > [The ACE examples are not real -- just for the sake of example.] > > This is an interesting case. In processing a URL field by > field, if a field > already contains an ACEd result, the browser could leave it > alone. If it is > not valid, it will not match a host name. A somewhat user-friendlier > approach would be to check it for NamePrep/ACE validity and > signal that at > an earlier stage. > > > Note: From what I recall of the discussion, given a URL like > href="http://標準萬國碼.Юникод.org/Ιούνικοντ.html">, the browser > would only apply > NamePrep/ACE to "標準萬國碼.Юникод.org", and NOT to "Ιούνικον > τ.html". The segment > "Ιούνικοντ.html" would represented by encoded in UTF-8, with any bytes > outside of [21..7E] using %xx notation. > [http://www.w3.org/TR/charmod/#sec-URIs] > > Mark > > ----- Original Message ----- > From: "Karlsson Kent - keka" > To: > Sent: Thursday, February 01, 2001 05:25 > Subject: RE: [idn] Fast nameprep vs. slow nameprep > > > > I'm not sure where the idea of doing "nameprepping" in the keyboard > 'interface' came from. I'm not sure what interface is meant here, > but it appears that "the same level(s) as where dead key handling > and IME switching is done" is what's intended. > > I find any suggestion to do "nameprepping" or even "ACE"ing in the > 'keyboard interface' to be out of the question. Do you expect system > providers to make a special "IDN mode" for the keyboards? Why? > And why would that solve anything? If you paste in text, the keyboard > handling is not involved after the "cmd-v" (or whatever). Why should > the keyboard handling be changed to map out soft hyphens (alt-- on > some keyboards), and map Å to å in some new "IDN mode"? Do you expect > some "automagic" switching between these modes? Or is Joe User > expected to change to "IDN mode" for entering IDNs (and out again > after)? Neither will work! > > Can please the keyboard interfaces be left out of this discussion. > It's far out of scope for the IDN WG. "nameprepping" must be done > at some other place than in the keyboard handling! > > /kent k > > > > > -----Original Message----- > > From: D. J. Bernstein [mailto:djb@cr.yp.to] > > Sent: Tuesday, January 30, 2001 10:22 AM > > To: idn@ops.ietf.org > > Subject: Re: [idn] Fast nameprep vs. slow nameprep > > > > > > There are five possible approaches under discussion: > > > > (1) [...] > > The keyboard interface has to help users type good names. > ... > > > > (2) [...] > > This lets us leave the keyboard interface alone, at > the expense > > of putting nameprep into a huge number of programs. Yuck. > ... > > (3) [...] > > The keyboard interface has to help users type good names. > ... > > (4) [...] > > The keyboard interface has to help users type good names and > > convert them to ACE. > ... > > (5) [...] > > This lets us leave the keyboard interface alone. > > > > From owner-idn@ops.ietf.org Thu Feb 1 13:46:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06927 for ; Thu, 1 Feb 2001 13:46:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OOUZ-0005IV-00 for idn-data@psg.com; Thu, 01 Feb 2001 10:29:59 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14OOUY-0005IN-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 10:29:58 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA24493; Thu, 1 Feb 2001 13:29:44 -0500 (EST) Message-Id: <200102011829.NAA24493@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Davis" cc: "Karlsson Kent - keka" , idn@ops.ietf.org Subject: Re: [idn] Fast nameprep vs. slow nameprep In-reply-to: Your message of "Thu, 01 Feb 2001 08:53:55 PST." <00b201c08c6f$90929d40$0c680b41@c1340594a> Date: Thu, 01 Feb 2001 13:29:43 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk note that in the case of your scenario B - a URL within a web page will be in the document character set, which might or might not be UTF-8. so it might also need translation in addition to nameprep and ACE. From owner-idn@ops.ietf.org Thu Feb 1 17:57:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13743 for ; Thu, 1 Feb 2001 17:57:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OS6J-0009fp-00 for idn-data@psg.com; Thu, 01 Feb 2001 14:21:11 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14OS6I-0009fY-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 14:21:10 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA27786 for ; Thu, 1 Feb 2001 14:20:51 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f11MKcP29514 for ; Thu, 1 Feb 2001 14:20:38 -0800 (PST) Received: from [130.242.18.113] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA23827 for ; Thu, 1 Feb 2001 14:20:35 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 1 Feb 2001 23:15:14 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [idn] Fast nameprep vs. slow nameprep Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 18.58 +0100 01-02-01, Karlsson Kent - keka wrote: >However, none of your usage >scenarios have anything to do with the keyboard interface >at any level (which is good). I created the confusion by seeing the need that the nameprep is NOT done in the resolver libraries or in the DNS server, i.e. somewhere between the keyboard and the application layer protocols (out of which DNS is one). paf From owner-idn@ops.ietf.org Thu Feb 1 19:26:10 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15381 for ; Thu, 1 Feb 2001 19:26:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OTiY-000BSg-00 for idn-data@psg.com; Thu, 01 Feb 2001 16:04:46 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14OTiX-000BSY-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 16:04:45 -0800 Received: (qmail 32497 invoked by uid 1001); 1 Feb 2001 23:29:51 -0000 Date: 1 Feb 2001 23:29:51 -0000 Message-ID: <20010201232951.18698.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Fast nameprep vs. slow nameprep References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Karlsson Kent - keka writes: > Do you expect system > providers to make a special "IDN mode" for the keyboards? It seems that no effort is necessary for European locales: the existing keyboard interfaces already produce KC-normalized strings. (I have no idea why you're worried about soft hyphens. Why would a user type a soft hyphen inside a domain name? The keyboard interface doesn't have to remove them; they simply won't work.) In Japan, on the other hand, we've heard that users already have to change keyboard modes to type domain names. Otherwise they don't even get the right dot! > If you paste in text, Good UTF-8 domain names will be preserved by copy-and-paste. There's no need for further nameprep. > Can please the keyboard interfaces be left out of this discussion. > It's far out of scope for the IDN WG. Wrong. The whole point of IDNs is to let users read and write non-ASCII characters in domain names. The entire path from keyboard to computer to screen---as the charter says, ``the use of such names by humans''---is within the scope of the IDN WG. ---Dan From owner-idn@ops.ietf.org Thu Feb 1 19:45:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15584 for ; Thu, 1 Feb 2001 19:45:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OU13-000Bkf-00 for idn-data@psg.com; Thu, 01 Feb 2001 16:23:53 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14OU12-000BkY-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 16:23:52 -0800 Received: (qmail 21994 invoked by uid 1001); 2 Feb 2001 00:03:37 -0000 Date: 2 Feb 2001 00:03:37 -0000 Message-ID: <20010202000337.19528.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 References: <20010130095615.27316.qmail@cr.yp.to> <200101301733.MAA04523@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk I've sent nameprepped UTF-8 names through many programs without trouble. It's really quite rare for a UNIX program to mangle 8-bit characters. (Sendmail is an exception, because of its clumsy string handling.) Of course, programs that align text on a terminal---for example, mail clients such as Mutt, and editors such as Emacs---have to understand the width of a UTF-8 string. In most cases they already do, and in other cases the upgrades will be done soon. UTF-8 IDNs will also need mail clients to assume that message header fields use UTF-8. I'm counting this upgrade and redeployment as part of the cost of UTF-8 IDNs. Keith keeps claiming that there are many more programs that would have to be upgraded for UTF-8, but he refuses to name any of those programs. Am I the only person who thinks our decisions should be based on facts? ---Dan From owner-idn@ops.ietf.org Thu Feb 1 20:09:53 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15946 for ; Thu, 1 Feb 2001 20:09:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OUVg-000CCl-00 for idn-data@psg.com; Thu, 01 Feb 2001 16:55:32 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14OUVf-000CCR-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 16:55:31 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA28547; Thu, 1 Feb 2001 19:55:28 -0500 (EST) Message-Id: <200102020055.TAA28547@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 In-reply-to: Your message of "02 Feb 2001 00:03:37 GMT." <20010202000337.19528.qmail@cr.yp.to> Date: Thu, 01 Feb 2001 19:55:28 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Am I the only person who thinks our decisions should be based on facts? No, you're the only person who thinks that our decisions should be based on gross extrapolations from a small sample of tests that you've done. Keith From owner-idn@ops.ietf.org Thu Feb 1 20:44:11 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16831 for ; Thu, 1 Feb 2001 20:44:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OUzr-000Ci9-00 for idn-data@psg.com; Thu, 01 Feb 2001 17:26:43 -0800 Date: Thu, 1 Feb 2001 23:18:38 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: [idn] New mailing list for IDNA discussions Cc: Ned Freed Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: A new mailing list is created where IDNA is discussed. The name of the mailing list is ietf-idna@mail.apps.ietf.org, and subscription is done by sending a mail to ietf-idna-request@mail.apps.ietf.org, with the word "subscribe" as the only word in the body. I thank my co-AD Ned Freed for setting up the mailing list. paf -- Patrik Fltstrm Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-idn@ops.ietf.org Thu Feb 1 20:54:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16951 for ; Thu, 1 Feb 2001 20:54:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OVBV-000Cuf-00 for idn-data@psg.com; Thu, 01 Feb 2001 17:38:45 -0800 Received: from ns2.globaldns.com ([206.253.214.12]) by psg.com with esmtp (Exim 3.16 #1) id 14OVBU-000CuY-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 17:38:44 -0800 Received: from enic.cc (tailback.enic.cc [206.253.214.252]) by ns2.globaldns.com (8.8.7/8.8.7) with ESMTP id RAA22983; Thu, 1 Feb 2001 17:33:27 -0800 (PST) (envelope-from dan@enic.cc) Message-ID: <3A7A0FF5.F0419596@enic.cc> Date: Thu, 01 Feb 2001 17:40:05 -0800 From: Dan Ebert Organization: eNIC Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: idn@ops.ietf.org Subject: Re: [idn] Fast nameprep vs. slow nameprep References: <200102011829.NAA24493@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > > note that in the case of your scenario B - a URL within a web page > will be in the document character set, which might or might not be > UTF-8. so it might also need translation in addition to nameprep > and ACE. It seems to me that there would also be a possible (probable?) need for translation from an OS character set (Big 5, GB 2312, ISO8859-x, etc.) to UTF-8 (and to ACE?) when a user types a multilingual domainname into a browser's location bar. -- Dan Ebert dan@enic.cc eNIC Corporation From owner-idn@ops.ietf.org Thu Feb 1 21:15:16 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17086 for ; Thu, 1 Feb 2001 21:15:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OVMs-000D8q-00 for idn-data@psg.com; Thu, 01 Feb 2001 17:50:30 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14OVMr-000D8k-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 17:50:29 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA29074; Thu, 1 Feb 2001 20:50:20 -0500 (EST) Message-Id: <200102020150.UAA29074@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Ebert cc: Keith Moore , idn@ops.ietf.org Subject: Re: [idn] Fast nameprep vs. slow nameprep In-reply-to: Your message of "Thu, 01 Feb 2001 17:40:05 PST." <3A7A0FF5.F0419596@enic.cc> Date: Thu, 01 Feb 2001 20:50:20 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > note that in the case of your scenario B - a URL within a web page > > will be in the document character set, which might or might not be > > UTF-8. so it might also need translation in addition to nameprep > > and ACE. > > It seems to me that there would also be a possible (probable?) need for > translation from an OS character set (Big 5, GB 2312, ISO8859-x, etc.) > to UTF-8 (and to ACE?) when a user types a multilingual domainname into > a browser's location bar. I concur. Keith From owner-idn@ops.ietf.org Thu Feb 1 21:28:14 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17181 for ; Thu, 1 Feb 2001 21:28:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OVnX-000DgF-00 for idn-data@psg.com; Thu, 01 Feb 2001 18:18:03 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14OVnV-000Dg8-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 18:18:02 -0800 Received: from jamessonyvaio (PPPa81-ResaleDialinx8005-1R7256.dialinx.net [4.16.72.142]) by mail.i-dns.net (Postfix) with SMTP id 001C1FFC0D; Fri, 2 Feb 2001 10:17:44 +0800 (SGT) Message-ID: <054001c08cbe$2b267770$95ce1004@jamessonyvaio> From: "James Seng/Personal" To: "Dan Ebert" , "Keith Moore" Cc: References: <200102011829.NAA24493@astro.cs.utk.edu> <3A7A0FF5.F0419596@enic.cc> Subject: Re: [idn] Fast nameprep vs. slow nameprep Date: Fri, 2 Feb 2001 10:16:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I suggest reading the I-D IDNA (or IDNRA) draft. This issue has been discussed in the I-D. -James Seng ----- Original Message ----- From: "Dan Ebert" To: "Keith Moore" Cc: Sent: Friday, February 02, 2001 9:40 AM Subject: Re: [idn] Fast nameprep vs. slow nameprep > Keith Moore wrote: > > > > note that in the case of your scenario B - a URL within a web page > > will be in the document character set, which might or might not be > > UTF-8. so it might also need translation in addition to nameprep > > and ACE. > > It seems to me that there would also be a possible (probable?) need for > translation from an OS character set (Big 5, GB 2312, ISO8859-x, etc.) > to UTF-8 (and to ACE?) when a user types a multilingual domainname into > a browser's location bar. > > -- > Dan Ebert dan@enic.cc eNIC Corporation > From owner-idn@ops.ietf.org Thu Feb 1 21:36:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18222 for ; Thu, 1 Feb 2001 21:36:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OVq1-000Dix-00 for idn-data@psg.com; Thu, 01 Feb 2001 18:20:37 -0800 Received: from epa.secret.org ([206.220.140.150] ident=0) by psg.com with esmtp (Exim 3.16 #1) id 14OVq0-000Diq-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 18:20:36 -0800 Received: from localhost (lucid@localhost) by epa.secret.org (8.9.3/8.9.1) with ESMTP id VAA25024 for ; Thu, 1 Feb 2001 21:20:34 -0500 (EST) Date: Thu, 1 Feb 2001 21:20:34 -0500 (EST) From: lucid@epa.secret.org To: idn@ops.ietf.org Subject: [idn] Cell phones and japan. In-Reply-To: <3A7A0FF5.F0419596@enic.cc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk I just got back from a weeklong vacation in japan. It seems to me that everyone I met there gets email thru their cell phone. Text entry is menu based with kanji selected via a joystick like nub. Possible issues include; How much memory does an implementation of name prep require? What encoding do these wireless devices use? Can they even handle ACE? Should we even worry? From owner-idn@ops.ietf.org Thu Feb 1 21:59:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18431 for ; Thu, 1 Feb 2001 21:59:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OW9b-000E6w-00 for idn-data@psg.com; Thu, 01 Feb 2001 18:40:51 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14OW9a-000E6q-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 18:40:50 -0800 Received: from jamessonyvaio (PPPa78-ResaleDialinx80019-4R7336.dialinx.net [4.16.65.171]) by mail.i-dns.net (Postfix) with SMTP id EE0E3FFC0A; Fri, 2 Feb 2001 10:40:34 +0800 (SGT) Message-ID: <059001c08cc1$5af3ae70$95ce1004@jamessonyvaio> From: "James Seng/Personal" To: , References: Subject: Re: [idn] Cell phones and japan. Date: Fri, 2 Feb 2001 10:39:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You have underestimated the capability of the phone. Put it this way. If a phone can handle input in romanji with fonts for a few thousand kanji using a 12-key number pad, with 120x320 TFT color screen capable of doing java and games and video conferencing, I am not sure if nameprep is an issue should they decided to do it. -James Seng ----- Original Message ----- From: To: Sent: Friday, February 02, 2001 10:20 AM Subject: [idn] Cell phones and japan. > > I just got back from a weeklong vacation in japan. It seems to me that > everyone I met there gets email thru their cell phone. Text entry is menu > based with kanji selected via a joystick like nub. > > Possible issues include; > How much memory does an implementation of name prep require? > What encoding do these wireless devices use? > Can they even handle ACE? > Should we even worry? > > > > From owner-idn@ops.ietf.org Thu Feb 1 22:09:34 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18432 for ; Thu, 1 Feb 2001 21:59:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OW9X-000E6n-00 for idn-data@psg.com; Thu, 01 Feb 2001 18:40:47 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14OW9W-000E6h-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 18:40:47 -0800 Received: from jamessonyvaio (PPPa78-ResaleDialinx80019-4R7336.dialinx.net [4.16.65.171]) by mail.i-dns.net (Postfix) with SMTP id D093EFFC09; Fri, 2 Feb 2001 10:40:26 +0800 (SGT) Message-ID: <058f01c08cc1$56334030$95ce1004@jamessonyvaio> From: "James Seng/Personal" To: , References: Subject: Re: [idn] Cell phones and japan. Date: Fri, 2 Feb 2001 10:38:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You have underestimated the capability of the phone. Put it this way. If a phone can handle input in romanji with fonts for a few thousand kanji using a 12-key number pad, with 120x320 TFT color screen capable of doing java and video conferencing and gaming, I am not sure if nameprep is an issue should they decided to do it. -James Seng ----- Original Message ----- From: To: Sent: Friday, February 02, 2001 10:20 AM Subject: [idn] Cell phones and japan. > > I just got back from a weeklong vacation in japan. It seems to me that > everyone I met there gets email thru their cell phone. Text entry is menu > based with kanji selected via a joystick like nub. > > Possible issues include; > How much memory does an implementation of name prep require? > What encoding do these wireless devices use? > Can they even handle ACE? > Should we even worry? > > > > From owner-idn@ops.ietf.org Thu Feb 1 23:30:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19855 for ; Thu, 1 Feb 2001 23:30:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OXHY-000FIq-00 for idn-data@psg.com; Thu, 01 Feb 2001 19:53:08 -0800 Received: from femail2.sdc1.sfba.home.com ([24.0.95.82]) by psg.com with esmtp (Exim 3.16 #1) id 14OXHX-000FIj-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 19:53:07 -0800 Received: from c1340594a ([65.11.104.12]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010202035239.LBDD27594.femail2.sdc1.sfba.home.com@c1340594a>; Thu, 1 Feb 2001 19:52:39 -0800 Message-ID: <003501c08ccb$d07a2750$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "James Seng/Personal" , , References: <058f01c08cc1$56334030$95ce1004@jamessonyvaio> Subject: Re: [idn] Cell phones and japan. Date: Thu, 1 Feb 2001 19:54:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I believe I sent this out before, but just in case people hadn't seen it: http://www.macchiato.com/unicode/normalization_footprint.htm Mark ----- Original Message ----- From: "James Seng/Personal" To: ; Sent: Thursday, February 01, 2001 18:38 Subject: Re: [idn] Cell phones and japan. > You have underestimated the capability of the phone. > > Put it this way. If a phone can handle input in romanji with fonts for a > few thousand kanji using a 12-key number pad, with 120x320 TFT color > screen capable of doing java and video conferencing and gaming, I am not > sure if nameprep is an issue should they decided to do it. > > -James Seng > > ----- Original Message ----- > From: > To: > Sent: Friday, February 02, 2001 10:20 AM > Subject: [idn] Cell phones and japan. > > > > > > I just got back from a weeklong vacation in japan. It seems to me that > > everyone I met there gets email thru their cell phone. Text entry is > menu > > based with kanji selected via a joystick like nub. > > > > Possible issues include; > > How much memory does an implementation of name prep require? > > What encoding do these wireless devices use? > > Can they even handle ACE? > > Should we even worry? > > > > > > > > > > > From owner-idn@ops.ietf.org Fri Feb 2 02:41:28 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04712 for ; Fri, 2 Feb 2001 02:41:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OaKg-000It0-00 for idn-data@psg.com; Thu, 01 Feb 2001 23:08:34 -0800 Received: from dokka.maxware.no ([195.139.236.69]) by psg.com with esmtp (Exim 3.16 #1) id 14OaKf-000Isu-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 23:08:33 -0800 Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id IAA28438; Fri, 2 Feb 2001 08:08:21 +0100 Message-Id: <4.3.2.7.2.20010201020945.02f27c08@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Feb 2001 02:14:33 -0800 To: "D. J. Bernstein" , idn@ops.ietf.org From: Harald Alvestrand Subject: Re: [idn] Fast nameprep vs. slow nameprep In-Reply-To: <20010130092212.23751.qmail@cr.yp.to> References: <20010127195756.26554.qmail@cr.yp.to> <20010128041237.15447.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:22 30/01/2001 +0000, D. J. Bernstein wrote: >There are five possible approaches under discussion: > > (1) UTF-8 with fast nameprep. Names in configuration files are good: > KC-normalized, no confusing characters, no uppercase characters. > (Except uppercase ASCII, for compatibility.) > > The keyboard interface has to help users type good names. No > changes are needed in qmail, djbdns, and many other programs. A > few programs with 8-bit bugs, notably Sendmail, need to be fixed. > > Patrik and Keith refuse to acknowledge this approach. I think you mean by "fast" what I mean when I say "early", and by "slow" you mean what I mean when I say "late". I also think you mean by "refuse to acknowledge" what I mean when I say "do not believe that it is workable". And when you say "Patrik and Keith", you mean the people who constituted the rough consensus at the San Jose IETF, and those who share that rough consensus on the list. I continue to not believe that just-send-UTF-8 is workable. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Fri Feb 2 03:09:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04824 for ; Fri, 2 Feb 2001 03:09:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ob0S-000JaR-00 for idn-data@psg.com; Thu, 01 Feb 2001 23:51:44 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14Ob0R-000JaL-00 for idn@ops.ietf.org; Thu, 01 Feb 2001 23:51:43 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 613 for ; Thu, 1 Feb 2001 23:51:41 -0800 Message-ID: <3A7A670C.E2DE1317@ehsco.com> Date: Thu, 01 Feb 2001 23:51:40 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: idn@ops.ietf.org Subject: Re: [idn] Fast nameprep vs. slow nameprep References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Patrik Fltstrm wrote: > I created the confusion by seeing the need that the nameprep is NOT > done in the resolver libraries or in the DNS server, I agree that the resolver is a bad place to do this. It seems fairly obvious from a cursory analysis that the best place to do this is in the application layer in front of the resolver (before gethostbyname). Any app which calls the API should have done the necessary work before the API is called. This also applies to DNS-specific apps like nsupdate and dig and the rest. However, I think that the use of ACE -- more specifically, the use of a mechanism which favors backwards compatibility -- pretty much dictates that the resolver has to do the work. In addition, I think it is pretty clear that servers will have to do the work against incoming queries as well. I don't see any way around it. Since there are no new RRs, classes or EDNS structures to make legacy applications and resolvers barf on new-style labels, we can pretty much expect that there will always be some legacy applications that will try to feed unformatted, un-prepped raw IDNs through a legacy resolver, and that some of those resolvers will simply treat the data as raw eight-bit data. The fact is that somebody somewhere is going to click on an IDN URL and expect that Netscape 3 is going to work with the Windows 3.0 resolver. It is inescapable. The real problem is that it will also happen with users of Netscape 6 and Windows 2000, MacOS X, and every other current day operating system. In those cases, the un-prepped data will still enter the DNS namespace, having never been formatted. The DNS servers will have to examine and reject unformatted data. New DNS resolvers will end up being the first line of defense to this problem should it emerge. The need for this will be measured by the amount of effort required to communicate failure back to the client. If it is a simple match->fail sequence that uses the same NXDOMAIN errors we already have (and if it doesn't happen a lot) then it won't be much of a problem. Conversely, if enough users yell about not being able to resolve IDNs (even though it is because their patch-current apps/resolvers aren't doing the work) then there might be sufficient non-technical motivation to introduce an intermediary solution somewhere within the DNS infrastructure, either at the server or with patched resolvers. In short: legacy apps+legacy resolvers=server labor legacy apps+patched resolver=resolver labor new apps=app labor I'd say spec for the last scenario but implementaions need to be prepared for all three. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Feb 2 07:45:01 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06600 for ; Fri, 2 Feb 2001 07:44:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OfG0-000N8t-00 for idn-data@psg.com; Fri, 02 Feb 2001 04:24:04 -0800 Received: from mail-gw.im.se ([193.14.22.222] helo=mail-gw.imt.im.se) by psg.com with esmtp (Exim 3.16 #1) id 14OfFz-000N8l-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 04:24:03 -0800 Received: from MSXSTH1.im.se (msxsth1.im.se [193.14.16.108]) by mail-gw.imt.im.se (8.11.0/8.11.0) with ESMTP id f12CHiD44932 for ; Fri, 2 Feb 2001 13:17:44 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Feb 2001 13:22:55 +0100 Message-ID: From: Karlsson Kent - keka To: idn@ops.ietf.org Subject: RE: [idn] Fast nameprep vs. slow nameprep Date: Fri, 2 Feb 2001 13:20:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06600 > -----Original Message----- > From: D. J. Bernstein [mailto:djb@cr.yp.to] ... > Karlsson Kent - keka writes: > > Do you expect system > > providers to make a special "IDN mode" for the keyboards? > > It seems that no effort is necessary for European locales: > the existing > keyboard interfaces already produce KC-normalized strings. No, they don't. I can easily enter a (a diearesis) or a (acute accent) on the keyboard, neither of which is in KC. Almost(!) all the letters are likely to already be in KC, but on this keyboard I can generate (micro sign) easily, and (micro sign) is not in KC. Further, "nameprepping" as it is currently specified maps all uppercase to lowercase (nearly; it specifies an extended form of "case *folding*" as per UTR 21, rather than map to lowercase). No keyboard should do that. > (I have no idea why you're worried about soft hyphens. Why > would a user > type a soft hyphen inside a domain name? The keyboard > interface doesn't > have to remove them; they simply won't work.) Current "nameprep" table says: 00AD; ; SOFT HYPHEN; Map out and there may well be a soft hyphen (or zero width space) in a URL to make it linebreak in a not too bad way when a visible copy printed (or when printing/dispaying the source). Soft hyphens can (already for some; more in the future) easily be generated from the keyboard. > In Japan, on the other hand, we've heard that users already have to > change keyboard modes to type domain names. Otherwise they don't even > get the right dot! There are two issues here: 1. There is still no special mode that generates "nameprepped" strings already from the keyboard, not even strings that are guaranteed to be KC. 2. As I said in my previous e-mail, the entier domain name (IDN) should be "nameprepped" before parsing on "." do get name parts. KC will map fullwidth full stop to full stop, and "nameprep" may (if so decided) further map ideographic full stop to full stop; and that before parsing into name parts (for ACEing or whatever). It is not reasonable to require keyboard mode changes (by the user) for each "." typed in an IDN. It is even more unreasonable to require new keyboard modes (from systems providers) that generate "nameprepped" strings. > > If you paste in text, > > Good UTF-8 domain names will be preserved by copy-and-paste. > There's no need for further nameprep. ??? If I paste "re" is should sure still be "re" that is pasted in. The "nameprepped" version is different: "re"; and *pasting* should not do any such change. > > > Can please the keyboard interfaces be left out of this discussion. > > It's far out of scope for the IDN WG. > > Wrong. The whole point of IDNs is to let users read and write > non-ASCII > characters in domain names. The entire path from keyboard to > computer to > screen---as the charter says, ``the use of such names by humans''---is > within the scope of the IDN WG. I did participate in producing the latest Swedish keyboard standard (soon to be published). It does not specify any "nameprepping", or KC mapping, nor are there any plans of ever introducing such things even in a special keyboard mode. Not that such modes are prevented, but nobody will expect any such mode, and "Svensson" (Joe User...) would never use it even in the unlikely event that some system provider created such a mode and shipped it with the system. The IDN working group must *consider* keyboard input, sure. However, it should not dream of *changing* the way keyboards work; such things are definitely out of scope for *this* WG. Kind regards /kent k From owner-idn@ops.ietf.org Fri Feb 2 07:52:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06654 for ; Fri, 2 Feb 2001 07:52:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OfFh-000N8b-00 for idn-data@psg.com; Fri, 02 Feb 2001 04:23:45 -0800 Received: from mail-gw.im.se ([193.14.22.222] helo=mail-gw.imt.im.se) by psg.com with esmtp (Exim 3.16 #1) id 14OfFf-000N8U-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 04:23:44 -0800 Received: from MSXSTH1.im.se (msxsth1.im.se [193.14.16.108]) by mail-gw.imt.im.se (8.11.0/8.11.0) with ESMTP id f12CHOD42074 for ; Fri, 2 Feb 2001 13:17:24 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Feb 2001 13:22:35 +0100 Message-ID: From: Karlsson Kent - keka To: idn@ops.ietf.org Subject: RE: [idn] Fast nameprep vs. slow nameprep Date: Fri, 2 Feb 2001 13:20:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06654 > -----Original Message----- > From: Patrik Fltstrm [mailto:paf@cisco.com] ... > I created the confusion by seeing the need that the nameprep is NOT > done in the resolver libraries or in the DNS server, i.e. somewhere > between the keyboard and the application layer protocols (out of ^^^^^^^ Ok, if that is a *strict* between. /kent k From owner-idn@ops.ietf.org Fri Feb 2 09:58:39 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10976 for ; Fri, 2 Feb 2001 09:58:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OhQm-000PDM-00 for idn-data@psg.com; Fri, 02 Feb 2001 06:43:20 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14OhQl-000PDG-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 06:43:19 -0800 Message-ID: <003701c08d27$2a66e040$1001a8c0@neteka.com> From: "Edmon" To: "Eric A. Hall" Cc: References: <3A7A670C.E2DE1317@ehsco.com> Subject: Re: [idn] Fast nameprep vs. slow nameprep Date: Fri, 2 Feb 2001 09:48:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree to this comment!: > The need for this will be measured by the amount of effort required to > communicate failure back to the client. If it is a simple match->fail > sequence that uses the same NXDOMAIN errors we already have (and if it > doesn't happen a lot) then it won't be much of a problem. Conversely, if > enough users yell about not being able to resolve IDNs (even though it is > because their patch-current apps/resolvers aren't doing the work) then > there might be sufficient non-technical motivation to introduce an > intermediary solution somewhere within the DNS infrastructure, either at > the server or with patched resolvers. > > In short: > legacy apps+legacy resolvers=server labor > legacy apps+patched resolver=resolver labor > new apps=app labor > > I'd say spec for the last scenario but implementaions need to be prepared > for all three. Thats exactly why we have prepared the known issues paper in our OpenIDN forum. These issues must be dealt with because at the end of the day, its the user who might not know too much about the discussions here that will be using the domain names. Also, if these preparations are not made, IDNs will not pass the business card test. Edmon PS. Though I'd add that I see that there should be a 4th scenario: new apps + new resolvers = full IDN and specs should be based on this scenario with "new apps only" as an intermediate solution. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Feb 2 13:37:22 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21225 for ; Fri, 2 Feb 2001 13:37:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Okeo-0002Pt-00 for idn-data@psg.com; Fri, 02 Feb 2001 10:10:02 -0800 Received: from ibd.ar.com ([63.194.205.75]) by psg.com with esmtp (Exim 3.16 #1) id 14Okem-0002Pf-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 10:10:01 -0800 Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id KAA06403; Fri, 2 Feb 2001 10:09:52 -0800 (PST) Date: Fri, 2 Feb 2001 10:09:52 -0800 (PST) From: Rick H Wesson To: Paul Hoffman / IMC cc: Subject: [idn] =?iso-8859-1?Q?Namprep-02=3A_=DF=2Ecom?= Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Nameprep .com = ss.com It's illegal to register ss.com as a ml domains because its only plain ascii after nameprep. How can anyone register .com or will it be unavailable? thanks, -rick From owner-idn@ops.ietf.org Fri Feb 2 13:45:33 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21622 for ; Fri, 2 Feb 2001 13:45:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Oksg-0002e4-00 for idn-data@psg.com; Fri, 02 Feb 2001 10:24:22 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Oksf-0002dx-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 10:24:21 -0800 Received: (qmail 20943 invoked by uid 1001); 2 Feb 2001 18:10:44 -0000 Date: 2 Feb 2001 18:10:44 -0000 Message-ID: <20010202181044.20756.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Fast nameprep vs. slow nameprep References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Uppercase letters will simply be prohibited by registrars. They won't work in domain names, and users won't type them. Exception: Uppercase ASCII will have to be allowed for compatibility. But we don't have this compatibility constraint outside ASCII. Karlsson Kent - keka writes: > there may well be a soft hyphen (or zero width space) in a URL I don't see why. Do you also expect blinking italics in a URL? Soft hyphens, like uppercase letters, will simply be prohibited. They won't work in domain names, and users won't type them. > Soft hyphens can (already for some; more in the future) easily be > generated from the keyboard. The goal is for users to easily type good (nameprepped) names. Users can also type many other things, such as spaces; so what? That doesn't hurt their ability to type good names. ---Dan From owner-idn@ops.ietf.org Sat Feb 3 00:02:58 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15550 for ; Sat, 3 Feb 2001 00:02:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OuIN-000Cva-00 for idn-data@psg.com; Fri, 02 Feb 2001 20:27:31 -0800 Received: from femail11.sdc1.sfba.home.com ([24.0.95.107]) by psg.com with esmtp (Exim 3.16 #1) id 14OuIM-000CvU-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 20:27:30 -0800 Received: from c1340594a ([65.11.104.12]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010203042729.NKQZ11370.femail11.sdc1.sfba.home.com@c1340594a>; Fri, 2 Feb 2001 20:27:29 -0800 Message-ID: <002101c08d99$cc1e62b0$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "D. J. Bernstein" , References: <20010202181044.20756.qmail@cr.yp.to> Subject: Re: [idn] Fast nameprep vs. slow nameprep Date: Fri, 2 Feb 2001 20:28:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Soft hyphens, like uppercase letters, will simply be prohibited. They > won't work in domain names, and users won't type them. We can't lose sight of the fact that people cut and paste text into the address field in a browser; they don't just type in URLs, especially long ones.. It is not uncommon for word-processing software to insert soft-hyphens into text. The user wouldn't even know that some text happened to contain some when s/he pasted it into the address field. From owner-idn@ops.ietf.org Sat Feb 3 00:43:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16980 for ; Sat, 3 Feb 2001 00:43:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OvAD-000E6B-00 for idn-data@psg.com; Fri, 02 Feb 2001 21:23:09 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14OvAC-000E65-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 21:23:08 -0800 Received: from slip-32-103-42-239.tx.us.prserv.net ("port 1056"@[32.103.42.239]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G8600MKV1M0EJ@a4.jck.com> for idn@ops.ietf.org; Sat, 03 Feb 2001 00:23:07 -0500 (EST) Date: Fri, 02 Feb 2001 22:42:24 -0500 From: John C Klensin Subject: =?ISO-8859-1?Q?Re:_[idn]_Namprep-02:_=DF.com?= In-reply-to: To: Rick H Wesson Cc: idn@ops.ietf.org Message-id: <1901200852.981153744@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.6 (Win32) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA16980 --On Friday, 02 February, 2001 10:09 -0800 Rick H Wesson wrote: > Nameprep .com = ss.com Sorry, this probably flunks the "I see it on a card or screen and don't know what script it is in" test. Abc.com (German script, i.e., Latin-1 subset of 10646) = Abcss.com but ac.com (Greek script and a few others) = ac.com (or maybe acb.com :-) ) and we are in huge trouble if it gets coerced to acss.com. And, to pick on your example for amusement value, .com (Greek) is significantly more likely to occur in nature than .com (German). john From owner-idn@ops.ietf.org Sat Feb 3 02:09:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25158 for ; Sat, 3 Feb 2001 02:09:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OwMh-000FL3-00 for idn-data@psg.com; Fri, 02 Feb 2001 22:40:07 -0800 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14OwMg-000FKx-00 for idn@ops.ietf.org; Fri, 02 Feb 2001 22:40:07 -0800 Received: from DC-DESK.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA20268; Fri, 2 Feb 2001 22:40:02 -0800 Message-Id: <5.1.0.7.2.20010202223200.01cea008@dcrocker.songbird.com> X-Sender: dhc@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 22:35:37 -0800 To: Harald Alvestrand From: Dave Crocker Subject: Re: [idn] Fast nameprep vs. slow nameprep Cc: idn@ops.ietf.org In-Reply-To: <4.3.2.7.2.20010201020945.02f27c08@127.0.0.1> References: <20010130092212.23751.qmail@cr.yp.to> <20010127195756.26554.qmail@cr.yp.to> <20010128041237.15447.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:14 AM 2/1/2001 -0800, Harald Alvestrand wrote: >I continue to not believe that just-send-UTF-8 is workable. It is approximately the 10th anniversary of the beginning of the effort to make Internet mail support "international character-sets". So I suppose it is fitting that we get to be re-introduced to the "just send the raw data" argument that was held so fondly by some. Happily, they did not win the debate then, but it is curious that the lessons from that earlier exercise seems to be unlearned by some. d/ From owner-idn@ops.ietf.org Sat Feb 3 04:27:38 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27832 for ; Sat, 3 Feb 2001 04:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OyXq-000IPa-00 for idn-data@psg.com; Sat, 03 Feb 2001 00:59:46 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14OyXp-000IPU-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 00:59:45 -0800 Received: (qmail 19342 invoked by uid 1001); 3 Feb 2001 09:00:05 -0000 Date: 3 Feb 2001 09:00:05 -0000 Message-ID: <20010203090005.2784.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: [idn] I don't want 8-bit failures in 2011 References: <20010130092212.23751.qmail@cr.yp.to> <20010127195756.26554.qmail@cr.yp.to> <20010128041237.15447.qmail@cr.yp.to> <4.3.2.7.2.20010201020945.02f27c08@127.0.0.1> <5.1.0.7.2.20010202223200.01cea008@dcrocker.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Dave Crocker writes: > It is approximately the 10th anniversary of the beginning of the effort to > make Internet mail support "international character-sets". It has been nearly twenty years since people realized how stupid it was to mangle 8-bit mail. But there is still no IETF specification saying that it's bad for Sendmail to destroy bytes 128 through 159 in the header of a message. In fact, in the world according to Crocker, it's perfectly acceptable for a new MTA to prohibit 8-bit text in the _body_ of a message! Of course, such an MTA will fail to interoperate with hundreds of thousands of machines running qmail, Exim, Sendmail with the 8 flag, etc. But Crocker says he's right and they're all wrong. What I find most amazing is that Crocker keeps claiming success. His own MTA (MMDF) has withered and practically died, along with all its commercial spinoffs; his rules are widely disobeyed by popular MTAs, as demanded by the users and system administrators; and he still doesn't get the message. He is out of touch with reality. Back to 8-bit headers: We wouldn't be faced with Sendmail's 8-bit bugs today if the IETF had required 8-bit-clean software ten years ago. But the IESG followed Crocker's approach. Now he wants us to continue down the same path, extending this disaster for another ten years. And _he_ says that _I_ am not learning the lessons of history! ---Dan From owner-idn@ops.ietf.org Sat Feb 3 05:18:42 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28673 for ; Sat, 3 Feb 2001 05:18:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OzVW-000JH5-00 for idn-data@psg.com; Sat, 03 Feb 2001 02:01:26 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14OzVV-000JGz-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 02:01:25 -0800 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f13A1L414623; Sat, 3 Feb 2001 11:01:21 +0100 (MET) Message-Id: <200102031001.f13A1L414623@malmo.trab.se> Date: Sat, 3 Feb 2001 11:00:16 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] Fast nameprep vs. slow nameprep To: djb@cr.yp.to, idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0+O2d+j9rjHoCXZNdza8fw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Dan J writes: >Uppercase letters will simply be prohibited by registrars. They won't >work in domain names, and users won't type them. > Why should upper case letters be prohibited? I allow it in my domain today and see no reason to disallow it. It enhances readability! Forcing names into lower case does not make them better. It makes them more difficult to read, more difficult to enter and breaks current sematics on name matching and peoples expectations on how things work. Using mixed case in names is extremely popular today. Of course users will type them. And will be very confused if they do not work. Different case will occur by mistake. Case used in a domain names should not matter when comparing names. Case should be preserved in DNS (it says so in the RFCs, and it does not say just ASCII). A solution for IDNs in DNS must allow mixed case (even for non-ASCII). Dan From owner-idn@ops.ietf.org Sat Feb 3 05:23:18 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28693 for ; Sat, 3 Feb 2001 05:23:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OzZU-000JKU-00 for idn-data@psg.com; Sat, 03 Feb 2001 02:05:32 -0800 Received: from epa.secret.org ([206.220.140.150] ident=0) by psg.com with esmtp (Exim 3.16 #1) id 14OzZT-000JKN-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 02:05:31 -0800 Received: from localhost (lucid@localhost) by epa.secret.org (8.9.3/8.9.1) with ESMTP id FAA37052 for ; Sat, 3 Feb 2001 05:05:29 -0500 (EST) Date: Sat, 3 Feb 2001 05:05:29 -0500 (EST) From: lucid@epa.secret.org To: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 In-Reply-To: <20010203090005.2784.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On 3 Feb 2001, D. J. Bernstein wrote: > Dave Crocker writes: > > It is approximately the 10th anniversary of the beginning of the effort to > > make Internet mail support "international character-sets". > It has been nearly twenty years since people realized how stupid it was > to mangle 8-bit mail. But there is still no IETF specification saying > that it's bad for Sendmail to destroy bytes 128 through 159 in the > header of a message. Ok, given that: IPv6 will requires changes at all of the same layers as IDN from application to network http://127.0.0.1/ http://127.1/ http://0:0:0:0:0:0:0:1/ http://::1/ I know of no production IPv6 networks http://www.ipv6.org/v6-www.html Production use of IPv6 will take another 5-20 years Ask your ISP if you can connect to them via IPv6 I doubt they even have IPv6 address space. Because of this I propose the following idea: IDN for IPv6 should be implemented in a raw unicode character set aka just do 8-bit. Until then *ACE or some other solution can be designed and implemented. -Bill From owner-idn@ops.ietf.org Sat Feb 3 05:27:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28891 for ; Sat, 3 Feb 2001 05:27:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OzI0-000J3O-00 for idn-data@psg.com; Sat, 03 Feb 2001 01:47:28 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14OzHz-000J3I-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 01:47:27 -0800 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f139lO412350; Sat, 3 Feb 2001 10:47:24 +0100 (MET) Message-Id: <200102030947.f139lO412350@malmo.trab.se> Date: Sat, 3 Feb 2001 10:46:19 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] Interactions between short-term and long-term To: idn@ops.ietf.org, djb@cr.yp.to MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UJULVY2gYda5yR7BY9ySUg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >> A domain name must be matched case insensitivly, but a lot of programs >> (Unix have a lot of them) do not. > >Details, please. Which programs are you talking about? Many programs handling /etc/hosts. I know for example that nfs exports fail if case is wrong. Many programs checking access based on host names (the configuratio files says for example: allow Openx.com, DNS returns for IP address OpenX.com). Dan From owner-idn@ops.ietf.org Sat Feb 3 05:40:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29126 for ; Sat, 3 Feb 2001 05:40:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14OznK-000JZU-00 for idn-data@psg.com; Sat, 03 Feb 2001 02:19:50 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14OznJ-000JZO-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 02:19:49 -0800 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f13AJk417244 for ; Sat, 3 Feb 2001 11:19:46 +0100 (MET) Message-Id: <200102031019.f13AJk417244@malmo.trab.se> Date: Sat, 3 Feb 2001 11:18:41 +0100 (MET) From: Dan Reply-To: Dan Subject: [idn] The layers and character handling in DNS To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EkjEsHHLI6RSHbIh2rAlDw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk There have been several comments on where to do nameprep and use of different character sets. If I look at how I would like things to work, if could be like this: user enters name in application using LOCAL character set. -> application calls routnes like: gethostbyname -> gethostbyname converts form LOCAL character set to normalised (not namepreped) UTF-8 (or other format). it may reject the query if the name contains forbidden characters. and sends the query to DNS server. -> DNS server receives the request, takes the UTF-8, compares it using the namepreped form of the name to the namepreped form of the names in the database. If it is a caching server if can do the matching by binary matching. -> The DNS server sends the response back to the client using normalised (original form, not namepreped) UTF-8. -> gethostbyname (or other routine) returns the answer with names converted into LOCAL character set. -> application presents answer using LOCAL chaarcter set to the user. This way you get: - applications can use local character set just like now. They do not have to know about format used for interoperability. - conversion form local to protocol character set is done in resolver APIs. - the complex name matching is done in authorative DNS servers. Applications needing to compare to names themselves have to know how to do name matching using nameprep (this could be implemented in resolver libraries giving all applications a common API for doing this). All the applications that do not need to compare names (there are a lot) need not implement more the simple normalisation of UTF-8 (which need to be done in all applications using UCS for interoperability, if they want it to work). If you want to support IDNs in non-upgraded DNS servers you could require DNS queries to send the query name namepreped, but the answers must be in original normalised form. This will unfortunately require nameprep in all applications (or all resolver code) which is not needed otherwise. Dan From owner-idn@ops.ietf.org Sat Feb 3 09:33:05 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03412 for ; Sat, 3 Feb 2001 09:33:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14P3Im-000MLO-00 for idn-data@psg.com; Sat, 03 Feb 2001 06:04:32 -0800 Received: from [166.60.6.38] (helo=NOD.RESTON.MCI.NET) by psg.com with esmtp (Exim 3.16 #1) id 14P3Il-000MLI-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 06:04:32 -0800 Received: from vint.mci.net ([166.60.14.44]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with ESMTPA id <01JZO26WAUSC9VUJRB@shoe.reston.mci.net> for idn@ops.ietf.org; Sat, 03 Feb 2001 09:04:30 -0500 (EST) Date: Sat, 03 Feb 2001 09:04:02 -0500 From: vint cerf Subject: Re: [idn] I don't want 8-bit failures in 2011 In-reply-to: X-Sender: vcerf@shoe.reston.mci.net To: lucid@epa.secret.org, idn@ops.ietf.org Cc: gmiller@mci.net Message-id: <5.0.2.1.2.20010203090321.01f626c0@shoe.reston.mci.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <20010203090005.2784.qmail@cr.yp.to> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT worldcom is happy to provide IPv6 production service on its vBNS+ network. We do have IPv6 address allocations. vint cerf At 05:05 AM 2/3/2001 -0500, lucid@epa.secret.org wrote: >I know of no production IPv6 networks > http://www.ipv6.org/v6-www.html > > Production use of IPv6 will take another 5-20 years > Ask your ISP if you can connect to them via IPv6 > I doubt they even have IPv6 address space. From owner-idn@ops.ietf.org Sat Feb 3 15:58:26 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11501 for ; Sat, 3 Feb 2001 15:58:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14P99s-0002WP-00 for idn-data@psg.com; Sat, 03 Feb 2001 12:19:44 -0800 Received: from ibd.ar.com ([63.194.205.75]) by psg.com with esmtp (Exim 3.16 #1) id 14P99r-0002WI-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 12:19:43 -0800 Received: from loki (wessorh@loki.ar.com [10.10.10.88]) by ibd.ar.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id MAA08236; Sat, 3 Feb 2001 12:19:40 -0800 (PST) Date: Sat, 3 Feb 2001 12:19:39 -0800 (PST) From: Rick H Wesson To: "D. J. Bernstein" cc: Subject: Re: [idn] I don't want 8-bit failures in 2011 In-Reply-To: <20010203090005.2784.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Dan, your conversation about 8bit SMTP is completely out of scope for this list/wg. please, keep on topic and focused on idn issues. -rick On 3 Feb 2001, D. J. Bernstein wrote: > Dave Crocker writes: > > It is approximately the 10th anniversary of the beginning of the effort to > > make Internet mail support "international character-sets". > > It has been nearly twenty years since people realized how stupid it was > to mangle 8-bit mail. But there is still no IETF specification saying > that it's bad for Sendmail to destroy bytes 128 through 159 in the > header of a message. > > In fact, in the world according to Crocker, it's perfectly acceptable > for a new MTA to prohibit 8-bit text in the _body_ of a message! > > Of course, such an MTA will fail to interoperate with hundreds of > thousands of machines running qmail, Exim, Sendmail with the 8 flag, > etc. But Crocker says he's right and they're all wrong. > > What I find most amazing is that Crocker keeps claiming success. His > own MTA (MMDF) has withered and practically died, along with all its > commercial spinoffs; his rules are widely disobeyed by popular MTAs, as > demanded by the users and system administrators; and he still doesn't > get the message. He is out of touch with reality. > > Back to 8-bit headers: We wouldn't be faced with Sendmail's 8-bit bugs > today if the IETF had required 8-bit-clean software ten years ago. But > the IESG followed Crocker's approach. Now he wants us to continue down > the same path, extending this disaster for another ten years. And _he_ > says that _I_ am not learning the lessons of history! > > ---Dan > From owner-idn@ops.ietf.org Sat Feb 3 17:12:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12926 for ; Sat, 3 Feb 2001 17:12:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PACI-00043s-00 for idn-data@psg.com; Sat, 03 Feb 2001 13:26:18 -0800 Received: from femail2.sdc1.sfba.home.com ([24.0.95.82]) by psg.com with esmtp (Exim 3.16 #1) id 14PACI-00043k-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 13:26:18 -0800 Received: from c1340594a ([65.11.104.12]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010203212549.BFOC27594.femail2.sdc1.sfba.home.com@c1340594a> for ; Sat, 3 Feb 2001 13:25:49 -0800 Message-ID: <003401c08e28$1c4a47c0$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: References: <200102031019.f13AJk417244@malmo.trab.se> Subject: [idn] NamePrep/ Date: Sat, 3 Feb 2001 13:27:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I updated my online NamePrep/LACE converter to the latest version. It is in http://www.macchiato.com/unicode/convert.html Click on the "NP" checkbox to turn on NamePrep. It will fold, normalize, and check for illegal characters. I'd only recommend IE5.5 for trying it. On Windows, NN4.76 works but has a wierd layout. NN6 is broken (but that's not new). Mark From owner-idn@ops.ietf.org Sun Feb 4 01:21:20 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13886 for ; Sun, 4 Feb 2001 01:21:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PI7x-000CHd-00 for idn-data@psg.com; Sat, 03 Feb 2001 21:54:21 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14PI7w-000CHX-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 21:54:20 -0800 Received: (qmail 12894 invoked by uid 1001); 4 Feb 2001 05:54:34 -0000 Date: 4 Feb 2001 05:54:34 -0000 Message-ID: <20010204055434.11229.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 References: <20010203090005.2784.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Rick H Wesson writes: > your conversation about 8bit SMTP is completely out of scope for this > list/wg. If we have UTF-8 IDNs, then they will be transmitted in mail messages, both in the header (e.g., From lines) and in the body (e.g., responses from automated mailing-list managers). Many clients send 8-bit text as is, labelled as 8-bit MIME or not at all. Many MTAs do just-send-8. It is clearly within the scope of IDN to consider the interoperability issues here---as illustrated by the Sendmail entry in my list of upgrades necessary for UTF-8. It is also sensible for us to review the Quoted-Printable disaster and evaluate its similarity to ACE. ---Dan From owner-idn@ops.ietf.org Sun Feb 4 02:27:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25538 for ; Sun, 4 Feb 2001 02:27:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PJKJ-000DNQ-00 for idn-data@psg.com; Sat, 03 Feb 2001 23:11:11 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14PJKI-000DNK-00 for idn@ops.ietf.org; Sat, 03 Feb 2001 23:11:10 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id CAA21503; Sun, 4 Feb 2001 02:11:01 -0500 (EST) Message-Id: <200102040711.CAA21503@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 In-reply-to: Your message of "04 Feb 2001 05:54:34 GMT." <20010204055434.11229.qmail@cr.yp.to> Date: Sun, 04 Feb 2001 02:11:01 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > your conversation about 8bit SMTP is completely out of scope for this > > list/wg. > > If we have UTF-8 IDNs, then they will be transmitted in mail messages, > both in the header (e.g., From lines) and in the body (e.g., responses > from automated mailing-list managers). Many clients send 8-bit text as > is, labelled as 8-bit MIME or not at all. Many MTAs do just-send-8. yes, some leakage will occur. and many UAs and MTAs will mung these in such a way that it becomes impossible to reply to such messages. > It is clearly within the scope of IDN to consider the interoperability > issues here---as illustrated by the Sendmail entry in my list of > upgrades necessary for UTF-8. of course. after all, it's this very set of interoperability isssues that makes ACE solutions so compelling. > It is also sensible for us to review the > Quoted-Printable disaster and evaluate its similarity to ACE. I suspect you're confusing quoted-printable with RFC 2047 and its predecessors. but if one is going to "review" the experience from that decision, (which I agree is relevant, and we've already done some of that) then one also needs to compare it with the experience of just-send-8. Keith From owner-idn@ops.ietf.org Sun Feb 4 10:56:25 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09330 for ; Sun, 4 Feb 2001 10:56:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PR4v-000L7T-00 for idn-data@psg.com; Sun, 04 Feb 2001 07:27:49 -0800 Received: from dokka.maxware.no ([195.139.236.69]) by psg.com with esmtp (Exim 3.16 #1) id 14PR4u-000L7N-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 07:27:48 -0800 Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id QAA11608; Sun, 4 Feb 2001 16:27:36 +0100 Message-Id: <4.3.2.7.2.20010204052001.0b547b58@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Feb 2001 06:00:56 -0800 To: Rick H Wesson , Paul Hoffman / IMC From: Harald Alvestrand Subject: =?iso-8859-1?Q?Re:_[idn]_Namprep-02:_=DF.com?= Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09330 At 10:09 02/02/2001 -0800, Rick H Wesson wrote: >Nameprep .com = ss.com > >It's illegal to register ss.com as a ml domains because its only >plain ascii after nameprep. "this" can mean 2 things, depending on how I interpret what I see..... Either this is Unicode x00DF: 00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;German;;; Or this is Unicode x032B: 03B2;GREEK SMALL LETTER BETA;Ll;0;L;;;;;N;;;0392;;0392 Both of these are lower case letters (Ll). None have decompositions, canonical or otherwise. The relevant text from nameprep-02 that produced the "sharp is ss" is: >3.2 Additional folding mappings > >There are some characters that do not have mappings in [UTR21] but still >need processing. These characters include a few Greek characters and >many symbols that contain Latin characters. The list of characters to >add to the mapping table were determined by the following algorithm: > >b = Normalize(Fold(a)); >c = Normalize(Fold(b)); >if c is not the same as b, add a mapping for "a to c". > >Because Normalize(Fold(c)) always equals c, the table is stable from >that point on. (Aside: I don't understand how this produced the entry "00DF; 0073 0073; Case map" in the tables, since there is no string that folds to 0x00DF. It's "logical" in some sense, since 00DF mapped to UPPERCASE is 0073 0073 according to the Special Casing datafile of Unicode. But "Fold" does not map to uppercase, it maps to lowercase. And then 00DF maps onto itself. Specification seems incomplete.) >How can anyone register .com or will it be unavailable? According to the current nameprep doc, it cannot be entered into a zonefile, so it will be "mechanically unavailable". The Greek Beta will be available. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Sun Feb 4 12:54:18 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10189 for ; Sun, 4 Feb 2001 12:54:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PSyX-000O2d-00 for idn-data@psg.com; Sun, 04 Feb 2001 09:29:21 -0800 Received: from femail11.sdc1.sfba.home.com ([24.0.95.107]) by psg.com with esmtp (Exim 3.16 #1) id 14PSyW-000O2X-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 09:29:20 -0800 Received: from c1340594a ([65.11.104.12]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010204172851.RMDN11370.femail11.sdc1.sfba.home.com@c1340594a>; Sun, 4 Feb 2001 09:28:51 -0800 Message-ID: <001d01c08ed0$1ec20f30$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Rick H Wesson" , "Paul Hoffman / IMC" , "Harald Alvestrand" Cc: References: <4.3.2.7.2.20010204052001.0b547b58@127.0.0.1> Subject: [idn] =?iso-8859-1?Q?Re:_=5Bidn=5D_Namprep-02:_=DF.com?= Date: Sun, 4 Feb 2001 09:30:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit The source documents to look at are: http://www.unicode.org/Public/3.1-Update/CaseFolding-3d4.beta.txt http://www.unicode.org/unicode/reports/tr21/ There it explains the treatment of es-zed. Mark ----- Original Message ----- From: "Harald Alvestrand" To: "Rick H Wesson" ; "Paul Hoffman / IMC" Cc: Sent: Sunday, February 04, 2001 06:00 Subject: Re: [idn] Namprep-02: .com At 10:09 02/02/2001 -0800, Rick H Wesson wrote: >Nameprep .com = ss.com > >It's illegal to register ss.com as a ml domains because its only >plain ascii after nameprep. "this" can mean 2 things, depending on how I interpret what I see..... Either this is Unicode x00DF: 00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;German;;; Or this is Unicode x032B: 03B2;GREEK SMALL LETTER BETA;Ll;0;L;;;;;N;;;0392;;0392 Both of these are lower case letters (Ll). None have decompositions, canonical or otherwise. The relevant text from nameprep-02 that produced the "sharp is ss" is: >3.2 Additional folding mappings > >There are some characters that do not have mappings in [UTR21] but still >need processing. These characters include a few Greek characters and >many symbols that contain Latin characters. The list of characters to >add to the mapping table were determined by the following algorithm: > >b = Normalize(Fold(a)); >c = Normalize(Fold(b)); >if c is not the same as b, add a mapping for "a to c". > >Because Normalize(Fold(c)) always equals c, the table is stable from >that point on. (Aside: I don't understand how this produced the entry "00DF; 0073 0073; Case map" in the tables, since there is no string that folds to 0x00DF. It's "logical" in some sense, since 00DF mapped to UPPERCASE is 0073 0073 according to the Special Casing datafile of Unicode. But "Fold" does not map to uppercase, it maps to lowercase. And then 00DF maps onto itself. Specification seems incomplete.) >How can anyone register .com or will it be unavailable? According to the current nameprep doc, it cannot be entered into a zonefile, so it will be "mechanically unavailable". The Greek Beta will be available. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Sun Feb 4 14:48:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11098 for ; Sun, 4 Feb 2001 14:48:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PUwF-0000S3-00 for idn-data@psg.com; Sun, 04 Feb 2001 11:35:07 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14PUwE-0000Rx-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 11:35:07 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 727 for ; Sun, 4 Feb 2001 11:35:03 -0800 Message-ID: <3A7DAEE7.7581A12C@ehsco.com> Date: Sun, 04 Feb 2001 11:35:03 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 References: <200102040711.CAA21503@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > It is clearly within the scope of IDN to consider the > > interoperability issues here---as illustrated by the Sendmail > > entry in my list of upgrades necessary for UTF-8. > > of course. after all, it's this very set of interoperability isssues > that makes ACE solutions so compelling. I'm not taking sides in the debate but I would like to point out that by not making forward compatibility an explicit extension, the use of ACE and a legacy-friendly message practically guarantees that problems with mixed encodings will go up. Legacy apps and resolvers that encounter UTF8 names in documents and links will use the UTF8 domain names even though they should not do so. As IDNs are promulgated, this problem will get worse, not better. Just as a statement of fact, it really would be *easier* (not better, but easier) to embrace UTF8 directly since there is nothing that prevents UTF8 from being used in queries today except the hostname limitations. Just as a simple measurement of where implementations are today, UTF8 mostly works while ACE does not work at all. This means that we are *closer* to UTF8 everywhere than we are to ACE everywhere. This is a simple statement of fact without examining the technical merits of the solutions, I am not taking sides in the debate but instead am trying to make simple observations plain. In short, ACE actually makes it easier for bad things to happen, since it does not mandate new behavior. In the end, going with ACE translates directly into more apps trying to use UTF8, not less. This is not a compelling (in a good way) feature. FWIW, these same problems exist if just-send-UTF8 is used. Both ACE and just-send-UTF8 suffer the same inheritance problems with legacy apps and resolvers. For example, UTF8-encoded names don't necessarily signify that the name has been nameprep'd, so it is just as easy for a UTF8 lookup to send bad data as it is for an ACE system. As such, they both have tremendous problems. [Personally, if there were a vote tomorrow I would go for the EDNS approach, for a variety of reasons, but primarily because it requires explicit forward compatibility and solves a bunch of other problems along the way.] -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Feb 4 20:46:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13765 for ; Sun, 4 Feb 2001 20:46:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PaLd-0006hN-00 for idn-data@psg.com; Sun, 04 Feb 2001 17:21:41 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14PaLW-0006hC-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 17:21:39 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA28557; Sun, 4 Feb 2001 20:21:21 -0500 (EST) Message-Id: <200102050121.UAA28557@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 In-reply-to: Your message of "Sun, 04 Feb 2001 11:35:03 PST." <3A7DAEE7.7581A12C@ehsco.com> Date: Sun, 04 Feb 2001 20:21:21 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > > It is clearly within the scope of IDN to consider the > > > interoperability issues here---as illustrated by the Sendmail > > > entry in my list of upgrades necessary for UTF-8. > > > > of course. after all, it's this very set of interoperability isssues > > that makes ACE solutions so compelling. > > I'm not taking sides in the debate but I would like to point out that by > not making forward compatibility an explicit extension, the use of ACE and > a legacy-friendly message practically guarantees that problems with mixed > encodings will go up. Legacy apps and resolvers that encounter UTF8 names > in documents and links will use the UTF8 domain names even though they > should not do so. As IDNs are promulgated, this problem will get worse, > not better. I am not sure I agree with the last sentence, but it's clear to me that even if we adopt ACE (a) leakage of non-ACEd UTF-8 IDNs will occur (as well as leakage of IDNs in other charsets), and (b) it's desirable for applications protocols to define what should happen when they do encounter such names. And while I could argue that applications that detect such names should signal these as error conditions (on the grounds that the earlier in the signal path such errors are detected, the more likely they are to be corrected), realistically I suspect that there will be tremendous pressure on most applications to "fix things up later". At least UTF-8 stings of more than a few characters can generally be detected even without a label, so there's less likely to be a misinterpretation of a UTF-8 IDN than of an IDN in some other charset without a label. So for example in email, even though ACE might be required in SMTP and in message headers, we'll see UTF-8 in both places, and we'll be better off if MTAs and UAs that do try to handle these things do so in a uniform way. > Just as a statement of fact, it really would be *easier* (not better, but > easier) to embrace UTF8 directly since there is nothing that prevents UTF8 > from being used in queries today except the hostname limitations. this would be true only if a) existing DNS servers could reliably compare UTF8 IDNs without nameprep b) DNS queries were the major area of concern > Just as > a simple measurement of where implementations are today, UTF8 mostly works > while ACE does not work at all. for DNS servers, perhaps. for applications that transmit DNS names as protocol elements, the opposite is closer to the truth. > In short, ACE actually makes it easier for bad things to happen, since it > does not mandate new behavior. on the contrary, ACE does mandate new behavior in any application that needs to do more with an IDN than query its DNS records, pass it to another application, or compare one IDN with another. any application that inputs or displays IDNs will have to behave differently in order to support ACE; but any application that inputs or compares IDNs would have to behave differently to support UTF-8 IDNs) > In the end, going with ACE translates > directly into more apps trying to use UTF8, not less. This is not a > compelling (in a good way) feature. any IDN scheme (whether ACE or not) will cause more leakage of non-ASCII names into applications that are expecting ASCII names. the very fact that we are creating a standard mechanism to do this, combined with the growng number of non-English speakers on the net, ensures this. Keith From owner-idn@ops.ietf.org Sun Feb 4 22:22:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15505 for ; Sun, 4 Feb 2001 22:22:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Pbol-0008Jw-00 for idn-data@psg.com; Sun, 04 Feb 2001 18:55:51 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14Pbok-0008Jq-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 18:55:50 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 66 for ; Sun, 4 Feb 2001 18:55:48 -0800 Message-ID: <3A7E1633.44790F4@ehsco.com> Date: Sun, 04 Feb 2001 18:55:47 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 References: <200102050121.UAA28557@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith, let me redefine the point: One of the great things about the EDNS proposal is that it provides long labels and names. Since this would be a favorite feature of a lot of the non-English locales, it would be widely-adopted. In turn, its very usage would break legacy apps and resolvers that tried to resolve the long labels/names. That keeps UTF8 names out of the legacy lookup path, while also encouraging upgrades to applications, resolvers and servers that support the necessary EDNS extensions. None of the other proposals have the ability to preserve legacy lookups while simultaneously promoting the adoption of the new service. There are numerous other benefits -- any application that does the EDNS formatted lookup is (very) likely to have done nameprep on the name in the application beforehand, it uses the same technology as A6 RRs so it can ride the same adoption wave, and many others -- but the key point is that the EDNS approach lets the domain names (and just the names) break the apps and resolvers. Very little additional effort is required except for the labels/names that do not exceed 63/255 bytes. That scenario is very likely yes but it will only happen in a percentage of the cases instead of all of them. > So for example in email, even though ACE might be required in SMTP > and in message headers, we'll see UTF-8 in both places, and we'll > be better off if MTAs and UAs that do try to handle these things > do so in a uniform way. In a common scenario, the relay would write out the HELO name, the IP address, and the PTR data. Setting aside HELO names for a moment, if the PTR data included EDNS data which the relay or its resolver did not understand, then the relay should leave the PTR string empty. If the app is able to extract the EDNS name then there are ugly but feasible encoding methods to keep it from destroying downstream mailers. As for HELO names, there are also some potential problems there, but they don't look like show stoppers (I don't know of any restrictions on length so encoding appears to be the only issue). What this all means is that mail servers aren't broken during a transition period, so no problem with EDNS-encoded names (regardless of the length issues). (Yes I know that some anal sites will break if they can't match HELO with PTR but that is an operational concern which is not covered by protocol). As for outbound mail, there might be problems if MX RRs mix legacy and modern names. Probably not if the netadmins design their forwarding through multi-homed and multi-named relays, and maybe no problems at all if the mailer can't read the complete list anyway. I mean, if the mailer only sees MX 100 on an ASCII name and never sees MX 50 with an IDN, then SMTP will still work if the mailer only sends to 100. It will break in situations where intermediary relays aren't capable of handling delivery to downstreams which have IDNs but that again is an operational issue which can be overcome. Worth exploration and testing but I don't see any problems that are insurmountable. > > a simple measurement of where implementations are today, UTF8 mostly > > works while ACE does not work at all. > > for DNS servers, perhaps. for applications that transmit DNS names as > protocol elements, the opposite is closer to the truth. I'm not arguing for or against ACE or just-use-UTF8. The point of the response was to point out that ACE and just-use-UTF8 both introduce major issues with backwards compatibility. If we really want to avoid the problems of bad names in legacy lookups then they should both be avoided. Yes I also realize it's too late for this argument and that ACE is the interim solution of choice. My bad for showing up late. Still the opinion is valid. > on the contrary, ACE does mandate new behavior in any application that > needs to do more with an IDN than query its DNS records, pass it to > another application, or compare one IDN with another. None of the simple stuff above is reliable with ACE or just-use-UTF8 using legacy apps or resolvers. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Feb 4 22:40:42 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16547 for ; Sun, 4 Feb 2001 22:40:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PcJh-0008qx-00 for idn-data@psg.com; Sun, 04 Feb 2001 19:27:49 -0800 Received: from p5.usnyc1.stsn.com ([199.106.216.5] helo=nychoteldns01.stsn.com) by psg.com with esmtp (Exim 3.16 #1) id 14PcJg-0008q6-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 19:27:48 -0800 Received: from jamessonyvaio ([10.0.208.56]) by nychoteldns01.stsn.com (8.11.0/8.11.0) with SMTP id f153SEn23795; Sun, 4 Feb 2001 22:28:21 -0500 Message-ID: <08d901c08f23$4f4f0560$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: "Eric A. Hall" Cc: References: <200102050121.UAA28557@astro.cs.utk.edu> <3A7E1633.44790F4@ehsco.com> Subject: Re: [idn] I don't want 8-bit failures in 2011 Date: Mon, 5 Feb 2001 11:25:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, This pros and cons discussion have been done before and been considered by the Protocol Design Team. Check out their reports on http://www.i-d-n.net/ietf49/idn-sandiego-protocol-design-term-report.ppt While you are there http://www.i-d-n.net/, you may also want to read a few I-Ds, including draft-idn-idne-01.txt, on how to use EDNS for IDN but more importantly, draft-klensin-dns-role-00.txt which discuss why above may not be right solution either. And for a really long term solution (which may be totally out of the scope of this WG) due to the radical approach proposed, draft-klensin-dnsclass0e-00.txt. :-) -James Seng ----- Original Message ----- From: "Eric A. Hall" Cc: Sent: Monday, February 05, 2001 10:55 AM Subject: Re: [idn] I don't want 8-bit failures in 2011 > > Keith, let me redefine the point: > > One of the great things about the EDNS proposal is that it provides long > labels and names. Since this would be a favorite feature of a lot of the > non-English locales, it would be widely-adopted. In turn, its very usage > would break legacy apps and resolvers that tried to resolve the long > labels/names. That keeps UTF8 names out of the legacy lookup path, while > also encouraging upgrades to applications, resolvers and servers that > support the necessary EDNS extensions. None of the other proposals have > the ability to preserve legacy lookups while simultaneously promoting the > adoption of the new service. > > There are numerous other benefits -- any application that does the EDNS > formatted lookup is (very) likely to have done nameprep on the name in the > application beforehand, it uses the same technology as A6 RRs so it can > ride the same adoption wave, and many others -- but the key point is that > the EDNS approach lets the domain names (and just the names) break the > apps and resolvers. Very little additional effort is required except for > the labels/names that do not exceed 63/255 bytes. That scenario is very > likely yes but it will only happen in a percentage of the cases instead of > all of them. > > > So for example in email, even though ACE might be required in SMTP > > and in message headers, we'll see UTF-8 in both places, and we'll > > be better off if MTAs and UAs that do try to handle these things > > do so in a uniform way. > > In a common scenario, the relay would write out the HELO name, the IP > address, and the PTR data. Setting aside HELO names for a moment, if the > PTR data included EDNS data which the relay or its resolver did not > understand, then the relay should leave the PTR string empty. If the app > is able to extract the EDNS name then there are ugly but feasible encoding > methods to keep it from destroying downstream mailers. As for HELO names, > there are also some potential problems there, but they don't look like > show stoppers (I don't know of any restrictions on length so encoding > appears to be the only issue). What this all means is that mail servers > aren't broken during a transition period, so no problem with EDNS-encoded > names (regardless of the length issues). (Yes I know that some anal sites > will break if they can't match HELO with PTR but that is an operational > concern which is not covered by protocol). > > As for outbound mail, there might be problems if MX RRs mix legacy and > modern names. Probably not if the netadmins design their forwarding > through multi-homed and multi-named relays, and maybe no problems at all > if the mailer can't read the complete list anyway. I mean, if the mailer > only sees MX 100 on an ASCII name and never sees MX 50 with an IDN, then > SMTP will still work if the mailer only sends to 100. It will break in > situations where intermediary relays aren't capable of handling delivery > to downstreams which have IDNs but that again is an operational issue > which can be overcome. Worth exploration and testing but I don't see any > problems that are insurmountable. > > > > a simple measurement of where implementations are today, UTF8 mostly > > > works while ACE does not work at all. > > > > for DNS servers, perhaps. for applications that transmit DNS names as > > protocol elements, the opposite is closer to the truth. > > I'm not arguing for or against ACE or just-use-UTF8. The point of the > response was to point out that ACE and just-use-UTF8 both introduce major > issues with backwards compatibility. If we really want to avoid the > problems of bad names in legacy lookups then they should both be avoided. > > Yes I also realize it's too late for this argument and that ACE is the > interim solution of choice. My bad for showing up late. Still the opinion > is valid. > > > on the contrary, ACE does mandate new behavior in any application that > > needs to do more with an IDN than query its DNS records, pass it to > > another application, or compare one IDN with another. > > None of the simple stuff above is reliable with ACE or just-use-UTF8 using > legacy apps or resolvers. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > From owner-idn@ops.ietf.org Sun Feb 4 22:55:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16676 for ; Sun, 4 Feb 2001 22:55:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PcXu-000995-00 for idn-data@psg.com; Sun, 04 Feb 2001 19:42:30 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14PcXt-00098y-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 19:42:29 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 462; Sun, 4 Feb 2001 19:42:28 -0800 Message-ID: <3A7E2123.D3A4B438@ehsco.com> Date: Sun, 04 Feb 2001 19:42:27 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: James Seng/Personal CC: idn@ops.ietf.org Subject: Re: [idn] I don't want 8-bit failures in 2011 References: <200102050121.UAA28557@astro.cs.utk.edu> <3A7E1633.44790F4@ehsco.com> <08d901c08f23$4f4f0560$aa2bd63f@jamessonyvaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've read the material there, almost all of it anyway. > And for a really long term solution (which may be totally out of the > scope of this WG) due to the radical approach proposed, > draft-klensin-dnsclass0e-00.txt. :-) Doesn't work to extend the label space. The question section has a fixed structure, so even with a new class the Qname is still limited to 63 byte labels and 255 byte octets. You'd have to do some ugly hacks to extend it (or use EDNS). There are lots of other problems with new classes. CNAMEs across classes probably won't work for example. All of the IN specific RRs (of which there are many) would have to be reinvented/redefined. Etc. Alternative class is creative but it brings too much baggage. EDNS is the most effective proposal currently on the table for many reasons. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Sun Feb 4 23:09:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16803 for ; Sun, 4 Feb 2001 23:09:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PclE-0009P0-00 for idn-data@psg.com; Sun, 04 Feb 2001 19:56:16 -0800 Received: from p5.usnyc1.stsn.com ([199.106.216.5] helo=nychoteldns01.stsn.com) by psg.com with esmtp (Exim 3.16 #1) id 14PclD-0009Of-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 19:56:15 -0800 Received: from jamessonyvaio ([10.0.208.56]) by nychoteldns01.stsn.com (8.11.0/8.11.0) with SMTP id f153v4n24294 for ; Sun, 4 Feb 2001 22:57:06 -0500 Message-ID: <09b701c08f27$5006e6e0$aa2bd63f@jamessonyvaio> From: "James Seng/Personal" To: Subject: [idn] related I-Ds Date: Mon, 5 Feb 2001 11:54:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I just realised I never really posted here but there are two I-Ds which is related to I18N that is in the directory. draft-hoffman-i18n-terms-00.txt talks about defination of I18N terminology. and draft-alvestrand-i18n-howto-00.txt talks about some basic idea on how to approach I18n. Would be useful reading. -James Seng From owner-idn@ops.ietf.org Mon Feb 5 02:16:14 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01802 for ; Mon, 5 Feb 2001 02:16:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14PfQ7-000CvF-00 for idn-data@psg.com; Sun, 04 Feb 2001 22:46:39 -0800 Received: from dokka.maxware.no ([195.139.236.69]) by psg.com with esmtp (Exim 3.16 #1) id 14PfQ6-000Cv8-00 for idn@ops.ietf.org; Sun, 04 Feb 2001 22:46:38 -0800 Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id HAA15633; Mon, 5 Feb 2001 07:46:19 +0100 Message-Id: <4.3.2.7.2.20010204193105.01f71350@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Feb 2001 19:41:01 -0800 To: "Mark Davis" , "Rick H Wesson" , "Paul Hoffman / IMC" From: Harald Alvestrand Subject: =?iso-8859-1?Q?Re:_[idn]_Namprep-02:_=DF.com?= Cc: In-Reply-To: <001d01c08ed0$1ec20f30$0c680b41@c1340594a> References: <4.3.2.7.2.20010204052001.0b547b58@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 09:30 04/02/2001 -0800, Mark Davis wrote: >The source documents to look at are: > >http://www.unicode.org/Public/3.1-Update/CaseFolding-3d4.beta.txt > >http://www.unicode.org/unicode/reports/tr21/ > >There it explains the treatment of es-zed. gotcha. what I missed was that this section: >3.1 Case mapping > >For each character in the input, if there is a lowercase mapping for >that character, the input character is changed to the mapped lowercase >character(s). The entries in the mapping table are derived from [UTR21]. could have read: The input string is case folded according to [UTR21] section 2.3. For most cases, this is the same thing as changing the input character to a lowercase character; however, for some cases more complex things happen. The mapping table in appendix N is used. This is derived from [UTR21] by applying the rules for equivalence classes of section 2.3 This makes it easier to see that this is NOT a simple conversion to lowercase. (there was no -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Mon Feb 5 11:08:49 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10617 for ; Mon, 5 Feb 2001 11:08:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Pnd5-000MKC-00 for idn-data@psg.com; Mon, 05 Feb 2001 07:32:35 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14Pnd4-000MJO-00 for idn@ops.ietf.org; Mon, 05 Feb 2001 07:32:34 -0800 Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id PAA09045; Mon, 5 Feb 2001 15:27:06 GMT From: "Brian W. Spolarich" To: "Eric A. Hall" Cc: Subject: RE: [idn] I don't want 8-bit failures in 2011 Date: Mon, 5 Feb 2001 10:31:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A7E1633.44790F4@ehsco.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | One of the great things about the EDNS proposal is that it provides long | labels and names. Since this would be a favorite feature of a lot of the | non-English locales, it would be widely-adopted. I don't find this to be a convincing statement. My impression was that the conventional wisdom with respect to CJK was that names would generally be shorter. Host labels are used by humans to identify and reach hosts and network services, not to compose short novellas. :-) Verisign folks (or anyone who might know), from the ML testbed, do we find that the CJK labels in terms of number of codepoints are longer, shorter, or about the same as the non-ML ones? If one is really worried about the 'long label problem', what data do we have on whether ACE or UTF-8 is better overall? Some ACEs are better at compression than others of course. All of this has been discussed in the past, but it doesn't hurt to re-open this issue if for no other reason than to facilitate consensus. I still think Klensin's point is right on: there are things we're doing with the DNS today that don't fit well with its purpose. We can either choose to change the DNS or provide a new service layer that is designed to meet those needs. -bws From owner-idn@ops.ietf.org Mon Feb 5 11:59:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11846 for ; Mon, 5 Feb 2001 11:59:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Poh7-000NaQ-00 for idn-data@psg.com; Mon, 05 Feb 2001 08:40:49 -0800 Received: from femail1.sdc1.sfba.home.com ([24.0.95.81]) by psg.com with esmtp (Exim 3.16 #1) id 14Poh7-000NZv-00 for idn@ops.ietf.org; Mon, 05 Feb 2001 08:40:49 -0800 Received: from c1340594a ([65.11.104.12]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010205164011.DUDF3627.femail1.sdc1.sfba.home.com@c1340594a>; Mon, 5 Feb 2001 08:40:11 -0800 Message-ID: <002c01c08f92$9079c330$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Mark Davis" , "Rick H Wesson" , "Paul Hoffman / IMC" , "Harald Alvestrand" Cc: References: <4.3.2.7.2.20010204052001.0b547b58@127.0.0.1> <4.3.2.7.2.20010204193105.01f71350@127.0.0.1> Subject: [idn] =?iso-8859-1?Q?Re:_=5Bidn=5D_Namprep-02:_=DF.com?= Date: Mon, 5 Feb 2001 08:42:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I agree that the wording in that section needs some cleanup. Just in case it is not clear, the CaseFolding tables are part of the UCD. They are currently in beta (although at this point it would require a special letter ballot to change them); they will be final by the end of March. > This makes it easier to see that this is NOT a simple conversion to lowercase. > (there was no Looks like this message was cut off. Mark ----- Original Message ----- From: "Harald Alvestrand" To: "Mark Davis" ; "Rick H Wesson" ; "Paul Hoffman / IMC" Cc: Sent: Sunday, February 04, 2001 19:41 Subject: Re: [idn] Namprep-02: .com > At 09:30 04/02/2001 -0800, Mark Davis wrote: > >The source documents to look at are: > > > >http://www.unicode.org/Public/3.1-Update/CaseFolding-3d4.beta.txt > > > >http://www.unicode.org/unicode/reports/tr21/ > > > >There it explains the treatment of es-zed. > > gotcha. > > what I missed was that this section: > > >3.1 Case mapping > > > >For each character in the input, if there is a lowercase mapping for > >that character, the input character is changed to the mapped lowercase > >character(s). The entries in the mapping table are derived from [UTR21]. > > could have read: > > The input string is case folded according to [UTR21] section 2.3. > For most cases, this is the same thing as changing the input character to a > lowercase character; however, for some cases more complex things happen. > The mapping table in appendix N is used. This is derived from [UTR21] by > applying the rules for equivalence classes of section 2.3 > > This makes it easier to see that this is NOT a simple conversion to lowercase. > (there was no > > -- > Harald Tveit Alvestrand, alvestrand@cisco.com > +47 41 44 29 94 > Personal email: Harald@Alvestrand.no > > > From owner-idn@ops.ietf.org Tue Feb 6 02:03:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07164 for ; Tue, 6 Feb 2001 02:03:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Q1qj-000Bqr-00 for idn-data@psg.com; Mon, 05 Feb 2001 22:43:37 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14Q1qj-000BqE-00 for idn@ops.ietf.org; Mon, 05 Feb 2001 22:43:37 -0800 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id WAA21566; Mon, 5 Feb 2001 22:43:20 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f166h5O14381; Mon, 5 Feb 2001 22:43:05 -0800 (PST) Received: from [10.0.1.8] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id WAA16062; Mon, 5 Feb 2001 22:42:47 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <002c01c08f92$9079c330$0c680b41@c1340594a> References: <4.3.2.7.2.20010204052001.0b547b58@127.0.0.1> <4.3.2.7.2.20010204193105.01f71350@127.0.0.1> <002c01c08f92$9079c330$0c680b41@c1340594a> Date: Tue, 6 Feb 2001 07:01:42 +0100 To: , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: [idn] Separate discussion list for IDNA Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Paul Hoffman and I have created a mailing list for discussions of only the IDNA algorithm described in draft-ietf-idn-idna-00.txt. The reason for a separate mailing list for this discussion is because it otherwise the discussion of IDNA will otherwise get bogged down with arguments whether IDNA is the correct way to do IDN. Those discussion should instead be on the IDN WG mailing list (although the protocol design team report concluded that an ACE-based solution in the application is the right way to go for the short term). Paul and I have not got many comments, but we feel that the document and description, as well as the algorithm, might be made better. Further, this message is sent to the apps-discuss list aswell as to the IDN mailing list as the IDNA algorithm can be used for domain name protocol components regardless of what protocol is using it. The name of the mailing list is ietf-idna@mail.apps.ietf.org. Subscribe by sending request to ietf-idna-request@mail.apps.ietf.org. paf -- Patrik Fltstrm Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-idn@ops.ietf.org Tue Feb 6 02:04:20 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08723 for ; Tue, 6 Feb 2001 02:04:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Q1qy-000Br9-00 for idn-data@psg.com; Mon, 05 Feb 2001 22:43:52 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14Q1qx-000BqK-00 for idn@ops.ietf.org; Mon, 05 Feb 2001 22:43:51 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id WAA23310 for ; Mon, 5 Feb 2001 22:43:24 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f166hQc23300 for ; Mon, 5 Feb 2001 22:43:26 -0800 (PST) Received: from [10.0.1.8] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id WAA16082 for ; Mon, 5 Feb 2001 22:43:11 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: Date: Tue, 6 Feb 2001 07:02:28 +0100 To: From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: [idn] IDNRA / IDNA Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Paul Hoffman and I no longer support the IDNRA algorithm specified in draft-ietf-idn-idnra-00.txt. Instead, we think a document should specify only what is passed in the DNS protocol (and possibly other protocols where domain name components are used) and leave it up to the implementor to implement the conversion between local script to network representation wherever he feels it is done best. Putting the presentation-layer change in just the application, not in the application and resolver, is a cleaner design that is easier to deploy. This is described in draft-ietf-idn-idna-00.txt, and we suggest further discussions about the IDNA algorithm. paf -- Patrik Fltstrm Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-idn@ops.ietf.org Wed Feb 7 09:36:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00333 for ; Wed, 7 Feb 2001 09:36:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QVAo-000GEJ-00 for idn-data@psg.com; Wed, 07 Feb 2001 06:02:18 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14QVAn-000GED-00 for idn@ops.ietf.org; Wed, 07 Feb 2001 06:02:17 -0800 Received: from valinor.malmo.trab.se (valinor [131.115.48.20]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f17E2E414738 for ; Wed, 7 Feb 2001 15:02:14 +0100 (MET) Received: from valinor by valinor.malmo.trab.se (8.10.1/TRM-1-KLIENT); Wed, 7 Feb 2001 15:02:13 +0100 (MET) (MET) Message-Id: <200102071402.f17E2DX16217@valinor.malmo.trab.se> Date: Wed, 7 Feb 2001 15:02:13 +0100 (MET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: [idn] nameprep in application may break things To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JgkwqHUvSimTlhcpHknPBQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk I think having nameprep done in applications will break things. If you do: nslookup Www.cisco.com you get as an answer: Name: WWW.cisco.com Address: 198.133.219.25 If you do: nslookup Www.cisco.com you get as an answer: Name: Www.cisco.com Address: 198.133.219.25 If you had nameprep in nslookup the answer in both cases would be: Name: www.cisco.com Address: 198.133.219.25 This will break all scripts calling nslookup and the doing simple string matching in the answer to test the result. I am sure there are lots of scripts that expect this behaviour. Dan From owner-idn@ops.ietf.org Wed Feb 7 09:58:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01059 for ; Wed, 7 Feb 2001 09:58:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QVl7-000Gix-00 for idn-data@psg.com; Wed, 07 Feb 2001 06:39:49 -0800 Received: from nordic.cisco.com ([144.254.116.47] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14QVl6-000GiJ-00 for idn@ops.ietf.org; Wed, 07 Feb 2001 06:39:48 -0800 Received: from [144.254.116.158] (stockholm11-dhcp27.cisco.com [144.254.116.158]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA24611; Wed, 7 Feb 2001 15:35:29 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <200102071402.f17E2DX16217@valinor.malmo.trab.se> References: <200102071402.f17E2DX16217@valinor.malmo.trab.se> Date: Wed, 7 Feb 2001 15:35:00 +0100 To: Dan Oscarsson , idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] nameprep in application may break things Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01059 At 15.02 +0100 01-02-07, Dan Oscarsson wrote: >I think having nameprep done in applications will break things. > >If you do: nslookup Www.cisco.com >you get as an answer: >Name: WWW.cisco.com >Address: 198.133.219.25 > >If you do: nslookup Www.cisco.com >you get as an answer: >Name: Www.cisco.com >Address: 198.133.219.25 > > >If you had nameprep in nslookup the answer in both cases would be: >Name: www.cisco.com >Address: 198.133.219.25 > > >This will break all scripts calling nslookup and the doing simple >string matching in the answer to test the result. >I am sure there are lots of scripts that expect this behaviour. One thing you forget is that applications which handle domainnames need to do nameprep, including your "simple script". Also, I question whether a DNS server rewrite the query part of a DNS packet. I doubt any DNS server do that. Further, I don't understand what you mean by your conclusion. Why should nslookup not present the non-nameprepped string to the user? You seem to think that nslookup is displaying the string which is the output of the nameprep calculation, but it could aswell be the input. paf -- Patrik Fltstrm Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-idn@ops.ietf.org Thu Feb 8 07:48:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05551 for ; Thu, 8 Feb 2001 07:48:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qq8O-000B9U-00 for idn-data@psg.com; Thu, 08 Feb 2001 04:25:12 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14Qq8N-000B9O-00 for idn@ops.ietf.org; Thu, 08 Feb 2001 04:25:12 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04923; Thu, 8 Feb 2001 07:25:09 -0500 (EST) Message-Id: <200102081225.HAA04923@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-dnsii-mdnp-02.txt Date: Thu, 08 Feb 2001 07:25:09 -0500 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 : The DNSII Multilingual Domain Name Protocol Author(s) : E. Chung, D. Leung Filename : draft-ietf-idn-dnsii-mdnp-02.txt Pages : 14 Date : 07-Feb-01 The core thinking for DNSII is that multilingual DNS requests SHOULD be signaled within a DNS label whether by way of a binary tag or an alphanumeric prefix, and that compatibility to legacy client applications SHOULD be taken into concern alongside legacy server implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-dnsii-mdnp-02.txt 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-dnsii-mdnp-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-dnsii-mdnp-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: <20010207145448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-dnsii-mdnp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-dnsii-mdnp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010207145448.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu Feb 8 07:52:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05593 for ; Thu, 8 Feb 2001 07:52:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qq8K-000B9G-00 for idn-data@psg.com; Thu, 08 Feb 2001 04:25:08 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14Qq8J-000B93-00 for idn@ops.ietf.org; Thu, 08 Feb 2001 04:25:07 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04907; Thu, 8 Feb 2001 07:25:05 -0500 (EST) Message-Id: <200102081225.HAA04907@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-dnsii-mdnr-01.txt Date: Thu, 08 Feb 2001 07:25:04 -0500 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 : DNSII Multilingual Domain Name Resolution Author(s) : E. Chung, D. Leung Filename : draft-ietf-idn-dnsii-mdnr-01.txt Pages : 15 Date : 07-Feb-01 This document outlines a resolution process that forms a framework for the resolution of multilingual domain names. Additionally, a tunneling mechanism utilizing additional RRs is introduced for the transition to a fully multilingual capable name space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-dnsii-mdnr-01.txt 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-dnsii-mdnr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-dnsii-mdnr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010207145438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-dnsii-mdnr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-dnsii-mdnr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010207145438.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Fri Feb 9 07:58:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15061 for ; Fri, 9 Feb 2001 07:58:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RCcx-000Lqe-00 for idn-data@psg.com; Fri, 09 Feb 2001 04:26:15 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14RCcw-000LqY-00 for idn@ops.ietf.org; Fri, 09 Feb 2001 04:26:14 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14190; Fri, 9 Feb 2001 07:26:13 -0500 (EST) Message-Id: <200102091226.HAA14190@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-mua-00.txt Date: Fri, 09 Feb 2001 07:26:13 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalizing Domain Names in Mail User Agents Author(s) : M. Kang Filename : draft-ietf-idn-mua-00.txt Pages : Date : 08-Feb-01 This document describes a way where domain names used in Internet e-mail can be internationalized by making changes only to end-user Mail User Agents and, by doing so, avoid damaging other applications which handle Internet e-mail, such as Message Transfer Agents and Delivery Agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-mua-00.txt 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-mua-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-mua-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010208140326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-mua-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-mua-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010208140326.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Sat Feb 10 12:27:33 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26767 for ; Sat, 10 Feb 2001 12:27:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RdF7-0000pu-00 for idn-data@psg.com; Sat, 10 Feb 2001 08:51:25 -0800 Received: from dt0b4n5b.maine.rr.com ([24.95.12.91] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 14RdF6-0000pn-00 for idn@ops.ietf.org; Sat, 10 Feb 2001 08:51:25 -0800 Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1AGo3C10711; Sat, 10 Feb 2001 11:50:03 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102101650.f1AGo3C10711@nic-naa.net> To: ietf-idna@mail.apps.ietf.org, ietf-provreg@cafax.se cc: idn@ops.ietf.org, duerst@w3.org, misha.wolf@reuters.com, cnnic-staff@cnnic.net.cn Subject: [idn] FYI: CNNIC services GBK, Big5, and UTF8 encodings Date: Sat, 10 Feb 2001 11:49:58 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk [Please trim the cc if replying!] Announced Monday, February 5th, at the following URL: http://english.peopledaily.com.cn/200102/05/eng20010205_61600.html My understanding is that CNNIC does or will provide a resolver which has support for these three encodings within the .cn ccTLD, defaults (like AOL keywords) any FQDN to FQDN.cn, supports these three encodings within the the DNS root, at least for some set of iso3166 labels, e.g., cn, and possibly tw and probably does more than the peopledaily writer describes. These aren't ASCII Compatible Extension (ACE) encoding mechanisms, and differ from the iDNS/NSI mechanism deployment of last November, which is ACE-based. For those familiar with either GBK or Big5, feel free to ignore the next two paras. For those unfamiliar with the GB series, GBK is the MS Windows PRC version (K == kuozhan "extension"), see also GB 1390.1-93 and GB 2312-80, and for the EUC-centric (me, other Unix i18n weenies), overlaps EUC-CN, and encodes the Chinese subset of ISO 10646-1:1993. For those unfamiliar with Big5, it is the de facto standard in Taiwan (Mac and Windows) and is equivalent to the first two planes of CNS 11643-1992, and for the EUC-centric, differs from EUC-TW code sets 0 and 1 mainly in having an additional encoding block. The CNNIC's approach appears to be at odds with a recent IDN WG I-D [1], which observed: > Note also that because modern OS are Unicode based and have network- > downloadable IMEs, "interoperability" is becoming less equivalent to > "use BIG5 characters only" or "use GB2312 character only" or "use > Shift-JIS characters only". What appears to be the case is CNNIC is offering network-downloadable code-set-specific resolvers, independent of (native) Unicode deployment in OS products and input method extension delivery mechanisms. Incidently, the January edition of the CNNIC semiannual data is available. Semiannual Survey Report on the Development of China's Internet (Jan. 2001) http://www.cnnic.cn/develst/e-cnnic200101.shtml Corrections and additional comments welcome, Maine is a ways from Beijing. Eric [1] "Han Ideograph (CJK) for Internationalized Domain Names", Seng et al., http://search.ietf.org/internet-drafts/draft-ietf-idn-cjk-00.txt From owner-idn@ops.ietf.org Sat Feb 10 21:48:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03227 for ; Sat, 10 Feb 2001 21:48:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RmCa-000Dw3-00 for idn-data@psg.com; Sat, 10 Feb 2001 18:25:24 -0800 Received: from blake.i-email.net ([203.126.116.232]) by psg.com with esmtp (Exim 3.16 #1) id 14RmCX-000DvA-00 for idn@ops.ietf.org; Sat, 10 Feb 2001 18:25:22 -0800 Received: from maynardibm (blake.i-email.net [203.126.116.232]) by blake.i-email.net (Postfix) with SMTP id A1CE5A890A for ; Sun, 11 Feb 2001 10:17:43 +0800 (SGT) Message-ID: <003b01c093d1$db3ba120$0200000a@maynardibm> From: "Maynard Kang" To: References: <200102091226.HAA14190@ietf.org> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-mua-00.txt Date: Sat, 10 Feb 2001 18:24:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Just some clarification as to the purpose of this document. Basically it is not intended to supersede IDNA, which is the direction of this working group now, but rather, it is a supporting document which serves to highlight certain issues MUAs may face when implementing IDNA (e.g. whether or not to render ACE when displaying IDNs part of mail content). As suggested by Paul Hoffman, this document will be evolved in due time to cover not just MUAs, but also other applications which face similar implementation issues, such as browsers and HTML editors (e.g. should all ACE IDNs appearing in HTML be rendered as abstract characters? Or displayed literally as ASCII if they are not part of a URL?) Comments are welcome. maynard ----- Original Message ----- From: To: Cc: Sent: Friday, 09 February, 2001 4:26 AM Subject: [idn] I-D ACTION:draft-ietf-idn-mua-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internationalized Domain Name Working Group of the IETF. > > Title : Internationalizing Domain Names in Mail User Agents > Author(s) : M. Kang > Filename : draft-ietf-idn-mua-00.txt > Pages : > Date : 08-Feb-01 > > This document describes a way where domain names used in Internet e-mail > can be internationalized by making changes only to end-user Mail User > Agents and, by doing so, avoid damaging other applications which handle > Internet e-mail, such as Message Transfer Agents and Delivery Agents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idn-mua-00.txt > > 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-mua-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idn-mua-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-idn@ops.ietf.org Sun Feb 11 07:11:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08078 for ; Sun, 11 Feb 2001 07:11:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ruzo-000OIy-00 for idn-data@psg.com; Sun, 11 Feb 2001 03:48:48 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14Ruzn-000OIs-00 for idn@ops.ietf.org; Sun, 11 Feb 2001 03:48:47 -0800 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f1BBmh418174; Sun, 11 Feb 2001 12:48:44 +0100 (MET) Message-Id: <200102111148.f1BBmh418174@malmo.trab.se> Date: Sun, 11 Feb 2001 12:47:31 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] nameprep in application may break things To: idn@ops.ietf.org, paf@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: a8KPuj4tgc2r7H4dIcP3Ew== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >> >>This will break all scripts calling nslookup and the doing simple >>string matching in the answer to test the result. >>I am sure there are lots of scripts that expect this behaviour. > >One thing you forget is that applications which handle domainnames >need to do nameprep, including your "simple script". All applications will not be fixed at the same time! I am sure there will be some with nameprep-handling and some without at the same time. > >Also, I question whether a DNS server rewrite the query part of a DNS >packet. I doubt any DNS server do that. No they normally do not, but if nslookup does nameprep it will lower case text before putting it into the query. So the response will contain a namepreped name instead of the originally entered. > >Further, I don't understand what you mean by your conclusion. Why >should nslookup not present the non-nameprepped string to the user? >You seem to think that nslookup is displaying the string which is the >output of the nameprep calculation, but it could aswell be the input. Many programs handling the result from DNS will decode the response and display the name form there. Instead of trying to match the input name with data in the response to be able to output the original (before nameprep) name. Dan From owner-idn@ops.ietf.org Mon Feb 12 19:43:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24596 for ; Mon, 12 Feb 2001 19:43:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ST6V-000Ag5-00 for idn-data@psg.com; Mon, 12 Feb 2001 16:13:59 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14ST6O-000Aeg-00 for idn@ops.ietf.org; Mon, 12 Feb 2001 16:13:52 -0800 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA13095; Sun, 11 Feb 2001 04:27:32 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1BCRFl05255; Sun, 11 Feb 2001 04:27:15 -0800 (PST) Received: from [192.168.1.22] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id EAA21980; Sun, 11 Feb 2001 04:27:09 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200102111148.f1BBmh418174@malmo.trab.se> References: <200102111148.f1BBmh418174@malmo.trab.se> Date: Sun, 11 Feb 2001 13:25:07 +0100 To: Dan , idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] nameprep in application may break things Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12.47 +0100 01-02-11, Dan wrote: > >One thing you forget is that applications which handle domainnames >>need to do nameprep, including your "simple script". > >All applications will not be fixed at the same time! I am sure there >will be some with nameprep-handling and some without at the same time. This is why I recommend the IDNA algorithm. See section 2.1.1 of draft-ietf-idn-idna-00.txt. paf From owner-idn@ops.ietf.org Tue Feb 13 06:36:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15248 for ; Tue, 13 Feb 2001 06:36:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SdHO-0002i8-00 for idn-data@psg.com; Tue, 13 Feb 2001 03:05:54 -0800 Date: Tue, 13 Feb 2001 11:09:47 +0100 To: WG-I18N@TERENA.NL, IETF mailing list on MIME and e-mail , , From: Jacob Palme Subject: [idn] Standards for machine translation in e-mail and netnews Cc: "Phil Scanlan" , , Keld Jrn Simonsen , Brian.Garr Message-Id: , Nick Shelness , "Pierre-Yves Focou. \"PY FOUCOU\"" , Francisco Sparta , Andrew Shuttleworth , Portal Coordination , REIS Mailing List , Thierry_Mayeur@lotus.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Work on standards for language-translation in e-mail and netnews can take place in the mailing list LANGTRANS@SU.SE. To subscribe to this mailing list, send a message to LISTSERV@SU.SE which contains the text SUB[SCRIBE] LANGTRANS When your subscription has been accepted, please write a short message to the list describing yourself and your interest in languate translation standards. More information and the present IETF drafts can be downloaded from http://dsv.su.se/jpalme/ietf/jp-ietf-home.html#translation The web page above earlier gave an incorrect description of how to join the mailing list. This has been corrected. -- Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/jpalme/ From owner-idn@ops.ietf.org Tue Feb 13 07:22:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15975 for ; Tue, 13 Feb 2001 07:22:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Se8e-0003RA-00 for idn-data@psg.com; Tue, 13 Feb 2001 04:00:56 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14Se8d-0003R4-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 04:00:56 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15606; Tue, 13 Feb 2001 07:00:55 -0500 (EST) Message-Id: <200102131200.HAA15606@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-amc-ace-m-00.txt Date: Tue, 13 Feb 2001 07:00:55 -0500 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 : AMC-ACE-M version 0.1.0 Author(s) : A. Costello Filename : draft-ietf-idn-amc-ace-m-00.txt Pages : Date : 12-Feb-01 AMC-ACE-M is a reversible map from a sequence of Unicode [UNICODE] characters to a sequence of letters (A-Z, a-z), digits (0-9), and hyphen-minus (-), henceforth called LDH characters. Such a map (called an 'ASCII-Compatible Encoding', or ACE) might be useful for internationalized domain names [IDN], because host name labels are currently restricted to LDH characters by [RFC952] and [RFC1123]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-amc-ace-m-00.txt 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-amc-ace-m-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-amc-ace-m-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010212125246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-amc-ace-m-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-amc-ace-m-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010212125246.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Feb 13 09:43:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20221 for ; Tue, 13 Feb 2001 09:43:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SgO1-0005WJ-00 for idn-data@psg.com; Tue, 13 Feb 2001 06:24:57 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14SgO0-0005WD-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 06:24:57 -0800 Received: from CLASSIC.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f1DEaVd93758 for ; Tue, 13 Feb 2001 09:36:31 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 13 Feb 2001 09:27:56 -0500 To: idn@ops.ietf.org From: Marc Blanchet Subject: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit This is a idn working group last call for comments on advancing the following document as a Informational RFC: Title : Requirements of Internationalized Domain Names Author(s) : Editors Zita Wenzel, James Seng Filename : http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-04.txt Please send substantive comments to the idn mailing list, and minor editorial comments to the authors. This last call period will end two week from today on February 28th, 2001. Marc Blanchet and James Seng (PS. stolen wg last call template from Bob Hinden, for those who recognize it...) Marc Blanchet Viagnie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From owner-idn@ops.ietf.org Tue Feb 13 10:29:59 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21869 for ; Tue, 13 Feb 2001 10:29:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Sh77-0006Lu-00 for idn-data@psg.com; Tue, 13 Feb 2001 07:11:33 -0800 Received: from [216.168.233.95] (helo=heron.verisign.com) by psg.com with esmtp (Exim 3.16 #1) id 14Sh75-0006LF-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 07:11:32 -0800 Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA19718 for ; Tue, 13 Feb 2001 10:10:55 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F91HV>; Tue, 13 Feb 2001 10:05:33 -0500 Message-ID: From: "Hollenbeck, Scott" To: idn@ops.ietf.org Subject: RE: [idn] W.G. Last Call on "Requirements of Internationalized Do main Names" Date: Tue, 13 Feb 2001 10:05:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk Minor editorial nits: Would it be possible to re-number the requirements so they are sequential without any missing or fractional numbers? As this document progresses and people unfamiliar with the discussions that led to edits read the document they are bound to wonder why the requirement numbers are disjoint. In section 1.3 (Definition of "hostname" and "Internationalized Domain Name"), where does the quoted definition for hostname come from? It would be wise to include a reference to appropriate RFCs, such as 952 and 1123. As section 6 (Acknowledgements) is currently written James (as one of the editors) gratefully acknowledges the contributions of himself, unless there is another James Seng somewhere with the same e-mail address. ;-) While James has definitely been a significant contributor I would suggest that an editor's name should not also appear in the Acknowledgements section. From owner-idn@ops.ietf.org Tue Feb 13 11:36:39 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23515 for ; Tue, 13 Feb 2001 11:36:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Shz5-0007Jd-00 for idn-data@psg.com; Tue, 13 Feb 2001 08:07:19 -0800 Received: from mail-a.bezeqint.net ([192.115.106.23] helo=mail.bezeqint.net) by psg.com with esmtp (Exim 3.16 #1) id 14Shz5-0007JB-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 08:07:19 -0800 Received: from QSM3 (bzq-183-178.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G8P0028SDQ44G@mail.bezeqint.net> for idn@ops.ietf.org; Tue, 13 Feb 2001 17:58:53 +0200 (IST) Date: Tue, 13 Feb 2001 17:59:54 +0200 From: Jonathan Rosenne Subject: RE: [idn] Last Call on Requirements for IDN - 25 In-reply-to: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> To: idn@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 (Normal) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I object to requirement [25] as unworkable. To follow the example given, I may be a Turk sitting in London and wish to access a Turkish host. The hostname will be folded using a British locale, which is wrong. As far as I know this is the only case of conflicting case maps, and even if there are a few more, I suggest to fold them all together, i.e. for IDN purposes I and Dotless I are to be considered equivalent. Jony From owner-idn@ops.ietf.org Tue Feb 13 11:52:59 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23907 for ; Tue, 13 Feb 2001 11:52:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SiMc-0007iV-00 for idn-data@psg.com; Tue, 13 Feb 2001 08:31:38 -0800 Received: from femail2.sdc1.sfba.home.com ([24.0.95.82]) by psg.com with esmtp (Exim 3.16 #1) id 14SiMb-0007iO-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 08:31:37 -0800 Received: from c1340594a ([65.11.104.12]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010213163111.JWGI2521.femail2.sdc1.sfba.home.com@c1340594a>; Tue, 13 Feb 2001 08:31:11 -0800 Message-ID: <008f01c095da$9f9bc950$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Jonathan Rosenne" , References: Subject: Re: [idn] Last Call on Requirements for IDN - 25 Date: Tue, 13 Feb 2001 08:32:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think it is just badly worded, since the principle is clear. [25] Case folding MUST be locale independent. For example, Latin capital letter I (U+0049) case folded to lower case in the Turkish context will become Latin small letter dotless i (U+0131). But in the English context, it will become Latin small letter i (U+0069). should be something like: Case folding MUST be locale independent. If it were locale-dependent, then different clients would get different results. For example, Latin capital letter I (U+0049) case folded to lower case in the Turkish context will become Latin small letter dotless i (U+0131). But in the English context, it will become Latin small letter i (U+0069). ----- Original Message ----- From: "Jonathan Rosenne" To: Sent: Tuesday, February 13, 2001 07:59 Subject: RE: [idn] Last Call on Requirements for IDN - 25 > > I object to requirement [25] as unworkable. > > To follow the example given, I may be a Turk sitting in London and wish to > access a Turkish host. The hostname will be folded using a British locale, which > is wrong. > > As far as I know this is the only case of conflicting case maps, and even if > there are a few more, I suggest to fold them all together, i.e. for IDN purposes > I and Dotless I are to be considered equivalent. > > Jony > > From owner-idn@ops.ietf.org Tue Feb 13 11:53:07 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23918 for ; Tue, 13 Feb 2001 11:53:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SiQ1-0007mr-00 for idn-data@psg.com; Tue, 13 Feb 2001 08:35:09 -0800 Received: from mail-a.bezeqint.net ([192.115.106.23] helo=mail.bezeqint.net) by psg.com with esmtp (Exim 3.16 #1) id 14SiPz-0007m6-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 08:35:07 -0800 Received: from QSM3 (bzq-183-178.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G8P001H7DSVN3@mail.bezeqint.net> for idn@ops.ietf.org; Tue, 13 Feb 2001 18:00:34 +0200 (IST) Date: Tue, 13 Feb 2001 18:01:33 +0200 From: Jonathan Rosenne Subject: RE: [idn] Last Call on Requirements for IDN - 25 In-reply-to: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> To: idn@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 (Normal) Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry - my mistake - I misread the requirement. Jony From owner-idn@ops.ietf.org Tue Feb 13 20:41:40 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04095 for ; Tue, 13 Feb 2001 20:41:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SqSu-000Hz8-00 for idn-data@psg.com; Tue, 13 Feb 2001 17:10:40 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14SqSs-000Hz1-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 17:10:39 -0800 Received: (qmail 19767 invoked by uid 1001); 14 Feb 2001 01:10:48 -0000 Date: 14 Feb 2001 01:10:48 -0000 Message-ID: <20010214011048.24067.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" References: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk I have five general objections to the document: (1) The models are oversimplified to the point of being deceptive. (2) Some of the requirements are unclear. (3) Some of the requirements are in conflict with current practice. (4) No justifications are provided for most of the requirements. (5) Many of the requirements overstate ``here's a cost to consider'' as ``we must minimize this cost.'' I also have specific comments on several of the requirements. > It MUST make the minimum number of changes to existing protocols on > all layers of the stack. This requirement is wildly overstated. If, for example, we can save years of effort and billions of dollars in redeployment costs by making one additional change to (e.g.) the SMTP protocol, then we should do so. Obviously we should consider the number of protocol changes required. But this number is not the same as cost. Demanding that it be minimized is stupid. > It MUST continue to allow any system anywhere to resolve any > internationalized domain name. Huh? ``Continue'' to resolve IDNs? What IDNs? > The protocol MUST NOT allow an IDN to be returned to a requestor > that requests the IP-to-(old)-domain-name mapping service. Huh? Why shouldn't gethostbyaddr() provide IDNs? > [3] The same name resolution request MUST generate the same response, > regardless of the location or localization settings in the resolver, in > the master server, and in any slave servers involved in the resolution > process. This requirement prohibits widespread current practice. Example: Akamai's responses depend on the location of the resolver. > [4] The protocol MUST NOT require that the current DNS cache > servers be modified to support IDN. This is another wildly overstated requirement. We should, of course, carefully evaluate all necessary upgrade costs. > [5] A caching server MUST NOT return data in response to a query that > would not have been returned if the same query had been presented to an > authoritative server. This needs clarification. If a cache receives foo CNAME bar from one server, and bar A 1.2.3.4 from another, then it will end up sending one message with both pieces of information, even though that data would not have been returned from any particular server. > However, these changes SHOULD be as small as possible This is overstated. > [8] The protocol supporting the service SHOULD be as simple as possible > from the user's perspective. Ideally, users SHOULD NOT realize that IDN > was added on to the existing DNS. Huh? Aren't we _trying_ to provide extra features for users? > [10] The best solution is one that maintains maximum feasible > compatibility with current DNS standards as long as it meets the other > requirements in this document. This is wildly overstated. > It also needs to sort names into order. Maybe, maybe not. The only reason for this requirement is DNSSEC's controversial NXT feature. > [22] To achieve interoperability, canonicalization MUST be done at a > single well-defined place in the DNS resolution process. This is wildly overstated. With fast nameprep, canonicalization won't happen anywhere in the resolution process, because names subject to resolution will already be good names. > The protocol MUST specify canonicalization; It's clear to me that we need to define which names are good. It's not clear to me that we should allow bad names. > [27] Any conversion (case, ligature folding, punctuation folding, etc) > from what the user enters into a client to what the client asks for > resolution MUST be done identically on any request from any client. This requirement prohibits widespread current practice. Example: some browsers automatically append .com to certain names; some don't. > [33] An IDN-capable resolver or server SHALL NOT generate more traffic > than a non-IDN-capable resolver or server would when resolving an > ASCII-only domain name. This requirement is wildly overstated. I don't think there are any serious proposals that would generate extra bandwidth for ASCII names, but why should we refuse to listen if someone comes up with a great idea that has this minor side effect? We should, of course, carefully evaluate traffic costs. > [34] The service SHOULD NOT add new centralized administration for the > DNS. A domain administrator SHOULD be able to create internationalized > names as easily as adding current domain names. The second sentence, taken literally, is unreasonable. Clarify. > [35] Within a single zone, the zone manager MUST be able to define > equivalence rules that suit the purpose of the zone, This requirement prohibits widespread current practice. I have no idea what the authors are thinking. > Slave servers MAY be either authorized by the zone owner (secondary > servers) or unauthorized (so-called "stealth secondaries"). The authors are obviously a bit confused about DNS here. The difference between a stealth secondary and a non-stealth secondary is that a stealth secondary is not listed in NS records. Both types of secondary are normally authorized by the owner. ---Dan From owner-idn@ops.ietf.org Tue Feb 13 23:18:43 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07423 for ; Tue, 13 Feb 2001 23:18:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14St8A-000LCP-00 for idn-data@psg.com; Tue, 13 Feb 2001 20:01:26 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14St88-000LCH-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 20:01:24 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 377C6FFC01; Wed, 14 Feb 2001 12:01:04 +0800 (SGT) Message-ID: <03f201c0963a$9dd586a0$f900a8c0@jamessonyvaio> From: "James Seng/Personal" To: "D. J. Bernstein" , References: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> <20010214011048.24067.qmail@cr.yp.to> Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" Date: Wed, 14 Feb 2001 12:00:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan, The shortest answer I can give you is to go thru our previous discussion since Dec 99. This requirements doc was drafted from various comments make across the many months of discussion within this mailing list so technically, Zita or myself are Editors, not Authors. Please note that if you have specific objections to any requirements, then the most constructive way to move forward with it is to propose your version of the wording. Zita is current busy with her work at NATO so I will be doing the last tweaking. And as we discussed before, I will do the tweaking if there is specific replacement wordings proposed, so please keep them coming. Expect -05 as soon as next week. -James Seng ----- Original Message ----- From: "D. J. Bernstein" To: Sent: Wednesday, February 14, 2001 9:10 AM Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" > I have five general objections to the document: > > (1) The models are oversimplified to the point of being deceptive. > (2) Some of the requirements are unclear. > (3) Some of the requirements are in conflict with current practice. > (4) No justifications are provided for most of the requirements. > (5) Many of the requirements overstate ``here's a cost to consider'' > as ``we must minimize this cost.'' > > I also have specific comments on several of the requirements. > > > It MUST make the minimum number of changes to existing protocols on > > all layers of the stack. > > This requirement is wildly overstated. If, for example, we can save > years of effort and billions of dollars in redeployment costs by making > one additional change to (e.g.) the SMTP protocol, then we should do so. > > Obviously we should consider the number of protocol changes required. > But this number is not the same as cost. Demanding that it be minimized > is stupid. > > > It MUST continue to allow any system anywhere to resolve any > > internationalized domain name. > > Huh? ``Continue'' to resolve IDNs? What IDNs? > > > The protocol MUST NOT allow an IDN to be returned to a requestor > > that requests the IP-to-(old)-domain-name mapping service. > > Huh? Why shouldn't gethostbyaddr() provide IDNs? > > > [3] The same name resolution request MUST generate the same response, > > regardless of the location or localization settings in the resolver, in > > the master server, and in any slave servers involved in the resolution > > process. > > This requirement prohibits widespread current practice. Example: > Akamai's responses depend on the location of the resolver. > > > [4] The protocol MUST NOT require that the current DNS cache > > servers be modified to support IDN. > > This is another wildly overstated requirement. We should, of course, > carefully evaluate all necessary upgrade costs. > > > [5] A caching server MUST NOT return data in response to a query that > > would not have been returned if the same query had been presented to an > > authoritative server. > > This needs clarification. If a cache receives foo CNAME bar from one > server, and bar A 1.2.3.4 from another, then it will end up sending one > message with both pieces of information, even though that data would not > have been returned from any particular server. > > > However, these changes SHOULD be as small as possible > > This is overstated. > > > [8] The protocol supporting the service SHOULD be as simple as possible > > from the user's perspective. Ideally, users SHOULD NOT realize that IDN > > was added on to the existing DNS. > > Huh? Aren't we _trying_ to provide extra features for users? > > > [10] The best solution is one that maintains maximum feasible > > compatibility with current DNS standards as long as it meets the other > > requirements in this document. > > This is wildly overstated. > > > It also needs to sort names into order. > > Maybe, maybe not. The only reason for this requirement is DNSSEC's > controversial NXT feature. > > > [22] To achieve interoperability, canonicalization MUST be done at a > > single well-defined place in the DNS resolution process. > > This is wildly overstated. With fast nameprep, canonicalization won't > happen anywhere in the resolution process, because names subject to > resolution will already be good names. > > > The protocol MUST specify canonicalization; > > It's clear to me that we need to define which names are good. It's not > clear to me that we should allow bad names. > > > [27] Any conversion (case, ligature folding, punctuation folding, etc) > > from what the user enters into a client to what the client asks for > > resolution MUST be done identically on any request from any client. > > This requirement prohibits widespread current practice. Example: some > browsers automatically append .com to certain names; some don't. > > > [33] An IDN-capable resolver or server SHALL NOT generate more traffic > > than a non-IDN-capable resolver or server would when resolving an > > ASCII-only domain name. > > This requirement is wildly overstated. I don't think there are any > serious proposals that would generate extra bandwidth for ASCII names, > but why should we refuse to listen if someone comes up with a great idea > that has this minor side effect? > > We should, of course, carefully evaluate traffic costs. > > > [34] The service SHOULD NOT add new centralized administration for the > > DNS. A domain administrator SHOULD be able to create internationalized > > names as easily as adding current domain names. > > The second sentence, taken literally, is unreasonable. Clarify. > > > [35] Within a single zone, the zone manager MUST be able to define > > equivalence rules that suit the purpose of the zone, > > This requirement prohibits widespread current practice. I have no idea > what the authors are thinking. > > > Slave servers MAY be either authorized by the zone owner (secondary > > servers) or unauthorized (so-called "stealth secondaries"). > > The authors are obviously a bit confused about DNS here. > > The difference between a stealth secondary and a non-stealth secondary > is that a stealth secondary is not listed in NS records. Both types of > secondary are normally authorized by the owner. > > ---Dan > From owner-idn@ops.ietf.org Tue Feb 13 23:28:26 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07759 for ; Tue, 13 Feb 2001 23:28:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14StKL-000LTX-00 for idn-data@psg.com; Tue, 13 Feb 2001 20:14:01 -0800 Received: from glucose.pas.idealab.com ([64.208.8.249] helo=idealab.com) by psg.com with smtp (Exim 3.16 #1) id 14StKK-000LTR-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 20:14:01 -0800 Received: (qmail 10884 invoked by uid 526); 14 Feb 2001 04:13:59 -0000 To: idn@ops.ietf.org, "D. J. Bernstein" Subject: Re: [idn] The report from the design team References: <5.0.2.1.1.20010115021238.03d99d20@mail.viagenie.qc.ca> <20010115115615.6526.qmail@cr.yp.to> From: Marc Tamsky Date: 13 Feb 2001 20:13:59 -0800 In-Reply-To: "D. J. Bernstein"'s message of "15 Jan 2001 11:56:15 -0000" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-idn@ops.ietf.org Precedence: bulk >>>>> On 15 Jan 2001 11:56:15 -0000, "D. J. Bernstein" said: >> The application-only solutions proposed are clearly easier to >> implement than the infrastructure solutions, > I don't believe you. We need facts about the actual deployment costs, > not buzzwords like ``application-only.'' > I've started a web page at http://cr.yp.to/proto/idn.html to tally the > costs of the proposals. Specific contributions are welcome. >> However, we cannot simply put binary characters into the current DNS >> without breaking many protocols and many DNS servers. > Give us the details. Exactly which pieces of software break, and how? I concur with Dan's line of questioning here. Every argument to date has been hand-waving about "software that will break." Which pieces of software, that use what protocols will break when UTF-8 appears in DNS RR? How do they break? Is the author/company still maintaining it? Is it known how easy it is to work a fix? Has a fix been published? Is it an input system problem? Does it depend on the OS resolver getting changed? More of these questions need to be identified and cataloged. Only then can anyone say with some basis in fact, and not conjecture, that one proposal creates more or less work than another. Today, if those same "broken" pieces of software were to be fed non-RFC DNS information and they crash, wouldn't that be material for a new or existing CERT advisory? (DOS vulnerability, host compromise come to mind.) Marc. From owner-idn@ops.ietf.org Wed Feb 14 00:02:49 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08524 for ; Wed, 14 Feb 2001 00:02:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Stwx-000MRW-00 for idn-data@psg.com; Tue, 13 Feb 2001 20:53:55 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14Stwx-000MRQ-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 20:53:55 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 687 for ; Tue, 13 Feb 2001 20:53:52 -0800 Message-ID: <3A8A0F60.59CBBE59@ehsco.com> Date: Tue, 13 Feb 2001 20:53:52 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] The report from the design team References: <5.0.2.1.1.20010115021238.03d99d20@mail.viagenie.qc.ca> <20010115115615.6526.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Every argument to date has been hand-waving about "software that will > break." My .02 to this is that I don't believe we should be requiring that a solution make all legacy implementations forward compatibile. Note that this is different from backwards compatible. The requirements as stated are trying to make legacy gear forward compatibile with some future solution. Instead, it should be focused on ensuring that whatever future solution is chosen does not willingly break legacy equipment. We certainly don't design RRs so that they instantly function with all legacy equipment. We don't design ESMTP extensions so that they immediately function with legacy mailers. Instead we design so that we don't break legacy stuff, and then leave it up to the net admins and operators to upgrade when the feature is important. IMO we should be treating IDNS the same way. We are limiting ourselves by an artifical and unreasonable restriction when we demand that all proposals must "allow any system anywhere to resolve any internationalized domain name." That requirement should be removed from the spec completely. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed Feb 14 00:02:58 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08535 for ; Wed, 14 Feb 2001 00:02:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Stso-000MKl-00 for idn-data@psg.com; Tue, 13 Feb 2001 20:49:38 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Stsn-000MKe-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 20:49:38 -0800 Received: (qmail 24132 invoked by uid 1001); 14 Feb 2001 04:49:54 -0000 Date: 14 Feb 2001 04:49:54 -0000 Message-ID: <20010214044954.9282.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" References: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> <20010214011048.24067.qmail@cr.yp.to> <03f201c0963a$9dd586a0$f900a8c0@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng/Personal writes: > The shortest answer I can give you is to go thru our previous discussion > since Dec 99. I have. The archives don't answer any of my objections. ---Dan From owner-idn@ops.ietf.org Wed Feb 14 01:24:55 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12918 for ; Wed, 14 Feb 2001 01:24:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SuzU-000OKK-00 for idn-data@psg.com; Tue, 13 Feb 2001 22:00:36 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14SuzQ-000OKD-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 22:00:35 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id BAA22945; Wed, 14 Feb 2001 01:00:16 -0500 (EST) Message-Id: <200102140600.BAA22945@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: idn@ops.ietf.org Subject: Re: [idn] The report from the design team In-reply-to: Your message of "Tue, 13 Feb 2001 20:53:52 PST." <3A8A0F60.59CBBE59@ehsco.com> Date: Wed, 14 Feb 2001 01:00:16 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > IMO we should be treating IDNS the same way. We are limiting ourselves by > an artifical and unreasonable restriction when we demand that all > proposals must "allow any system anywhere to resolve any internationalized > domain name." That requirement should be removed from the spec completely. the requirement might be overstated, but I don't think we can eliminate it completely. to put the question in a more practical light: if someone sends out mail with a return address that uses an IDN, is it acceptable if the recipient cannot reply to that message unless his mail reader and the chain of SMTPs between him and the original sender support IDNs? personally, I don't think so. Keith From owner-idn@ops.ietf.org Wed Feb 14 02:05:41 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24299 for ; Wed, 14 Feb 2001 02:05:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SvqM-000P7Y-00 for idn-data@psg.com; Tue, 13 Feb 2001 22:55:14 -0800 Received: from web5503.mail.yahoo.com ([216.115.106.186]) by psg.com with smtp (Exim 3.16 #1) id 14SvqL-000P7O-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 22:55:14 -0800 Message-ID: <20010214065513.3015.qmail@web5503.mail.yahoo.com> Received: from [159.226.6.26] by web5503.mail.yahoo.com; Tue, 13 Feb 2001 22:55:13 PST Date: Tue, 13 Feb 2001 22:55:13 -0800 (PST) From: wenhui zhang Subject: Re: [idn] FYI: CNNIC services GBK, Big5, and UTF8 encodings To: Eric Brunner-Williams in Portland Maine , ietf-idna@mail.apps.ietf.org, ietf-provreg@cafax.se Cc: idn@ops.ietf.org, duerst@w3.org, misha.wolf@reuters.com, cnnic-staff@cnnic.net.cn In-Reply-To: <200102101650.f1AGo3C10711@nic-naa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Hello The resolver of Chinese Domain Name System(CDNS), as a part of CDNS which CNNIC provides, is just like the resolver of Netscape browser that does not change the encoding of user's local requires and send the original requirement to a code-switcher. The code switcher can transfer local encoding to UTF-8 and vice versa. Any local encoding query before it enter to name server is changed to UTF8-based encoding query. The name server can handle UTF8-based encoding query.The ACE-based domain name will not be changed and its processes is just as former. Using this mechanism, no matter what kind of native encoding set, the multilingual domain name system will work correctly. Yours regards deng xiang 2001.2 --- Eric Brunner-Williams in Portland Maine wrote: > [Please trim the cc if replying!] > > Announced Monday, February 5th, at the following > URL: > > http://english.peopledaily.com.cn/200102/05/eng20010205_61600.html > > My understanding is that CNNIC does or will provide > a resolver which has > support for these three encodings within the .cn > ccTLD, > defaults (like AOL keywords) any FQDN to FQDN.cn, > supports these three encodings within the the DNS > root, at least > for some set of iso3166 labels, e.g., cn, and > possibly tw > and probably does more than the peopledaily writer > describes. > > These aren't ASCII Compatible Extension (ACE) > encoding mechanisms, and differ > from the iDNS/NSI mechanism deployment of last > November, which is ACE-based. > > For those familiar with either GBK or Big5, feel > free to ignore the next > two paras. > > For those unfamiliar with the GB series, GBK is the > MS Windows PRC version > (K == kuozhan "extension"), see also GB 1390.1-93 > and GB 2312-80, and for > the EUC-centric (me, other Unix i18n weenies), > overlaps EUC-CN, and encodes > the Chinese subset of ISO 10646-1:1993. > > For those unfamiliar with Big5, it is the de facto > standard in Taiwan (Mac > and Windows) and is equivalent to the first two > planes of CNS 11643-1992, > and for the EUC-centric, differs from EUC-TW code > sets 0 and 1 mainly in > having an additional encoding block. > > The CNNIC's approach appears to be at odds with a > recent IDN WG I-D [1], > which observed: > > > Note also that because modern OS are Unicode based > and have network- > > downloadable IMEs, "interoperability" is becoming > less equivalent to > > "use BIG5 characters only" or "use GB2312 > character only" or "use > > Shift-JIS characters only". > > What appears to be the case is CNNIC is offering > network-downloadable > code-set-specific resolvers, independent of (native) > Unicode deployment > in OS products and input method extension delivery > mechanisms. > > Incidently, the January edition of the CNNIC > semiannual data is available. > Semiannual Survey Report on the Development of > China's Internet (Jan. 2001) > http://www.cnnic.cn/develst/e-cnnic200101.shtml > > Corrections and additional comments welcome, Maine > is a ways from Beijing. > > Eric > > [1] "Han Ideograph (CJK) for Internationalized > Domain Names", Seng et al., > > http://search.ietf.org/internet-drafts/draft-ietf-idn-cjk-00.txt > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-idn@ops.ietf.org Wed Feb 14 02:41:10 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24584 for ; Wed, 14 Feb 2001 02:41:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SwL4-000PYA-00 for idn-data@psg.com; Tue, 13 Feb 2001 23:26:58 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14SwL3-000PXz-00 for idn@ops.ietf.org; Tue, 13 Feb 2001 23:26:57 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 567 for ; Tue, 13 Feb 2001 23:26:55 -0800 Message-ID: <3A8A333E.5DCEC31B@ehsco.com> Date: Tue, 13 Feb 2001 23:26:54 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: idn@ops.ietf.org Subject: Re: [idn] The report from the design team References: <200102140600.BAA22945@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > the requirement might be overstated, but I don't think we can > eliminate it completely. Let me point out that this requirement prohibits the EDNS, DNSII, and new Class proposals, and also prohibits longer labels and names (they will not be forward compatible with legacy equipment). No change to DNS whatsoever will be tolerated by the current requirement. > to put the question in a more practical light: if someone sends > out mail with a return address that uses an IDN, is it acceptable > if the recipient cannot reply to that message unless his mail > reader and the chain of SMTPs between him and the original sender > support IDNs? The end-user still has to upgrade the MUA to use ACE. If he doesn't, then at least one of the SMTP servers will have to do the work (assuming they accept an unconverted IDN from the MUA in the first place) whenever the user clicks on the internationalized mailto: link. We are talking about varying degrees of breakage. Anything that presents a process with a local-format IDN has the potential to break things if the systems aren't compliant with whatever solution is chosen, and this includes ACE. Breakage of some degree is absolutely unavoidable. As for how a new DNS message format would address this problem, no mail server should accept MAIL FROM which includes a domain name that the MTA doesn't recognize as legitimate, so in all likelihood a new ESMTP extension would almost certainly be required in order to accomodate an IDN solution that uses longer labels/names or non-ascii characters in the SMTP envelope. This may be required even when ACE is used though. What then? There are other examples which are also hard to deal with. Ancient print servers that fire off alerts over SMTP aren't likely to be fixed easily, and ACE allows them to work with IDNs after a manual conversion and reconfiguration, while this would not be possible with a new DNS message format. There are at least a dozen operational solutions to that kind of problem however, even when a protocol solution is not available. Tough question. I don't know the answer. It just seems to be a bad idea to preclude all options up front. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed Feb 14 04:32:41 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25332 for ; Wed, 14 Feb 2001 04:32:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Sxtj-00018Q-00 for idn-data@psg.com; Wed, 14 Feb 2001 01:06:51 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14Sxti-00018J-00 for idn@ops.ietf.org; Wed, 14 Feb 2001 01:06:50 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 85D3EFFC05; Wed, 14 Feb 2001 17:06:24 +0800 (SGT) Message-ID: <060501c09665$45499f50$f900a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Eric A. Hall" Cc: References: <200102140600.BAA22945@astro.cs.utk.edu> <3A8A333E.5DCEC31B@ehsco.com> Subject: Re: [idn] The report from the design team Date: Wed, 14 Feb 2001 17:05:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Before this discussion goes further, please put your specific changes to the requirements with the proposed new wordings here. Thanks! -James Seng ----- Original Message ----- From: "Eric A. Hall" Cc: Sent: Wednesday, February 14, 2001 3:26 PM Subject: Re: [idn] The report from the design team > > > the requirement might be overstated, but I don't think we can > > eliminate it completely. > > Let me point out that this requirement prohibits the EDNS, DNSII, and new > Class proposals, and also prohibits longer labels and names (they will not > be forward compatible with legacy equipment). No change to DNS whatsoever > will be tolerated by the current requirement. > > > to put the question in a more practical light: if someone sends > > out mail with a return address that uses an IDN, is it acceptable > > if the recipient cannot reply to that message unless his mail > > reader and the chain of SMTPs between him and the original sender > > support IDNs? > > The end-user still has to upgrade the MUA to use ACE. If he doesn't, then > at least one of the SMTP servers will have to do the work (assuming they > accept an unconverted IDN from the MUA in the first place) whenever the > user clicks on the internationalized mailto: link. > > We are talking about varying degrees of breakage. Anything that presents a > process with a local-format IDN has the potential to break things if the > systems aren't compliant with whatever solution is chosen, and this > includes ACE. Breakage of some degree is absolutely unavoidable. > > As for how a new DNS message format would address this problem, no mail > server should accept MAIL FROM which includes a domain name that the MTA > doesn't recognize as legitimate, so in all likelihood a new ESMTP > extension would almost certainly be required in order to accomodate an IDN > solution that uses longer labels/names or non-ascii characters in the SMTP > envelope. This may be required even when ACE is used though. What then? > > There are other examples which are also hard to deal with. Ancient print > servers that fire off alerts over SMTP aren't likely to be fixed easily, > and ACE allows them to work with IDNs after a manual conversion and > reconfiguration, while this would not be possible with a new DNS message > format. There are at least a dozen operational solutions to that kind of > problem however, even when a protocol solution is not available. > > Tough question. I don't know the answer. It just seems to be a bad idea to > preclude all options up front. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > From owner-idn@ops.ietf.org Wed Feb 14 04:57:42 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25497 for ; Wed, 14 Feb 2001 04:57:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14SyKi-0001WR-00 for idn-data@psg.com; Wed, 14 Feb 2001 01:34:44 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14SyKh-0001WL-00 for idn@ops.ietf.org; Wed, 14 Feb 2001 01:34:43 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 705; Wed, 14 Feb 2001 01:34:41 -0800 Message-ID: <3A8A5131.8741006B@ehsco.com> Date: Wed, 14 Feb 2001 01:34:41 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: James Seng/Personal CC: idn@ops.ietf.org Subject: Re: [idn] The report from the design team References: <200102140600.BAA22945@astro.cs.utk.edu> <3A8A333E.5DCEC31B@ehsco.com> <060501c09665$45499f50$f900a8c0@jamessonyvaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Before this discussion goes further, please put your specific changes to > the requirements with the proposed new wordings here. Thanks! James, as I said, I believe the clause should be removed. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Wed Feb 14 08:28:00 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28048 for ; Wed, 14 Feb 2001 08:27:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14T1a2-00042X-00 for idn-data@psg.com; Wed, 14 Feb 2001 05:02:46 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14T1a1-00042P-00 for idn@ops.ietf.org; Wed, 14 Feb 2001 05:02:45 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA23205; Wed, 14 Feb 2001 08:02:42 -0500 (EST) Message-Id: <200102141302.IAA23205@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: idn@ops.ietf.org Subject: Re: [idn] The report from the design team In-reply-to: Your message of "Tue, 13 Feb 2001 23:26:54 PST." <3A8A333E.5DCEC31B@ehsco.com> Date: Wed, 14 Feb 2001 08:02:42 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > to put the question in a more practical light: if someone sends > > out mail with a return address that uses an IDN, is it acceptable > > if the recipient cannot reply to that message unless his mail > > reader and the chain of SMTPs between him and the original sender > > support IDNs? > > The end-user still has to upgrade the MUA to use ACE. If he doesn't, then > at least one of the SMTP servers will have to do the work (assuming they > accept an unconverted IDN from the MUA in the first place) whenever the > user clicks on the internationalized mailto: link. you've changed test cases on me :) the MUAs I use don't support mailto: links at all, so I don't care about them as much as I care about reply functionality working. (I generally find mailto: links pretty useless, since they force me to use the web browser's mail reader, and they don't let me pick and choose the addresses to which I want to send a single message.) > We are talking about varying degrees of breakage. Anything that presents a > process with a local-format IDN has the potential to break things if the > systems aren't compliant with whatever solution is chosen, and this > includes ACE. Breakage of some degree is absolutely unavoidable. agreed. > As for how a new DNS message format would address this problem, no mail > server should accept MAIL FROM which includes a domain name that the MTA > doesn't recognize as legitimate, so in all likelihood a new ESMTP > extension would almost certainly be required in order to accomodate an IDN > solution that uses longer labels/names or non-ascii characters in the SMTP > envelope. This may be required even when ACE is used though. What then? it would be possible to design an ACE that encoded a single IDN label as multiple DNS labels. we need some idea as to whether a single-label ACE that uses compression is "good enough" and I haven't seen that yet. Keith From owner-idn@ops.ietf.org Wed Feb 14 15:25:44 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15877 for ; Wed, 14 Feb 2001 15:25:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14T83M-000BhP-00 for idn-data@psg.com; Wed, 14 Feb 2001 11:57:28 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14T83L-000BgF-00 for idn@ops.ietf.org; Wed, 14 Feb 2001 11:57:27 -0800 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA02979; Wed, 14 Feb 2001 11:57:12 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1EJupd12104; Wed, 14 Feb 2001 11:56:51 -0800 (PST) Received: from [10.0.1.16] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA25683; Wed, 14 Feb 2001 11:56:43 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3A8A333E.5DCEC31B@ehsco.com> References: <200102140600.BAA22945@astro.cs.utk.edu> <3A8A333E.5DCEC31B@ehsco.com> Date: Wed, 14 Feb 2001 20:52:04 +0100 To: "Eric A. Hall" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] The report from the design team Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 23.26 -0800 01-02-13, Eric A. Hall wrote: > > to put the question in a more practical light: if someone sends > > out mail with a return address that uses an IDN, is it acceptable > > if the recipient cannot reply to that message unless his mail > > reader and the chain of SMTPs between him and the original sender > > support IDNs? > >The end-user still has to upgrade the MUA to use ACE. If he doesn't, then >at least one of the SMTP servers will have to do the work (assuming they >accept an unconverted IDN from the MUA in the first place) whenever the >user clicks on the internationalized mailto: link. I think Keith said "reply to an email", and I think that is the level of backward functionality which is really essential. I.e. one reason why I wrote the IDNA proposal was exactly this scenario: User A have an IDN capable email client, and he uses an email address in a domainname which is an "IDN"-domain. He sends an email with this email address as From address. The recipient B have a client and/or server (or even a system which is behind a gateway, like lotus notes, first class or X.400) which receives the message. Now, B want to reply to the message. I want that to work, regardless of how the From address look like on the screen. Because of this, B having non-IDN software, IDNA is needed. Also, B can still add the From-address to his address book in his email client (the domainname still looks weird as the ACE is not decoded). Broken as the ACE is not decoded -- yes -- but it is possible for A and B to continue to exchange email. Patrik From owner-idn@ops.ietf.org Thu Feb 15 04:46:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11993 for ; Thu, 15 Feb 2001 04:46:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TKPK-000PD8-00 for idn-data@psg.com; Thu, 15 Feb 2001 01:08:58 -0800 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.16 #1) id 14TKPJ-000PD2-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 01:08:57 -0800 Received: (from tale@localhost) by gro.dd.org (8.9.0/8.8.5) id EAA02244; Thu, 15 Feb 2001 04:08:55 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14987.40102.939106.442157@gro.dd.org> Date: Thu, 15 Feb 2001 04:08:54 -0500 (EST) From: tale@nominum.com (David C Lawrence) To: idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-Reply-To: <200102031019.f13AJk417244@malmo.trab.se> References: <200102031019.f13AJk417244@malmo.trab.se> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan writes: > If I look at how I would like things to work, if could be like this: > > user enters name in application using LOCAL character set. > -> > application calls routnes like: gethostbyname > -> > gethostbyname converts form LOCAL character set to > normalised (not namepreped) UTF-8 (or other format). > it may reject the query if the name contains forbidden characters. > and sends the query to DNS server. How does gethostbyname() know for sure what the character set of its argument is? From owner-idn@ops.ietf.org Thu Feb 15 08:20:25 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14800 for ; Thu, 15 Feb 2001 08:20:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TO1F-0002AQ-00 for idn-data@psg.com; Thu, 15 Feb 2001 05:00:21 -0800 Received: from asadal.cs.pusan.ac.kr ([164.125.164.185]) by psg.com with esmtp (Exim 3.16 #1) id 14TO1E-0002AJ-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 05:00:20 -0800 Received: from localhost (gimgs@localhost) by asadal.cs.pusan.ac.kr (8.8.8+Sun/8.8.8) with ESMTP id VAA03765; Thu, 15 Feb 2001 21:57:06 +0900 (KST) Date: Thu, 15 Feb 2001 21:57:05 +0900 (KST) From: =?euc-kr?Q?=B1=E8=5F=B0=E6=BC=AE-GIM=5FGyeongseog?= To: David C Lawrence cc: idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-Reply-To: <14987.40102.939106.442157@gro.dd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=euc-kr Content-Transfer-Encoding: 8BIT Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Thu, 15 Feb 2001, David C Lawrence wrote: > Dan writes: > > If I look at how I would like things to work, if could be like this: > > > > user enters name in application using LOCAL character set. > > -> > > application calls routnes like: gethostbyname > > -> > > gethostbyname converts form LOCAL character set to > > normalised (not namepreped) UTF-8 (or other format). > > it may reject the query if the name contains forbidden characters. > > and sends the query to DNS server. > > How does gethostbyname() know for sure what the character set of its > argument is? i guess that gethostbyname need be extended so that one additional param indicates the local char set. 漮, λ ǻ к; KIM Kyongsok/GIM Gyeongseog, Busan National Univ. gimgs@HANGEUL.cs.pusan.ac.kr, http://HANGEUL.cs.pusan.ac.kr/hangeul/ Ph: (051) 510-2292, Fax: (051) 515-2208 From owner-idn@ops.ietf.org Thu Feb 15 14:33:42 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28431 for ; Thu, 15 Feb 2001 14:33:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TTfP-000KRy-00 for idn-data@psg.com; Thu, 15 Feb 2001 11:02:11 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14TTfO-000KRs-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 11:02:10 -0800 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17084 for ; Thu, 15 Feb 2001 11:02:06 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 15 Feb 2001 11:02:00 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] The layers and character handling in DNS Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 9:57 PM +0900 2/15/01, _ʺ-GIM_Gyeongseog wrote: >On Thu, 15 Feb 2001, David C Lawrence wrote: > >> Dan writes: >> > If I look at how I would like things to work, if could be like this: >> > >> > user enters name in application using LOCAL character set. >> > -> >> > application calls routnes like: gethostbyname >> > -> >> > gethostbyname converts form LOCAL character set to >> > normalised (not namepreped) UTF-8 (or other format). >> > it may reject the query if the name contains forbidden characters. >> > and sends the query to DNS server. >> >> How does gethostbyname() know for sure what the character set of its >> argument is? > >i guess that gethostbyname need be extended so that one additional >param indicates the local char set. And, with that information, gethostbyname then needs to translate completely correctly and authoritatively from that charset to UTF8 (or at least to ISO/IEC 10646 code points). For this scheme to work, we need to have authoritative and non-changing mapping tables for every local charset. Even is this was possible (and it's not; see below), the software would be huge. Those of us who have just the easy Latin characters in our names keep forgetting that many of the local charsets in the rest of the world don't have the mapping tables needed, and won't have them any time soon. There is wide dispute about what the mappings should be, and even the organizations that have spent the time doing mappings *still* are changing them. Part of this is due to the way that ISO/IEC 10646 is designed, so it is likely that this issue will not be resolved for decades, if ever. Please, folks: this is a dead end. If you want to keep going down this path, maybe preface each message you write with "In an idealized universe where there was authoritative and non-changing mapping tables for every local charset, ...". --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Feb 15 14:49:54 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28739 for ; Thu, 15 Feb 2001 14:49:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TU7B-000L1i-00 for idn-data@psg.com; Thu, 15 Feb 2001 11:30:53 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14TU7A-000L0p-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 11:30:52 -0800 Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id TAA26929; Thu, 15 Feb 2001 19:26:23 GMT From: "Brian W. Spolarich" To: "Paul Hoffman / IMC" , Subject: RE: [idn] The layers and character handling in DNS Date: Thu, 15 Feb 2001 14:31:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Please, folks: this is a dead end. If you want to keep going down > this path, maybe preface each message you write with "In an idealized > universe where there was authoritative and non-changing mapping > tables for every local charset, ...". Paul, I'm not sure I see this as anything other than the result of trying to extend the codepage-based world beyond its useful boundaries. Isn't this what Unicode-ISO/IEC 10646-1 is all about? Using data in a codepage-based CES outside of that environment is going to yield mixed results at best, and very poor results in some contexts. This should encourage users to migrate to Unicode-based systems and increase pressure on software vendors to implement and improve such support in their systems. Or am I being naive? -bws From owner-idn@ops.ietf.org Thu Feb 15 15:06:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28946 for ; Thu, 15 Feb 2001 15:06:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TUSJ-0003Ea-00 for idn-data@psg.com; Thu, 15 Feb 2001 11:52:43 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14TUSH-0003DJ-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 11:52:42 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA23798; Thu, 15 Feb 2001 14:52:31 -0500 (EST) Message-Id: <200102151952.OAA23798@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Hoffman / IMC cc: idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-reply-to: Your message of "Thu, 15 Feb 2001 11:02:00 PST." Date: Thu, 15 Feb 2001 14:52:31 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk so what you're saying is that, at least in some parts of the world, folks won't be able to use IDNs until they upgrade their platforms to support Unicode? Keith From owner-idn@ops.ietf.org Thu Feb 15 15:17:10 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29092 for ; Thu, 15 Feb 2001 15:17:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TUW0-0004Bg-00 for idn-data@psg.com; Thu, 15 Feb 2001 11:56:32 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14TUVz-0004BU-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 11:56:31 -0800 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA20360; Thu, 15 Feb 2001 11:56:19 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200102151952.OAA23798@astro.cs.utk.edu> References: <200102151952.OAA23798@astro.cs.utk.edu> Date: Thu, 15 Feb 2001 11:56:13 -0800 To: Keith Moore From: Paul Hoffman / IMC Subject: Re: [idn] The layers and character handling in DNS Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 2:52 PM -0500 2/15/01, Keith Moore wrote: >so what you're saying is that, at least in some parts of the world, >folks won't be able to use IDNs until they upgrade their platforms >to support Unicode? No, not at all. "Platforms" don't need to support "Unicode"; applications need to support IDN. The IDN protocol we are working on has parts of The Unicode Standard in it. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Feb 15 15:24:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29211 for ; Thu, 15 Feb 2001 15:24:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TUhZ-000CAU-00 for idn-data@psg.com; Thu, 15 Feb 2001 12:08:29 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14TUhX-000C8r-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 12:08:27 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA24004; Thu, 15 Feb 2001 15:08:22 -0500 (EST) Message-Id: <200102152008.PAA24004@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Hoffman / IMC cc: Keith Moore , idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-reply-to: Your message of "Thu, 15 Feb 2001 11:56:13 PST." Date: Thu, 15 Feb 2001 15:08:22 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > >so what you're saying is that, at least in some parts of the world, > >folks won't be able to use IDNs until they upgrade their platforms > >to support Unicode? > > No, not at all. "Platforms" don't need to support "Unicode"; > applications need to support IDN. The IDN protocol we are working on > has parts of The Unicode Standard in it. I might believe that you can *display* IDNs independent of platform support for Unicode, at least, if you have a pixel-addressable display of sufficient resolution, and sufficient storage for Unicode fonts. whether you can effectively *input* IDNs without platform support for Unicode is a different question. Keith From owner-idn@ops.ietf.org Thu Feb 15 15:53:00 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29721 for ; Thu, 15 Feb 2001 15:52:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TV5n-000NQb-00 for idn-data@psg.com; Thu, 15 Feb 2001 12:33:31 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14TV5m-000NQU-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 12:33:30 -0800 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22412; Thu, 15 Feb 2001 12:33:23 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200102152008.PAA24004@astro.cs.utk.edu> References: <200102152008.PAA24004@astro.cs.utk.edu> Date: Thu, 15 Feb 2001 12:33:18 -0800 To: Keith Moore From: Paul Hoffman / IMC Subject: Re: [idn] The layers and character handling in DNS Cc: Keith Moore , idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:08 PM -0500 2/15/01, Keith Moore wrote: >whether you can effectively *input* IDNs without platform support for Unicode >is a different question. Correct. Most "platforms" have support for some character sets, each of which is a subset of the Unicode (ISO/IEC 10646) character repertoire. Because of this, the input mechanism can be used with IDN. The "platform" decides the mapping between the character sets and Unicode. The difference here and where this thread was going is that the mapping is done by the application (probably through "the platform"), *not* by the protocol itself. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Feb 15 17:45:44 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01873 for ; Thu, 15 Feb 2001 17:45:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TWsV-000AHw-00 for idn-data@psg.com; Thu, 15 Feb 2001 14:27:55 -0800 Received: from dt0b4n5b.maine.rr.com ([24.95.12.91] helo=nic-naa.net) by psg.com with esmtp (Exim 3.16 #1) id 14TWsU-000AHp-00 for idn@ops.ietf.org; Thu, 15 Feb 2001 14:27:54 -0800 Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.1/8.9.3) with ESMTP id f1FMQvC34899; Thu, 15 Feb 2001 17:26:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200102152226.f1FMQvC34899@nic-naa.net> To: Paul Hoffman / IMC cc: idn@ops.ietf.org, brunner@nic-naa.net Subject: Re: [idn] The layers and character handling in DNS In-Reply-To: Your message of "Thu, 15 Feb 2001 11:02:00 PST." Date: Thu, 15 Feb 2001 17:26:57 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-idn@ops.ietf.org Precedence: bulk Paul, Is this a real requirement? > we need to have authoritative and non-changing mapping tables for > every local charset If real, is it strengthened or weakened by removing the word "mapping"? I only ask because my experience at Sun and HP, and my peers at IBM and elsewhere confirm, that historically vendors "cherry picked", going for ROI (unit sales), prior to any code-set independent (or dependent if one views the ASCII -> UTF8 substitution as just a code-set substitution) i18n deployment. Vendor, Consortia, and National "authoritative" tables were the norm, and were frequently modified. I'm asking about cherry picking on tables. Next, or to be confusing and go to your comment, with "mapping on", previously, I only ask because the resolver supplied by the Chinese Domain Name System (CDNS) discussed by Wenhui Zhang (let me know if you haven't seen this mail, I thought it went to idn and provreg), does convert GBK and Big5 encodings to UTF8. I assume something useful (for some definition of utility) happens in some other CDNS supplied service. I'm asking about cherry picking on mappings. If economically rational behavior is changed, then my prior experience with cherry picking in the non-ASCII host system software market is a limited guide. Broadly, my question is "impossibility" relevant? Is the only alternative to one path the one characterized as: "In an idealized universe where there was authoritative and non-changing mapping tables for every local charset, ..." I don't mind looking funny, idealized universii and formal reasoning are run-of-the-mill for people who enjoy maths, but I'm puzzled by a course so radically different from the historical provisioning of post-EBCDIC writing system support, which has most of the CJ (I'm dead ignorant on K) host market exchanging data like mad, with most traffic in a few encodings. Incidently, until UCAS [1] went PDAM, about the time I started working on i18n, my non-latin writing system didn't even have a prevailing encoding. Thanks for your thoughts Paul, kitakitamatsino (or U+15BD U+1455 U+15BD U+1455 U+14AA U+165F U+14C4) Eric [1] Dirk Vermeulen's work http://www.egt.ie/standards/sl/n1441-en.html From owner-idn@ops.ietf.org Fri Feb 16 06:14:33 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26169 for ; Fri, 16 Feb 2001 06:14:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TiOC-0002JR-00 for idn-data@psg.com; Fri, 16 Feb 2001 02:45:24 -0800 From: =?gb2312?q?xiang=20deng?= Subject: [idn] Re: Query: GBK, Big5, and UTF8 encodings To: idn@ops.ietf.org Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 16 Feb 2001 02:45:24 -0800 Mr. Eric Brunner: Sorry for not response sooner.And I'll answer your questions one by one. > I just received your 2nd note. Names encoded in GBK or Big5 (locale dependent > encodings) are converted to UTF8 in the resolver library, and CNNIC's name > servers support UTF8. Is this correct? > The processing of user's requirement: Application <--> resolver <--> code_switcher <--> cdns | local encoding -> UTF8 > Is my understanding correct: > > CNNIC provides (or will soon provide) a dns resolver library > for download which supports domain names encoded in GBK, Big5, > and UTF8? > No.The dns resolver do not change the requirement but to send it in standard format. We have a downloadable client which support local encoding,but the objective of providing the client is to find way to resolve some problems caused by browser and firewalls. > and > > CNNIC has deployed (or will soon deploy) a version of bind which > supports resolution of utf8 encoded names? The implementation has been finished and will be improved in future and the registration service has been provided. > > Please correct each of my statements. > > Also, please list the host operating systems for which the downloadable > gbk/big5/utf8 resolver library will be available, and please also list > the nameservers for which utf8 support is available. > please visit www.cnnic.net.cn and download the client used in windows system.Welcome to test it in chinese domain name. Your requirement may be sent to 159.226.6.186 ,this server will response what you query. > > Are my following additional understandings correct? > > Additionally, sort of a feature, ".cn" (and possibly other top-level domains) > may also be represented in GBK and Big5 (and utf8), as "middle country"? Is > this also correct? If so, what are the code points for zhung guo? Services includes: "chinese-domain-name.cn" "chinese-domain-name.й" The code point of zhong guo "й" is: zhong "" in GB18030 : 0xD6D0 in UNCODE : 0x4F2D guo "" in GB18030 : 0xB9FA in UNCODE : 0x56FD > > Also, sort of a feature, relative names are resolved by default to fully > qualified domain names within the .cn hierarchy? Is this also correct? > The resolving of ".cn" domain name abides by the standard mode.The only different point is that dns server allows 8-bit domain name through. Best regards to you. deng xiang 2001.2.16 _________________________________________________________ Do You Yahoo!? ¼Ż! http://mail.yahoo.com.cn ŻֲҸԾʩչhttp://cn.clubs.yahoo.com From owner-idn@ops.ietf.org Fri Feb 16 16:59:20 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10419 for ; Fri, 16 Feb 2001 16:59:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TsSY-0002YZ-00 for idn-data@psg.com; Fri, 16 Feb 2001 13:30:34 -0800 Received: from [216.168.233.95] (helo=heron.verisign.com) by psg.com with esmtp (Exim 3.16 #1) id 14TsSX-0002Y1-00 for idn@ops.ietf.org; Fri, 16 Feb 2001 13:30:33 -0800 Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA00608 for ; Fri, 16 Feb 2001 16:30:01 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9G5L>; Fri, 16 Feb 2001 16:24:33 -0500 Message-ID: From: "Hollenbeck, Scott" To: idn@ops.ietf.org Subject: [idn] nameprep-02 Unassigned Code Point Typo? Date: Fri, 16 Feb 2001 16:24:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk I think there's a small but significant typo in the table of unassigned code points found in nameprep-02 Appendix G. The table currently lists this range: FDC8-FDCF but the actual unassigned code points per Unicode 3.0/3.0.1 run from FDC8-FDEF. From owner-idn@ops.ietf.org Fri Feb 16 18:37:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11791 for ; Fri, 16 Feb 2001 18:37:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TuAw-00047S-00 for idn-data@psg.com; Fri, 16 Feb 2001 15:20:30 -0800 Received: from tnt.isi.edu ([128.9.128.128]) by psg.com with esmtp (Exim 3.16 #1) id 14TuAv-00047L-00 for idn@ops.ietf.org; Fri, 16 Feb 2001 15:20:30 -0800 Received: from gin.isi.edu (gin.isi.edu [128.9.160.70]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1GNKSs26942; Fri, 16 Feb 2001 15:20:28 -0800 (PST) From: Zita Wenzel Received: (from zita@localhost) by gin.isi.edu (8.8.7/8.8.6) id XAA12859; Fri, 16 Feb 2001 23:20:28 GMT Date: Fri, 16 Feb 2001 23:20:28 GMT Message-Id: <200102162320.XAA12859@gin.isi.edu> To: ehall@ehsco.com, James@Seng.cc Subject: Re: [idn] Requirements Document Cc: idn@ops.ietf.org, zita@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Hi, As James said, we are the editors. Please send suggestions for specific wording changes to the IDN requirements document to the list. Note that the current version is draft-ietf-idn-requirements-04.txt. Thanks, Zita > Before this discussion goes further, please put your specific changes to > the requirements with the proposed new wordings here. Thanks! > > -James Seng > From owner-idn@ops.ietf.org Fri Feb 16 19:25:38 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12156 for ; Fri, 16 Feb 2001 19:25:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14TuyI-0005CT-00 for idn-data@psg.com; Fri, 16 Feb 2001 16:11:30 -0800 Received: from above.proper.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14TuyI-0005CN-00 for idn@ops.ietf.org; Fri, 16 Feb 2001 16:11:30 -0800 Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05889; Fri, 16 Feb 2001 16:11:24 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Fri, 16 Feb 2001 16:11:14 -0800 To: "Hollenbeck, Scott" , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] nameprep-02 Unassigned Code Point Typo? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 4:24 PM -0500 2/16/01, Hollenbeck, Scott wrote: >I think there's a small but significant typo in the table of unassigned code >points found in nameprep-02 Appendix G. The table currently lists this >range: > >FDC8-FDCF > >but the actual unassigned code points per Unicode 3.0/3.0.1 run from >FDC8-FDEF. Whoops, that's correct. That was a versioning mistake on my part. FDD0-FDEF are currently unassigned, but will become assigned as noncharacter code points in Unicode 3.1. (See , section 3, Noncharacters, update to D7b.) This will be corrected in the next version of nameprep. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Feb 17 09:48:33 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04575 for ; Sat, 17 Feb 2001 09:48:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14U8Ls-000N1L-00 for idn-data@psg.com; Sat, 17 Feb 2001 06:28:44 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14U8Lr-000N1E-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 06:28:43 -0800 Received: from terra (terra.malmo.trab.se [131.115.48.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f1HESd406639; Sat, 17 Feb 2001 15:28:39 +0100 (MET) Message-Id: <200102171428.f1HESd406639@malmo.trab.se> Date: Sat, 17 Feb 2001 15:27:23 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] The layers and character handling in DNS To: idn@ops.ietf.org, tale@nominum.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ExSffXwV+9P2ddyYrRiGig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >Dan writes: >> If I look at how I would like things to work, if could be like this: >> >> user enters name in application using LOCAL character set. >> -> >> application calls routnes like: gethostbyname >> -> >> gethostbyname converts form LOCAL character set to >> normalised (not namepreped) UTF-8 (or other format). >> it may reject the query if the name contains forbidden characters. >> and sends the query to DNS server. > >How does gethostbyname() know for sure what the character set of its >argument is? In Unix from the current locale. Paul said that this thread was having the mapping by the protocol. This is not so, the protocol uses UCS, it is the API used by the application that should map between the protocol format and local format. The APIs for accessing DNS should not return protocol format, it should return the native format used in applications. It is the same for the API for LDAPv3. The LDAP protocol uses UTF-8, but the strings returned by the calls should do the mapping for the application. Dan From owner-idn@ops.ietf.org Sat Feb 17 12:49:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05812 for ; Sat, 17 Feb 2001 12:49:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UBJh-000Pbe-00 for idn-data@psg.com; Sat, 17 Feb 2001 09:38:41 -0800 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.16 #1) id 14UBJg-000PbY-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 09:38:40 -0800 Received: (from tale@localhost) by gro.dd.org (8.9.0/8.8.5) id MAA27068; Sat, 17 Feb 2001 12:38:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14990.46877.693071.526704@gro.dd.org> Date: Sat, 17 Feb 2001 12:38:37 -0500 (EST) From: tale@nominum.com (David C Lawrence) To: idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-Reply-To: <200102171428.f1HESd406639@malmo.trab.se> References: <200102171428.f1HESd406639@malmo.trab.se> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >How does gethostbyname() know for sure what the character set of its > >argument is? > > In Unix from the current locale. This is not reliable, certainly not in the already deployed software, which is what you are trying to accomodate by not changing the API. How does gethostbyname() *know for sure* what the character set of its argument is? Answer: it doesn't, because there is no way that it can. From owner-idn@ops.ietf.org Sat Feb 17 13:24:22 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06090 for ; Sat, 17 Feb 2001 13:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UBoG-000079-00 for idn-data@psg.com; Sat, 17 Feb 2001 10:10:16 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14UBoD-000073-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 10:10:15 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA29270; Sat, 17 Feb 2001 13:10:07 -0500 (EST) Message-Id: <200102171810.NAA29270@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: tale@nominum.com (David C Lawrence) cc: idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-reply-to: Your message of "Sat, 17 Feb 2001 12:38:37 EST." <14990.46877.693071.526704@gro.dd.org> Date: Sat, 17 Feb 2001 13:10:06 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > How does gethostbyname() *know for sure* what the character set of its > argument is? Answer: it doesn't, because there is no way that it can. Let me suggest a different answer: gethostbyname() knows what the character set of the argument is because, by definition, it is ASCII. it's a bad idea to try to change this, because if you do, you break one of the assumptions on which code that uses gethostbyname was written. you also create new failure modes which existing code does not anticipate. (as another example - when the ctype macros/functions were made locale-specific, it broke code that was using them to try to parse protocol elements that required ASCII. ) if you want an interface to look up addresses from IDNs - whether it be in native format, UTF-8, or whatever - you need a different function. don't overload gethostbyname. but don't try to retroactively change an existing interface. Keith From owner-idn@ops.ietf.org Sat Feb 17 20:00:00 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08995 for ; Sat, 17 Feb 2001 20:00:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UHrt-0006wb-00 for idn-data@psg.com; Sat, 17 Feb 2001 16:38:25 -0800 Received: from nordic.cisco.com ([144.254.116.47] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14UHrs-0006vr-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 16:38:24 -0800 Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA23729; Sun, 18 Feb 2001 01:37:13 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com (Unverified) Message-Id: In-Reply-To: <200102171810.NAA29270@astro.cs.utk.edu> References: <200102171810.NAA29270@astro.cs.utk.edu> Date: Sat, 17 Feb 2001 16:35:12 -0800 To: Keith Moore , tale@nominum.com (David C Lawrence) From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] The layers and character handling in DNS Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 13.10 -0500 01-02-17, Keith Moore wrote: > > How does gethostbyname() *know for sure* what the character set of its >> argument is? Answer: it doesn't, because there is no way that it can. > >Let me suggest a different answer: > >gethostbyname() knows what the character set of the argument is >because, by definition, it is ASCII. FYI: In the IDNA algorithm, nameprep and ace encoding is done _before_ gethostbyname() is called, for exactly the reasons Keith lists. paf From owner-idn@ops.ietf.org Sat Feb 17 22:02:52 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10536 for ; Sat, 17 Feb 2001 22:02:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UJtv-000904-00 for idn-data@psg.com; Sat, 17 Feb 2001 18:48:39 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14UJtu-0008zx-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 18:48:38 -0800 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f1I30id54162 for ; Sat, 17 Feb 2001 22:00:44 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010217213928.02bb0fa0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 21:44:44 -0500 To: idn@ops.ietf.org From: Marc Blanchet Subject: [idn] next ietf Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Some notes about the next IETF meeting: Tentative idn wg time (may change: see http://www.ietf.org/meetings/agenda_50.txt): WEDNESDAY, March 21, 2001 1300-1500 Afternoon Sessions I INT idn Internationalized Domain Name WG THURSDAY, March 22, 2001 1300-1500 Afternoon Sessions I INT idn Internationalized Domain Name WG Internet-draft cutoff dates (http://www.ietf.org/meetings/cutoff_dates_50.html): February 23 - Internet Draft Cut-off for initial document (-00) submission at 17:00 ET March 2 - Internet Draft final submission cutoff date at 1700 ET idn wg agenda: People who would like to present something during the next idn meeting should send their request using this template to the wg co-chairs (Marc.Blanchet@viagenie.qc.ca,jseng@pobox.org.sg): title: name: document (i.e. draft name): requested time: Thanks, Marc. Marc Blanchet Viagnie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From owner-idn@ops.ietf.org Sun Feb 18 00:43:07 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12886 for ; Sun, 18 Feb 2001 00:43:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UM8m-000BW7-00 for idn-data@psg.com; Sat, 17 Feb 2001 21:12:08 -0800 Received: from beatrice.rutgers.edu ([165.230.209.226] ident=[UCEz/gbIS8jYMmR9SWgJy9QoQ0pISAok]) by psg.com with esmtp (Exim 3.16 #1) id 14UM8i-000BVy-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 21:12:04 -0800 Received: from puck2.rutgers.edu (sendmail@puck2.rutgers.edu [165.230.209.234]) by beatrice.rutgers.edu (8.9.3/8.9.3) with ESMTP id AAA13118; Sun, 18 Feb 2001 00:12:30 -0500 (EST) Received: (from easmith@localhost) by puck2.rutgers.edu (8.11.2/8.11.2) id f1I5CSU26675; Sun, 18 Feb 2001 00:12:28 -0500 (EST) From: "Allen Smith" Message-Id: <10102180012.ZM26658@puck2.rutgers.edu> Date: Sun, 18 Feb 2001 00:12:28 -0500 In-Reply-To: Marc Blanchet "[idn] W.G. Last Call on "Requirements of Internationalized Domain Names"" (Feb 13, 9:47am) References: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Marc Blanchet , idn@ops.ietf.org Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk On Feb 13, 9:47am, Marc Blanchet wrote: > This is a idn working group last call for comments on advancing the > following document as a Informational RFC: > > Title : Requirements of Internationalized Domain Names > Author(s) : Editors Zita Wenzel, James Seng > Filename : > http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-04.txt > > Please send substantive comments to the idn mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on February 28th, 2001. I see a problem with the following section: >[2.6] The protocol MUST work for all features of DNS, IPv4, and >IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor >that requests the IP-to-(old)-domain-name mapping service. It's _way_ too limited. It isn't just applications requesting hostnames from IP addresses that'll get broken if they get back a name containing characters that they don't expect (namely anything not allowed in RFC1123). It's an application asking for _any_ type of DNS record containing a hostname. I suggest considering the problems on UNIX, for instance, of a script that calls another program with a domain name that it got back from an MX request. What happens if that domain name has shell-active characters (redirection, etcetera)? Potential problems, up to and including security holes. Suggested rephrase: [2.6] The protocol MUST work for all features of DNS, IPv4, and IPv6. The protocol MUST NOT allow an IDN violating [RFC1034] and [RFC1123] to be returned to a requestor that does not request IDNs. This provision MUST be enforced by either nameservers or resolvers and SHOULD be enforced by both. -Allen -- Allen Smith easmith@beatrice.rutgers.edu From owner-idn@ops.ietf.org Sun Feb 18 01:20:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14800 for ; Sun, 18 Feb 2001 01:20:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UMxu-000CfF-00 for idn-data@psg.com; Sat, 17 Feb 2001 22:04:58 -0800 Received: from beatrice.rutgers.edu ([165.230.209.226] ident=[rObTUJs68BYfSYj6Rkh39PkrkGy1xWa9]) by psg.com with esmtp (Exim 3.16 #1) id 14UMxo-000Cf6-00 for idn@ops.ietf.org; Sat, 17 Feb 2001 22:04:53 -0800 Received: from puck2.rutgers.edu (sendmail@puck2.rutgers.edu [165.230.209.234]) by beatrice.rutgers.edu (8.9.3/8.9.3) with ESMTP id BAA13455; Sun, 18 Feb 2001 01:05:18 -0500 (EST) Received: (from easmith@localhost) by puck2.rutgers.edu (8.11.2/8.11.2) id f1I65IH27801; Sun, 18 Feb 2001 01:05:18 -0500 (EST) From: "Allen Smith" Message-Id: <10102180105.ZM27416@puck2.rutgers.edu> Date: Sun, 18 Feb 2001 01:05:17 -0500 In-Reply-To: "Allen Smith" "Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names"" (Feb 18, 12:55am) References: <5.0.2.1.1.20010213092504.02667748@mail.viagenie.qc.ca> <10102180012.ZM26658@puck2.rutgers.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Marc Blanchet , idn@ops.ietf.org Subject: Re: [idn] W.G. Last Call on "Requirements of Internationalized Domain Names" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk My apologies for replying to my own post, but I realized that people might not understand why I'm suggesting a limit to the full standards in RFC1123, including length et al. Buffer overflows. If one concludes that applications not allowing for this are broken anyway, one could use instead: [2.6] The protocol MUST work for all features of DNS, IPv4, and IPv6. The protocol MUST NOT allow an IDN with characters other than alphabet (A-Za-z), digits (0-9), minus sign (-), and period (.) to be returned to a requestor that does not request IDNs. This provision MUST be enforced by either nameservers or resolvers and SHOULD be enforced by both. This will allow for long domain names created by ACE. Thanks, -Allen -- Allen Smith easmith@beatrice.rutgers.edu From owner-idn@ops.ietf.org Sun Feb 18 07:56:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08531 for ; Sun, 18 Feb 2001 07:56:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14USzv-000JvP-00 for idn-data@psg.com; Sun, 18 Feb 2001 04:31:27 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14USzu-000JvJ-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 04:31:27 -0800 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f1IChad56127 for ; Sun, 18 Feb 2001 07:43:36 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010217223309.02a60cb8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 22:37:23 -0500 To: idn@ops.ietf.org From: Marc Blanchet Subject: Re: [idn] The layers and character handling in DNS In-Reply-To: References: <200102171810.NAA29270@astro.cs.utk.edu> <200102171810.NAA29270@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/ 16:35 2001-02-17 -0800, Patrik Fltstrm you wrote/vous criviez: >At 13.10 -0500 01-02-17, Keith Moore wrote: >> > How does gethostbyname() *know for sure* what the character set of its >>> argument is? Answer: it doesn't, because there is no way that it can. >> >>Let me suggest a different answer: >> >>gethostbyname() knows what the character set of the argument is >>because, by definition, it is ASCII. > >FYI: In the IDNA algorithm, nameprep and ace encoding is done _before_ >gethostbyname() is called, for exactly the reasons Keith lists. - One thing we also have to consider is the API (gethost*) have been redefined for ipv6 support, where the new api support both ipv4 and ipv6: RFC2553. IDN call should handle both old and new non-idn-aware-api. Marc. Marc Blanchet Viagnie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From owner-idn@ops.ietf.org Sun Feb 18 09:21:02 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09236 for ; Sun, 18 Feb 2001 09:21:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UUXA-000Li1-00 for idn-data@psg.com; Sun, 18 Feb 2001 06:09:52 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14UUX9-000Lhv-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 06:09:51 -0800 Received: from r2.jck.com ("port 1156"@[209.187.148.221]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTPA id <0G8Y0034SI09KE@a4.jck.com> for idn@ops.ietf.org; Sun, 18 Feb 2001 09:09:45 -0500 (EST) Date: Sun, 18 Feb 2001 09:09:44 -0500 From: John C Klensin Subject: Re: [idn] The layers and character handling in DNS In-reply-to: To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Message-id: <3234840912.982487384@r2.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.6 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, I think this leads to results that violate the law of least astonishment. Suppose I'm using local character code X to represent script Z and so is Keith. My local mapping is Unicode<-F1(X,Z) and Keith's is Unicode<-F2(X,Z), and they are different. Let's assume that each is consistently reversible (although that is another problem, both with this issue and, I suspect, with Nameprep). So I find an IDN domain on the network, and, by the time its name emerges from my application, it is in X, having been passed through F1'(Unicode,Z). I pass X to Keith out of band (e.g., in an email message with "text/plain; charset=X"). Now Keith looks it up, applying F2(X,Z) before Nameprep. And, behold, he either gets 'nodomain' or, worse, the wrong stuff. I think consistent behavior is important. And I don't see how one gets that without either native implementations of 10646 (i.e., no local character sets) or with standardized/ unambiguous mappings between each local set and 10646. Of course, we could try to make Nameprep complicated enough to smooth over all such details, s.t., Nameprep(F1(X,Z)))= Nameprep(F2(X,Z)) for all Fn. Seems unlikely somehow. john --On Thursday, 15 February, 2001 12:33 -0800 "Paul Hoffman / IMC" wrote: > At 3:08 PM -0500 2/15/01, Keith Moore wrote: >> whether you can effectively *input* IDNs without platform >> support for Unicode is a different question. > > Correct. Most "platforms" have support for some character sets, > each of which is a subset of the Unicode (ISO/IEC 10646) > character repertoire. Because of this, the input mechanism can > be used with IDN. The "platform" decides the mapping between > the character sets and Unicode. > > The difference here and where this thread was going is that the > mapping is done by the application (probably through "the > platform"), *not* by the protocol itself. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Sun Feb 18 11:09:09 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10344 for ; Sun, 18 Feb 2001 11:09:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UWAv-000NbV-00 for idn-data@psg.com; Sun, 18 Feb 2001 07:55:01 -0800 Received: from nordic.cisco.com ([144.254.116.47] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14UWAu-000NbG-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 07:55:01 -0800 Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA22621; Sun, 18 Feb 2001 16:52:36 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3234840912.982487384@r2.jck.com> References: <3234840912.982487384@r2.jck.com> Date: Sun, 18 Feb 2001 06:59:49 -0800 To: John C Klensin , Paul Hoffman / IMC From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] The layers and character handling in DNS Cc: idn@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 09.09 -0500 01-02-18, John C Klensin wrote: >Suppose I'm using local character code X to represent script Z >and so is Keith. My local mapping is Unicode<-F1(X,Z) and >Keith's is Unicode<-F2(X,Z), and they are different. Let's >assume that each is consistently reversible (although that is >another problem, both with this issue and, I suspect, with >Nameprep). Ok. >So I find an IDN domain on the network, and, by the time its name >emerges from my application, it is in X, having been passed >through F1'(Unicode,Z). I pass X to Keith out of band (e.g., in >an email message with "text/plain; charset=X"). I think you send "X" as data, where the charset is "Z". >Now Keith looks >it up, applying F2(X,Z) before Nameprep. And, behold, he either >gets 'nodomain' or, worse, the wrong stuff. This might happen. >I think consistent behavior is important. And I don't see how >one gets that without either native implementations of 10646 >(i.e., no local character sets) or with standardized/ unambiguous >mappings between each local set and 10646. > >Of course, we could try to make Nameprep complicated enough to >smooth over all such details, s.t., Nameprep(F1(X,Z)))= >Nameprep(F2(X,Z)) for all Fn. Seems unlikely somehow. The whole goal with the normalization which UTC has done is that the number of X and Fn which make Nameprep(F1(X,Z)) != Nameprep(Fn(X,Z)) is as small as possible. We can argue until we die how many of these X and n exists which break the pattern, and because of this, I think this discussion is mostly academic. BUT: I think the key message John has, which the IDN group have to be aware of is that the IDN wg seems to have made a choice that Unicode with the normalization rules which are defined by UTC (not IETF) is the absolutely best functions that can be found. Further, the problems brought up _will_ happen, and we in the IETF can only rely on UTC being smart enough to develop normalization tables and do good marketing to see that the number of Fn is relatively small for each X. Now, the big question which John doesn't ask explicitly is whether these mappings are good enough, and if the IDN wg is aware of the fact that it should have been able to say "no, too many Fn exists for too many X, so we don't belive these mappings are good enough". Personally, I have been thinking of this a lot the last 6-8 months, and my conclusion is: (1) The IETF is NOT a forum where we have the knowledge on making a decision whether a mapping function is good enough or not for characters. The only thing the IETF can do is to choose someone which works in this area and trust them doing an as good job as possible. UTC is doing a good job, but they have "bugs" and problems with their mapping tables (as anyone would have) and we in the IETF will inherit them -- for good and for bad. (2) Because of the issues John list, or even more important the fact that we (amateurs) in the IETF do already know that two code points in Unicode which are not normalized to the same value still look the same exists, the only way of solving the problem is to (a) have special normalization rules (not the UTC ones) in the IETF or (b) regardless of IDN try to push all applications to be aware of this issue so they start looking at dictionary approaches in places of the user interface where misunderstanding can happen. And (a) is NOT a path to take due to the argument in (1) above. So, consistent behaviour is something we will get only if F1 and Fn for the same X map to at least two code points which are normalized to the same in the nameprep phase -- and we in the IETF _have_ to rely on UTC for this. Eventual misunderstandings that can happen (or rather, WILL happen) because of non-normalization happening -- for example between latin, greek and cyrillic -- will not be solved by nameprep. Or else we should not do this at all. My personal opinion is that we SHOULD do this, but know about the limitations, and regardless of the IDN solution with nameprep understand that we need a dictionary _aswell_ because of the limitations that exists. paf > > john > > > >--On Thursday, 15 February, 2001 12:33 -0800 "Paul Hoffman / IMC" > wrote: > >> At 3:08 PM -0500 2/15/01, Keith Moore wrote: >>> whether you can effectively *input* IDNs without platform >>> support for Unicode is a different question. >> >> Correct. Most "platforms" have support for some character sets, >> each of which is a subset of the Unicode (ISO/IEC 10646) >> character repertoire. Because of this, the input mechanism can >> be used with IDN. The "platform" decides the mapping between >> the character sets and Unicode. >> >> The difference here and where this thread was going is that the >> mapping is done by the application (probably through "the >> platform"), *not* by the protocol itself. >> >> --Paul Hoffman, Director >> --Internet Mail Consortium >> -- Patrik Fltstrm Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-idn@ops.ietf.org Sun Feb 18 11:27:52 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10426 for ; Sun, 18 Feb 2001 11:27:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UWVr-000O8M-00 for idn-data@psg.com; Sun, 18 Feb 2001 08:16:39 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14UWVp-000O8G-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 08:16:38 -0800 Received: from r2.jck.com ("port 1246"@[209.187.148.221]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTPA id <0G8Y0036DNVNKE@a4.jck.com> for idn@ops.ietf.org; Sun, 18 Feb 2001 11:16:36 -0500 (EST) Date: Sun, 18 Feb 2001 11:16:35 -0500 From: John C Klensin Subject: Re: [idn] The layers and character handling in DNS In-reply-to: To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: idn@ops.ietf.org Message-id: <3242451662.982494995@r2.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.6 (Win32) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10426 --On Sunday, 18 February, 2001 06:59 -0800 Patrik Fltstrm wrote: >> So I find an IDN domain on the network, and, by the time its >> name emerges from my application, it is in X, having been >> passed through F1'(Unicode,Z). I pass X to Keith out of band >> (e.g., in an email message with "text/plain; charset=X"). > > I think you send "X" as data, where the charset is "Z". Yes, sorry -- typographical error. > The whole goal with the normalization which UTC has done is > that the number of X and Fn which make Nameprep(F1(X,Z)) != > Nameprep(Fn(X,Z)) is as small as possible. We can argue until > we die how many of these X and n exists which break the > pattern, and because of this, I think this discussion is mostly > academic. I wouldn't try to make a quantitative argument. However, I suggest that, if there are _any_ major "local" character sets that have ambiguous and/or non-reversible mappings to 10646, then we are in trouble with these sorts of algorithms. I would define "major" in terms of either the size or importance of the potential user group: if we are in trouble with Chinese, Japanese, Korean, or even with Latin-based alphabets with different composition rules in different interpretations/mappings, then I suggest that we are in big trouble indeed. > BUT: I think the key message John has, which the IDN group have > to be aware of is that the IDN wg seems to have made a choice > that Unicode with the normalization rules which are defined by > UTC (not IETF) is the absolutely best functions that can be > found. Further, the problems brought up _will_ happen, and we > in the IETF can only rely on UTC being smart enough to develop > normalization tables and do good marketing to see that the > number of Fn is relatively small for each X. I think this position works iff: (i) There are _zero_ nameprep mapping rules or discounted characters not specified in Unicode (and preferably ISO) standards. If we need a many-paged Nameprep document for any purpose other than to provide a stable version of a UTC spec --I consider it a problem if we need even that, but it is another, and arguably separate, problem-- then the "hope UTC gets it right" story fails. A single IETF-specific rule, whether for URIs, funny characters, or anything else, IMO kills this story and turns it all into an IETF problem. (ii) We have a really good versioning model so that someone applying Nameprep can know what rules to use. If NamePrep2001(string) != NamePrep2002(string) and one can't tell which one should be applied, I think that, long-term, the whole thing deteriorates badly. Given an obvious variation of the F1 != F2 argument, I suspect (but haven't worked through the cases to my satisfaction yet) that means that the relevant version information needs to be encoded in the names themselves. I.e., the real test is whether NamePrepN(F1(X,Z))=NamePrepM(F2(X,Z)) and whether M and N can be determined in all places in which it is relevant (which would be especially important if the equality doesn't apply --it won't, or one wouldn't need NamePrep versions-- and one needs to know which version to apply. > Now, the big question which John doesn't ask explicitly is > whether these mappings are good enough, and if the IDN wg is > aware of the fact that it should have been able to say "no, too > many Fn exists for too many X, so we don't belive these > mappings are good enough". Since I don't believe that, if things don't work, users will forgive us if we just say "don't blame us, it is UTC's problem" I tend to ask a higher-level question. And I'm getting increasingly dissatisfied with the answer I get. > Personally, I have been thinking of this a lot the last 6-8 > months, and my conclusion is: > > (1) The IETF is NOT a forum where we have the knowledge on > making a decision whether a mapping function is good enough or > not for characters. The only thing the IETF can do is to choose > someone which works in this area and trust them doing an as > good job as possible. UTC is doing a good job, but they have > "bugs" and problems with their mapping tables (as anyone would > have) and we in the IETF will inherit them -- for good and for > bad. Agreed. But that implies, as above, that we make _zero_ of our own rules. If the Nameprep document is more complex than "take the UTC rules and apply them" (perhaps in some specific order relative to other things that need doing), I think we are out of this space and into applying our own judgement... we I think we agree we should not do. > (2) Because of the issues John list, or even more important the > fact that we (amateurs) in the IETF do already know that two > code points in Unicode which are not normalized to the same > value still look the same exists, the only way of solving the > problem is to (a) have special normalization rules (not the UTC > ones) in the IETF or (b) regardless of IDN try to push all > applications to be aware of this issue so they start looking at > dictionary approaches in places of the user interface where > misunderstanding can happen. And (a) is NOT a path to take due > to the argument in (1) above. Indeed, that is the conclusion I keep reaching. > So, consistent behaviour is something we will get only if F1 > and Fn for the same X map to at least two code points which are > normalized to the same in the nameprep phase -- and we in the > IETF _have_ to rely on UTC for this. Eventual misunderstandings > that can happen (or rather, WILL happen) because of > non-normalization happening -- for example between latin, greek > and cyrillic -- will not be solved by nameprep. And the alternative, of course, is to move these issues into an environment in which the ambiguities are tolerable or can be passed back to the user. That isn't the DNS. > Or else we should not do this at all. > > My personal opinion is that we SHOULD do this, but know about > the limitations, and regardless of the IDN solution with > nameprep understand that we need a dictionary _aswell_ because > of the limitations that exists. And I've gotten a bit more pessimistic and --faced with approximate agreement on the facts and first-level conclusions-- am getting close to concluding that * we should _not_ do this at all * we should press forward with a directory approach as the only one likely to solve the problem. * we should ask ourselves whether, if a directory approach is needed anyway, it makes sense to add this much complexity to the DNS when the real work will need to be done at another level. And, coming back to the ongoing Last Call at a 10,000 meter level, if the Requirements document doesn't draw out these types of issues and at least point to the need for solutions or explicit decisions, it isn't, IMO, ready for publication. john From owner-idn@ops.ietf.org Sun Feb 18 11:52:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10521 for ; Sun, 18 Feb 2001 11:52:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UWsy-000Ok0-00 for idn-data@psg.com; Sun, 18 Feb 2001 08:40:32 -0800 Received: from nordic.cisco.com ([144.254.116.47] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14UWsx-000OiE-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 08:40:31 -0800 Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA25945; Sun, 18 Feb 2001 17:38:39 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3242451662.982494995@r2.jck.com> References: <3242451662.982494995@r2.jck.com> Date: Sun, 18 Feb 2001 08:30:20 -0800 To: John C Klensin From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] The layers and character handling in DNS Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11.16 -0500 01-02-18, John C Klensin wrote: > > > (1) The IETF is NOT a forum where we have the knowledge on >> making a decision whether a mapping function is good enough or >> not for characters. The only thing the IETF can do is to choose >> someone which works in this area and trust them doing an as >> good job as possible. UTC is doing a good job, but they have >> "bugs" and problems with their mapping tables (as anyone would >> have) and we in the IETF will inherit them -- for good and for >> bad. > >Agreed. But that implies, as above, that we make _zero_ of our >own rules. If the Nameprep document is more complex than "take >the UTC rules and apply them" (perhaps in some specific order >relative to other things that need doing), I think we are out of >this space and into applying our own judgement... we I think we >agree we should not do. I agree with this in principle, BUT, we need still some extra text. This because we might want to - prohibit some code points as part of a label (compare with the problems with having no definition of what is a hostname compared with definition in DNS protocol to be able to handle decimal values of 0-255 (inclusive) as part of a label). - specify what should happen with non-assigned characters (which solves the versioning problem). - specify in what order case folding, normalization etc should happen. paf From owner-idn@ops.ietf.org Sun Feb 18 12:32:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10749 for ; Sun, 18 Feb 2001 12:32:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UXL1-000PXg-00 for idn-data@psg.com; Sun, 18 Feb 2001 09:09:31 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14UXL0-000PXZ-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 09:09:30 -0800 Received: from r2.jck.com ("port 1268"@[209.187.148.221]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTPA id <0G8Y00373QBSKE@a4.jck.com> for idn@ops.ietf.org; Sun, 18 Feb 2001 12:09:29 -0500 (EST) Date: Sun, 18 Feb 2001 12:09:27 -0500 From: John C Klensin Subject: Re: [idn] The layers and character handling in DNS In-reply-to: To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: idn@ops.ietf.org Message-id: <3245624212.982498167@r2.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.6 (Win32) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10749 --On Sunday, 18 February, 2001 08:30 -0800 Patrik Fltstrm wrote: >> Agreed. But that implies, as above, that we make _zero_ of our >> own rules. If the Nameprep document is more complex than "take >> the UTC rules and apply them" (perhaps in some specific order >> relative to other things that need doing), I think we are out >> of this space and into applying our own judgement... we I >> think we agree we should not do. > > I agree with this in principle, BUT, we need still some extra > text. > > This because we might want to > > - prohibit some code points as part of a label (compare with > the problems with having no definition of what is a hostname > compared with definition in DNS protocol to be able to handle > decimal values of 0-255 (inclusive) as part of a label). I think this takes us well out on a slippery slope. And much further out if the rules/ prohibitions are not _extremely_ short and simple. > - specify what should happen with non-assigned characters > (which solves the versioning problem). Solves the versioning problem iff you believe that we will get it exactly right, for all currently-assigned characters, the first time. Watching the Nameprep discussions over the last few months does not lead me to be optimistic about this. > - specify in what order case folding, normalization etc should > happen. Yes, this I agree with. But this one can be done as a few simple rules or not at all. And we had better be able to enumerate "etc" and not need to add anything to that list in the future, or we will have another versioning problem. john From owner-idn@ops.ietf.org Sun Feb 18 12:44:14 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10801 for ; Sun, 18 Feb 2001 12:44:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UXgS-0000CZ-00 for idn-data@psg.com; Sun, 18 Feb 2001 09:31:40 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14UXgQ-0000CL-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 09:31:38 -0800 Received: (qmail 20990 invoked by uid 1001); 18 Feb 2001 17:31:59 -0000 Date: 18 Feb 2001 17:31:58 -0000 Message-ID: <20010218173158.21255.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS References: <14990.46877.693071.526704@gro.dd.org> <200102171810.NAA29270@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Keith Moore writes: [ extending gethostbyname() to allow UTF-8 ] > new failure modes Namely? Give us the details, Keith. > but don't try to retroactively change an existing interface. Don't be an idiot. There are some interfaces that we _want_ to extend. Sysadmins want to type non-ASCII characters when they're editing zone files, for example, and users want to be able to type those non-ASCII characters on the ssh command line. If we can support these extensions at low cost by extending some other interfaces too, great! ---Dan From owner-idn@ops.ietf.org Mon Feb 19 01:24:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18645 for ; Mon, 19 Feb 2001 01:24:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Uj8a-000Fef-00 for idn-data@psg.com; Sun, 18 Feb 2001 21:45:28 -0800 Received: from nordic.cisco.com ([144.254.116.47] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14Uj8Z-000FdU-00 for idn@ops.ietf.org; Sun, 18 Feb 2001 21:45:27 -0800 Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id GAA26799; Mon, 19 Feb 2001 06:43:31 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3245624212.982498167@r2.jck.com> References: <3245624212.982498167@r2.jck.com> Date: Sun, 18 Feb 2001 21:28:18 -0800 To: John C Klensin From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] The layers and character handling in DNS Cc: idn@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 12.09 -0500 01-02-18, John C Klensin wrote: >--On Sunday, 18 February, 2001 08:30 -0800 Patrik Fltstrm > wrote: > > > > - prohibit some code points as part of a label (compare with >> the problems with having no definition of what is a hostname >> compared with definition in DNS protocol to be able to handle >> decimal values of 0-255 (inclusive) as part of a label). > >I think this takes us well out on a slippery slope. And much >further out if the rules/ prohibitions are not _extremely_ short >and simple. Yes, it is a slippery slope, but we already do the same thing when we use only ASCII in protocols. Now when having many more characters to pick from, we have to do the same kind of selection. I don't see how we suddenly can _not_ do it, and for example allow '/' (ascii slash) as a character which is allowed. I.e. we have to at least have the same ascii characters still being forbidden in textual based protocols in applications as we have today. > > - specify what should happen with non-assigned characters >> (which solves the versioning problem). > >Solves the versioning problem iff you believe that we will get it >exactly right, for all currently-assigned characters, the first >time. Watching the Nameprep discussions over the last few >months does not lead me to be optimistic about this. Two different issues: (a) UTC claims that assigned code points will not change. So, we either have to trust them or not. Yes, this is strong wording, but it was intentional. (b) People in IETF don't understand that the IETF do _NOT_ do normalization. My job as liason (and some others) is to see that the IETF does not do anything which where we instead reference UTC. So, some people bring up "bugs"/"issues" or whatever we should call what is brought up on the mailing list. I will strongly oppose personally to any such mappings/fixes ending in any document from the IDN wg. > > - specify in what order case folding, normalization etc should >> happen. > >Yes, this I agree with. But this one can be done as a few simple >rules or not at all. And we had better be able to enumerate >"etc" and not need to add anything to that list in the future, or >we will have another versioning problem. Yes. I agree. paf From owner-idn@ops.ietf.org Mon Feb 19 11:09:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07724 for ; Mon, 19 Feb 2001 11:09:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14UsVC-000OYq-00 for idn-data@psg.com; Mon, 19 Feb 2001 07:45:26 -0800 Received: from dokka.maxware.no ([195.139.236.69]) by psg.com with esmtp (Exim 3.16 #1) id 14UsVB-000OYk-00 for idn@ops.ietf.org; Mon, 19 Feb 2001 07:45:25 -0800 Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id QAA25043; Mon, 19 Feb 2001 16:45:15 +0100 Message-Id: <4.3.2.7.2.20010219163202.0405cf08@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Feb 2001 16:34:08 +0100 To: "Eric A. Hall" , idn@ops.ietf.org From: Harald Alvestrand Subject: "Any system anywhere" (Re: [idn] The report from the design team) In-Reply-To: <3A8A0F60.59CBBE59@ehsco.com> References: <5.0.2.1.1.20010115021238.03d99d20@mail.viagenie.qc.ca> <20010115115615.6526.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 20:53 13/02/2001 -0800, Eric A. Hall wrote: >IMO we should be treating IDNS the same way. We are limiting ourselves by >an artifical and unreasonable restriction when we demand that all >proposals must "allow any system anywhere to resolve any internationalized >domain name." That requirement should be removed from the spec completely. I believe the intent of the paragraph was to say "allow any system anywhere THAT IMPLEMENTS THE IDN SPECIFICATION to resolve any internationalized domain name". The scenario it was aimed to prevent was one where multiple enclaves of "IDN" names existed, where one could not resolve those names without passing through the gateways for that particular enclave. I propose the version above (without caps) as replacement text. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Mon Feb 19 11:37:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08658 for ; Mon, 19 Feb 2001 11:37:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ut47-000P8u-00 for idn-data@psg.com; Mon, 19 Feb 2001 08:21:31 -0800 Received: from dokka.maxware.no ([195.139.236.69]) by psg.com with esmtp (Exim 3.16 #1) id 14Ut46-000P8i-00 for idn@ops.ietf.org; Mon, 19 Feb 2001 08:21:30 -0800 Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id RAA25139; Mon, 19 Feb 2001 17:21:14 +0100 Message-Id: <4.3.2.7.2.20010219170330.043eef00@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Feb 2001 17:08:16 +0100 To: John C Klensin , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Harald Alvestrand Subject: Versioning (Re: [idn] The layers and character handling in DNS) Cc: idn@ops.ietf.org In-Reply-To: <3242451662.982494995@r2.jck.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:16 18/02/2001 -0500, John C Klensin wrote: >(ii) We have a really good versioning model so that someone >applying Nameprep can know what rules to use. If >NamePrep2001(string) != NamePrep2002(string) and one can't tell >which one should be applied, I think that, long-term, the whole >thing deteriorates badly. Given an obvious variation of the F1 >!= F2 argument, I suspect (but haven't worked through the cases >to my satisfaction yet) that means that the relevant version >information needs to be encoded in the names themselves. I.e., >the real test is whether > NamePrepN(F1(X,Z))=NamePrepM(F2(X,Z)) and whether > M and N can be determined in all places in which it is relevant >(which would be especially important if the equality doesn't >apply --it won't, or one wouldn't need NamePrep versions-- and >one needs to know which version to apply. actually versioning nameprep does not work, for any case but the one where a string illegal in NameprepM is now legal in NameprepN (M < N). for this case, one can assume that 1) the name is installed using NameprepN (since M would disallow it) and that 2) the owner doesn't care that he is not reachable under NameprepM (or he would have chosen another). For the case of NameprepM <> NameprepN, we can store the info on which name to use: - in the human-readable string. Will be pelted with rotten bananas. - in the DNS entry for the name. But since we can't get to the DNS-stored entry before we have done nameprep, the chicken-and-egg conundrum strikes again. - in the global /hosts.txt file????? For any existing name, Nameprep can't change. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Mon Feb 19 19:44:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18931 for ; Mon, 19 Feb 2001 19:44:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14V0K2-0007ez-00 for idn-data@psg.com; Mon, 19 Feb 2001 16:06:26 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14V0K2-0007en-00 for idn@ops.ietf.org; Mon, 19 Feb 2001 16:06:26 -0800 Received: from slip139-92-111-94.gen.ch.prserv.net ("port 1051"@[139.92.111.94]) by a4.jck.com (PMDF V6.0-24 #44844) with ESMTPA id <0G910042T4AABD@a4.jck.com> for idn@ops.ietf.org; Mon, 19 Feb 2001 19:06:24 -0500 (EST) Date: Mon, 19 Feb 2001 18:28:39 -0500 From: John C Klensin Subject: Re: Versioning (Re: [idn] The layers and character handling in DNS) In-reply-to: <4.3.2.7.2.20010219170330.043eef00@127.0.0.1> To: Harald Alvestrand Cc: idn@ops.ietf.org Message-id: <3354775732.982607319@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.6 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 19 February, 2001 17:08 +0100 Harald Alvestrand wrote: > actually versioning nameprep does not work, for any case but > the one where a string illegal in NameprepM is now legal in > NameprepN (M < N). That has been my impression. But, if it is the case, it implies that the first, and every subsequent version, of nameprep must be perfectly correct for any unbanned characters. Sorry, but being certain about that... Well, the WG just doesn't appear have the level of divine guidance needed to be that confident; we need to design things on the assumption that we will need versions because we got something wrong and it turned out to be important. If we can't, then the system fails. > - in the human-readable string. Will be pelted with rotten > bananas. - in the DNS entry for the name. But since we can't > get to the DNS-stored entry before we have done nameprep, the > chicken-and-egg conundrum strikes again. - in the global > /hosts.txt file????? > > For any existing name, Nameprep can't change. Again, requires perfect wisdom. Since we don't have that, I think you are adding to my argument that the current approach just cannot work. john From owner-idn@ops.ietf.org Mon Feb 19 20:55:48 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19751 for ; Mon, 19 Feb 2001 20:55:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14V1T7-0008qy-00 for idn-data@psg.com; Mon, 19 Feb 2001 17:19:53 -0800 Received: from nordic.cisco.com ([144.254.116.47] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14V1T6-0008qM-00 for idn@ops.ietf.org; Mon, 19 Feb 2001 17:19:53 -0800 Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id CAA12035; Tue, 20 Feb 2001 02:17:48 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <3354775732.982607319@localhost> References: <3354775732.982607319@localhost> Date: Mon, 19 Feb 2001 17:16:41 -0800 To: John C Klensin , Harald Alvestrand From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Versioning (Re: [idn] The layers and character handling in DNS) Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 18.28 -0500 01-02-19, John C Klensin wrote: > > - in the human-readable string. Will be pelted with rotten >> bananas. - in the DNS entry for the name. But since we can't >> get to the DNS-stored entry before we have done nameprep, the >> chicken-and-egg conundrum strikes again. - in the global >> /hosts.txt file????? >> >> For any existing name, Nameprep can't change. > >Again, requires perfect wisdom. Since we don't have that, I >think you are adding to my argument that the current approach >just cannot work. We don't do the algorithms in nameprep. UTC does. I claim they are better than we (as you say we don't have knowledge about these things) and that we don't have any other choice than pointing at them. Have anyone done a better job than UTC regarding normalization and case folding and creation of one charset? If so, the discussion is interesting whether we should go with UTC or someone else, depending on how many bugs there is in their tables. NOT doing this solution and only a dictionary solution (something I think we need regardless) means staying with the subset of ascii accepted as "hostnames" for a very very long time. I don't see the market wanting to wait for that -- which includes changing all protocols, and all applications. paf From owner-idn@ops.ietf.org Tue Feb 20 06:52:09 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10453 for ; Tue, 20 Feb 2001 06:52:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VAQC-000Iwu-00 for idn-data@psg.com; Tue, 20 Feb 2001 02:53:28 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 14VAQC-000Iwn-00 for idn@ops.ietf.org; Tue, 20 Feb 2001 02:53:28 -0800 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08076; Tue, 20 Feb 2001 02:53:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id CAA19138; Tue, 20 Feb 2001 02:53:20 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1KArIL306867; Tue, 20 Feb 2001 02:53:18 -0800 (PST) Date: Tue, 20 Feb 2001 11:52:30 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] The layers and character handling in DNS To: Keith Moore Cc: David C Lawrence , idn@ops.ietf.org In-Reply-To: "Your message with ID" <200102171810.NAA29270@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > if you want an interface to look up addresses from IDNs - whether it be > in native format, UTF-8, or whatever - you need a different function. > don't overload gethostbyname. > > but don't try to retroactively change an existing interface. I agree fully. I think some of the experience in dealing with this for IPv6 can be useful, since it had much of the same issues - unmodified applications can't in general cope with gethostbyname returning an IPv6 address just as unmodified applications can't cope with gethostbyADDR returning an IDN (in your favorite character set) name. *If* (and this isn't obvious to me) there is a need for APIs that encapsulte ace encoding (or ace + nameprep) together with the IP address lookups I think it would make sense to look at getaddrinfo() and getnameinfo(). Those APIs are recommended for IPv6 address lookups *and* they have flags fields that it easy to extended the e.g. for IDN purposes. My 2 cents, Erik From owner-idn@ops.ietf.org Tue Feb 20 10:26:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13431 for ; Tue, 20 Feb 2001 10:26:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VEMM-000Mgk-00 for idn-data@psg.com; Tue, 20 Feb 2001 07:05:46 -0800 Received: from [128.169.93.168] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 3.16 #1) id 14VEML-000MeW-00 for idn@ops.ietf.org; Tue, 20 Feb 2001 07:05:45 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA28868; Tue, 20 Feb 2001 09:41:00 -0500 (EST) Message-Id: <200102201441.JAA28868@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , David C Lawrence , idn@ops.ietf.org Subject: Re: [idn] The layers and character handling in DNS In-reply-to: Your message of "Tue, 20 Feb 2001 11:52:30 +0100." Date: Tue, 20 Feb 2001 09:41:00 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > *If* (and this isn't obvious to me) there is a need for APIs > that encapsulte ace encoding (or ace + nameprep) together with > the IP address lookups I think it would make sense to look > at getaddrinfo() and getnameinfo(). > Those APIs are recommended for IPv6 address lookups *and* they > have flags fields that it easy to extended the e.g. for IDN purposes. getxxxinfo also avoids a huge design flaw in gethostbyxxx - getxxxinfo can indicate temporary failures. Keith From owner-idn@ops.ietf.org Thu Feb 22 21:25:34 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03519 for ; Thu, 22 Feb 2001 21:25:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14W7T2-000CDr-00 for idn-data@psg.com; Thu, 22 Feb 2001 17:56:20 -0800 Received: from web5502.mail.yahoo.com ([216.115.106.185]) by psg.com with smtp (Exim 3.16 #1) id 14W7T1-000CDk-00 for idn@ops.ietf.org; Thu, 22 Feb 2001 17:56:19 -0800 Message-ID: <20010223015618.8908.qmail@web5502.mail.yahoo.com> Received: from [159.226.6.169] by web5502.mail.yahoo.com; Thu, 22 Feb 2001 17:56:18 PST Date: Thu, 22 Feb 2001 17:56:18 -0800 (PST) From: wenhui zhang Subject: Re: [idn] next ietf To: Marc Blanchet , idn@ops.ietf.org Cc: jseng@pobox.org.sg In-Reply-To: <5.0.2.1.1.20010217213928.02bb0fa0@mail.viagenie.qc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk hello We would like to make a presentation at the meeting. title:Technical Implementation and Stardard Suggestions for IDN name: Wenhui Zhang, CNNIC document (i.e. draft name): requested time:30 minutes Thanks for your considerations. Thanks in advances wenhui CNNIC --- Marc Blanchet wrote: > Some notes about the next IETF meeting: > > Tentative idn wg time (may change: see > http://www.ietf.org/meetings/agenda_50.txt): > > WEDNESDAY, March 21, 2001 > 1300-1500 Afternoon Sessions I > INT idn Internationalized Domain > Name WG > > THURSDAY, March 22, 2001 > 1300-1500 Afternoon Sessions I > INT idn Internationalized Domain > Name WG > > > Internet-draft cutoff dates > (http://www.ietf.org/meetings/cutoff_dates_50.html): > > February 23 - Internet Draft Cut-off for initial > document (-00) > submission at 17:00 ET > March 2 - Internet Draft final submission cutoff > date at 1700 ET > > idn wg agenda: > People who would like to present something during > the next idn meeting > should send their request using this template to the > wg co-chairs > (Marc.Blanchet@viagenie.qc.ca,jseng@pobox.org.sg): > > title: > name: > document (i.e. draft name): > requested time: > > > Thanks, Marc. > > Marc Blanchet > Viagnie inc. > tel: 418-656-9254 > http://www.viagenie.qc.ca > > ---------------------------------------------------------- > Normos (http://www.normos.org): Internet standards > portal: > IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all > in one place. > > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ From owner-idn@ops.ietf.org Sun Feb 25 20:22:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14278 for ; Sun, 25 Feb 2001 20:22:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XBzQ-000IiI-00 for idn-data@psg.com; Sun, 25 Feb 2001 16:58:12 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14XBzP-000IiC-00 for idn@ops.ietf.org; Sun, 25 Feb 2001 16:58:11 -0800 Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f1Q1BDd46968 for ; Sun, 25 Feb 2001 20:11:14 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010225151048.04f70e88@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 25 Feb 2001 15:12:31 -0500 To: idn@ops.ietf.org From: Marc Blanchet Subject: [idn] ietf agenda changed Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, ietf agenda changed for idn sessions. Please note that this can change again anytime. Regards, Marc. Current sessions are: +++++++++++++++++++++ Draft Agenda of the Fiftieth IETF Meeting March 18 - 23, 2001 Minneapolis, MN (As of February 22, 2001) MONDAY, March 19, 2001 1930-2200 Evening Sessions APP fax Internet Fax WG GEN ipo IP over Optical WG INT idn Internationalized Domain Name WG OPS aaa Authentication, Authorization and Accounting WG OPS rmonmib Remote Network Monitoring WG RTG manet Mobile Ad-hoc Networks WG SEC ipsp IP Security Policy WG TSV tsvwg Transport Area WG WEDNESDAY, March 21, 2001 1300-1500 Afternoon Sessions I APP trade Internet Open Trading Protocol WG INT idn Internationalized Domain Name WG INT l2tpext Layer Two Tunneling Protocol Extensions WG OPS mboned MBONE Deployment WG OPS rap Resource Allocation Protocol WG RTG ospf Open Shortest Path First IGP WG SEC kink Kerberized Internet Negotiation of Keys WG TSV pilc Performance Implications of Links Characteristics WG Marc Blanchet Viagnie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From owner-idn@ops.ietf.org Sun Feb 25 23:59:14 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17602 for ; Sun, 25 Feb 2001 23:59:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XFUd-000LpG-00 for idn-data@psg.com; Sun, 25 Feb 2001 20:42:39 -0800 Received: from nwcst267.netaddress.usa.net ([204.68.23.12]) by psg.com with smtp (Exim 3.16 #1) id 14XFUc-000LpA-00 for idn@ops.ietf.org; Sun, 25 Feb 2001 20:42:38 -0800 Received: (qmail 2493 invoked by uid 60001); 26 Feb 2001 04:42:37 -0000 Message-ID: <20010226044237.2492.qmail@nwcst267.netaddress.usa.net> Received: from 204.68.23.12 by nwcst267 for [159.226.7.70] via web-mailer(34FM.0700.15B.01) on Mon Feb 26 04:42:37 GMT 2001 Date: 26 Feb 2001 12:42:37 HKT From: "xiaodong.lee" To: idn@ops.ietf.org Subject: [idn] Some opinions on Requirements of IDN X-Mailer: USANET web-mailer (34FM.0700.15B.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA17602 hello I have some opinions on "Requirements of Internationalized Domain Name" just hoping someone on the list can tell me the particular or exact answer,thanks anyway for any help on making clear >[4] The protocol MUST NOT require that the current DNS cache >servers be modified to support IDN. If a cache server can have >additional functionality to support IDN better, this additional >functionality MUST NOT cause problems for resolving correctly >functioning current domain names. In the future, when IDN become a standrad, is it necessary that we Must NOT modify the (current)DNS cache server to support IDN? I originally think that this requirement consider the requirement of the IDN final solution, if so, why have this limitation? >[8] The protocol supporting the service SHOULD be as simple as possible >from the user's perspective. Ideally, users SHOULD NOT realize that IDN >was added on to the existing DNS. Here, the concept of "user" is indistinct. If "user"=Application, the limitation of "users SHOULD NOT realize that IDN was added on to the existing DNS" will limit the extension of application interface to be compatible with IDN. >[35] Within a single zone, the zone manager MUST be able to define >equivalence rules that suit the purpose of the zone, such as, but not >limited to, and not necessarily, non-ASCII case folding, Unicode >normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or >traditional/simplified Chinese equivalence. Such defined equivalences >MUST NOT remove equivalences that are assumed by (old or >local-rule-ignorant) caches. If the zone manager of any node could change the equivalence rules, the inconsistent equivalences of the whole IDN system would be brought on. ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1