From owner-idn@ops.ietf.org Fri Jan 5 11:28:46 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16057 for ; Fri, 5 Jan 2001 11:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EY2x-0009Ap-00 for idn-data@psg.com; Fri, 05 Jan 2001 06:40:47 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14EY2v-0009AU-00 for idn@ops.ietf.org; Fri, 05 Jan 2001 06:40:45 -0800 Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA11820; Fri, 5 Jan 2001 09:40:43 -0500 (EST) Message-Id: <200101051440.JAA11820@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] An experiment with UTF-8 domain names In-reply-to: Your message of "05 Jan 2001 07:55:41 GMT." <20010105075541.26564.qmail@cr.yp.to> Date: Fri, 05 Jan 2001 09:39:28 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk Dan, you're testing the wrong things. we already know that the DNS protocol and common DNS implementations will handle arbitrary 8bit character strings, and those can be UTF-8 if we want them to. we also know that the vast majority of applications cannot properly input or display UTF-8 strings, and that some applications will either break or improperly handle UTF-8 strings when they appear in domain names. > This sent a message to postmaster@S.cr.yp.to. I read the message using > the UTF-8 version of less, and it was displayed comprehensibly, with the > To line shown as follows: > > To: postmaster@"S".cr.yp.to > > qmail-inject doesn't mind weird characters, such as control characters > and 8-bit characters, in atoms. It converts the atoms to quoted strings. > Of course, RFC 822 doesn't allow quoted strings, never mind 8-bit > characters, in domain names, but these are easy protocol extensions. ... > What's wrong with handling S this way? The answer seems to be that some > other programs don't work. What are those programs? What exactly do they > do wrong? How hard is it to fix them? Why should we believe that the > other IDN proposals will require less effort? > > Keith Moore writes: > > all apps will have to be modified (many will require significant > > modification) if they want to deal meaningfully with IDNs. > > False. As demonstrated above, qmail and djbdns already work with UTF-8 > domain names. They're both widely deployed. Apparently Microsoft also > has some clients and servers that work with UTF-8 domain names. no, you've just demonstrated that qmail does not work with UTF-8 domain names, because it generates an illegal message header. other mail parsers will choke on the message header that qmail generates because it violates RFC822 syntax. other programs may (in some sense) also treat the same input "reasonably" but will behave differently than qmail under such conditions. from experience, some of them will generate RFC 2047 encoded-words (different ones in different ways) - which is also a violation of the specifications, but a different violation of the specifications. replies to such messages will fail. > Changing those programs has a cost. What is the benefit? interoperability. Brian W. Spolarich writes: > > Using 8-bit data will break some applications. > > Using 7-bit data (presumably) will not. > > False. If the user's S.cr.yp.to has to be encoded inside DNS and mail > messages as ace-blah.cr.yp.to, then qmail will be faced with S.cr.yp.to > in (e.g.) /var/qmail/control/virtualdomains, and ace-blah.cr.yp.to in > SMTP. This simply won't work unless the software is changed. that's a good point. but until qmail is updated to accept UTF-8 in virtualdomains and other places, users can at least get IDNs to work by cutting-and-pasting the ACE form of the name. presumably we would want similar support for DNS zone files. but it's even worse than that, because most UNIX users today are not using UTF-8 as a local charset. so they'll quite naturally edit the virtualdomains file using iso-8859-1, or iso-2022-jp, or whatever is the default for their environment. either tools that read IDNs will have to know how to translate from local chraset to UTF-8, or users will have to learn to use different commands to edit files containing IDNs than they use to edit "normal" (for them) files. (I think the former is more likely; users are loathe to give up their familiar editors) (the problem is slightly different on windows and mac platforms, but exists nonetheless) actually the problem is much the same in both cases, because in both cases the sysadmin has to type in a form of the domain name which is not the same as is used natively - unless the local charset just happens to be UTF-8. > If, on the other hand, S.cr.yp.to is used as is, then the software will > work fine. no, it just breaks a different set of things. and (at least in this case) it moves the points at which the failures are noticed away from the systems that are controlled by the folks who are setting up the IDN, to remote systems that are used by folks who are less likely to be able to identify, much less fix, the problem. > James Seng/Personal writes: > > Patching sendmail might be trival for a good programmer like yourself. > > How fast do you think you can get everyone to use your patch and would > > unpatch software fallback safely? > > All the proposals require a sendmail patch. To tell sendmail to accept > mail for S.foo.dom, the user adds S.foo.dom to a file with his UTF-8 > editor; sendmail mishandles the \210 if it isn't patched. > > The patch required for direct use of UTF-8 is by far the simplest. No, > deployment isn't free, but the other proposals don't change this fact. true, deployment isn't free for any of these proposals, nor can it be. but your scenario doesn't even begin to address the impact on MUAs which cannot properly parse or generate replies for messages with UTF-8 in the message header. nor does it consider what happens with different legacy mail software handle the UTF-8 IDN in different ways. and of course email is just one application; lots of applications use DNS names. -- you're a smart guy, so I suspect that you've realized most or all of this already. I'm wondering whether the real difference of opinion might be about how much disruption to the installed base is acceptable in the name of producing an apparently "cleaner" result in the long run. taking email as an example, what percentage of each of the following would be acceptable (relative to the number of messages sent), in your opinion: - catastrophic MTA failures (crashes) - catastrophic UA failures (crashes) - unreported delivery failures - reported delivery failures - messages delivered but undisplayable due to parse errors etc. - messages delivered but unreplyable due to lack of UA support (would work if a different or upgraded UA were used) - messages delivered but unreplyable due to being modified in transit Keith p.s. > P.S. I'm a subscriber to this mailing list. I don't want to receive > extra copies of messages sent to the list. I've set Mail-Followup-To > accordingly. and since Mail-Followup-To is a nonstandard extension, I assume you're willing to accept the lack of reliability that naturally comes from use of nonstandard extensions. :) > P.P.S. You may have noticed an unusual From line on this message. The > problem is that the software running this mailing list can't deal with > the concept of sublist subscribers; it forwards my messages to Seng. > Seng eventually approved two of my messages, editing the Date field and > removing the Received lines to hide the delay. He has refused to approve > this one unless I take special actions to fool the list software. So I'm > using his address in From, and my address in Reply-To. Hmm. I use subaddresses also, and at first I had this problem also. If memory serves it was worked around by adding my address to a list of non-subscribers who are authorized to post. Not an ideal solution to be sure, but the problem of mailing lists that don't allow postings from non-subscribers isn't likely to get fixed here. From owner-idn@ops.ietf.org Fri Jan 5 11:28:49 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16069 for ; Fri, 5 Jan 2001 11:28:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Dq24-000N62-00 for idn-data@psg.com; Wed, 03 Jan 2001 07:40:56 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14Dq24-000N5l-00 for idn@ops.ietf.org; Wed, 03 Jan 2001 07:40:56 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA00400; Wed, 3 Jan 2001 07:39:03 -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 f03FcvC16290; Wed, 3 Jan 2001 07:38:57 -0800 (PST) Received: from [212.247.7.134] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA25774; Wed, 3 Jan 2001 07:38:43 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <4.2.0.58.J.20001227171746.02e6aae0@sh.w3.mag.keio.ac.jp> References: <4.2.0.58.J.20001227171746.02e6aae0@sh.w3.mag.keio.ac.jp> Date: Wed, 3 Jan 2001 16:37:48 +0100 To: "Martin J. Duerst" , "James Seng/Personal" , "D. J. Bernstein" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] What's wrong with skwan-utf8? Cc: 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 19.22 +0900 01-01-03, Martin J. Duerst wrote: >As I said, web browsers support it, and they are the most important >clients for multilingual domain names. Also, conversion from >UTF-16 or UCS-4 to UTF-8 is very simple and has been implemented >dozens of times. The ACE proposals I have looked at are quite a bit >more complicated, and there is rarely much code yet. Martin, code exists in many places already for ACE, and the troublesome part of all of this will still be the nameprep part which have to be done regardless of UTF-8 or *ACE encodings. Existing implementations of UTF-8 will not be possible to use, so we have to update quite some amount of code regardless of what solution is chosen. Also, I want you to please differentiate between implementations of standards and the standards themselves. RFC 821 took 6 years to clearify in RFC 2821... paf -- Patrik Fältström 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 Fri Jan 5 11:28:53 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16080 for ; Fri, 5 Jan 2001 11:28:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EYZs-0009gS-00 for idn-data@psg.com; Fri, 05 Jan 2001 07:14:48 -0800 Received: from smtp.ispchannel.com ([24.142.63.7] helo=smtp2a.ispchannel.com) by psg.com with esmtp (Exim 3.16 #1) id 14EYZr-0009g3-00 for idn@ops.ietf.org; Fri, 05 Jan 2001 07:14:48 -0800 Received: from mark ([24.142.91.110]) by smtp2a.ispchannel.com (InterMail vK.4.02.00.00 201-232-116 license 7d3764cdaca754bf8ae20adf0db2aa60) with SMTP id <20010105151756.YWFK382.smtp2a@mark>; Fri, 5 Jan 2001 07:17:56 -0800 Message-ID: <002901c0772a$5c2eb2f0$6e5b8e18@mark> From: "Mark Davis" To: "Dan" , , References: <200101051007.f05A7ll14252@malmo.trab.se> Subject: Re: [idn] An experiment with UTF-8 domain names Date: Fri, 5 Jan 2001 07:15:38 -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 > So if the applications use the correct normalisation of UTF-8 today they need not be changed. There are many ways to normalize data. NamePrep is designed to provide a single, absolutely determinate process for this IDN normalization. The chances that the average application would, by chance, duplicate the same normalization is minimal. Mark ----- Original Message ----- From: "Dan" To: ; Sent: Friday, January 05, 2001 02:07 Subject: Re: [idn] An experiment with UTF-8 domain names Patrik Fältström wrote: >At 07.55 +0000 01-01-05, D. J. Bernstein wrote: >>Keith Moore writes: >>> all apps will have to be modified (many will require significant >>> modification) if they want to deal meaningfully with IDNs. >> >>False. As demonstrated above, qmail and djbdns already work with UTF-8 >>domain names. They're both widely deployed. Apparently Microsoft also >>has some clients and servers that work with UTF-8 domain names. > >They have to be changed because of the nameprep stage, which will >have to be done regardless of whether you use UTF-8 or ACE or >whatever encoding of Unicode. That depends on how the applications encode UTF-8 today and how we use UTF-8 in DNS. All that is needed is that the UTF-8 is normalised to the form selected for use in DNS. So if the applications use the correct normalisation of UTF-8 today they need not be changed. The rest of the "nameprep" handling can be done in the DNS servers. Dan From owner-idn@ops.ietf.org Fri Jan 5 14:06:49 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19919 for ; Fri, 5 Jan 2001 14:06:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EbrX-000Cco-00 for idn-data@psg.com; Fri, 05 Jan 2001 10:45:15 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14EbrW-000Cch-00 for idn@ops.ietf.org; Fri, 05 Jan 2001 10:45:14 -0800 Received: (qmail 29200 invoked by uid 1001); 5 Jan 2001 18:41:41 -0000 Date: 5 Jan 2001 18:41:41 -0000 Message-ID: <20010105184141.18748.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein c/o James Seng" To: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names Reply-To: "D. J. Bernstein" References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk paf writes: > They have to be changed because of the nameprep stage, Ah, yes, the stage where af.mi1 is converted to af.mil. I know this will come as a shock to you, but I've never implemented that stage. The registries don't accept af.mi1 as an alias for af.mil; neither do I. Users who see af.mil on a business card have to type af.mil, not af.mi1, into the computer. If they don't know how to do that, too bad. I'm going to continue allowing DNS administrators to set up ``lDNs'' even though I know that some users will have trouble typing them. Keith Moore writes: > you're testing the wrong things. Setting up domain names in DNS, arranging for them to receive mail, sending mail to them, and reading the mail, are the ``wrong things''? Do you also think that putting up web pages and reading them are the ``wrong things''? > we also know that the vast majority of applications cannot properly > input or display UTF-8 strings, and that some applications will either > break or improperly handle UTF-8 strings when they appear in domain names. Several of us keep asking for details of what exactly will break. The anti-UTF-8 people keep refusing to provide those details. Why? Could it be because the failures aren't as widespread as they claim? Yes, sendmail corrupts UTF-8 IDNs. Perhaps other programs have trouble too. How difficult will it be to fix them? Why should we believe that painful MIME-style IDNs will be less expensive? All I'm asking for is an accurate evaluation of the costs and benefits of each IDN proposal. > most UNIX users today are not using UTF-8 as a local charset. XFree86 4.0 uses the UTF-8 version of xterm. It's easy to configure Emacs and vim and less to treat text as UTF-8. This is going to replace 8859-1 as the default; UNIX users are tired of dealing with deficient character sets. Is this upgrade free? No. People will be stuck with 8859-1 text files for years, and will have to go through extra effort to view them until they're converted to UTF-8 on disk. But choosing another IDN proposal isn't going to reduce this cost. > illegal message header Irrelevant. The format was extended. Calling a successful experiment unsuccessful because it wasn't IETF-sanctioned is silly. ---Dan From owner-idn@ops.ietf.org Fri Jan 5 15:52:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22229 for ; Fri, 5 Jan 2001 15:52:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EdSg-000Dzs-00 for idn-data@psg.com; Fri, 05 Jan 2001 12:27:42 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14EdSe-000Dzm-00 for idn@ops.ietf.org; Fri, 05 Jan 2001 12:27:40 -0800 Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA15331; Fri, 5 Jan 2001 15:22:38 -0500 (EST) Message-Id: <200101052022.PAA15331@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] An experiment with UTF-8 domain names In-reply-to: Your message of "05 Jan 2001 18:41:41 GMT." <20010105184141.18748.qmail@cr.yp.to> Date: Fri, 05 Jan 2001 15:21:24 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > They have to be changed because of the nameprep stage, > > Ah, yes, the stage where af.mi1 is converted to af.mil. > > I know this will come as a shock to you, but I've never implemented that > stage. The registries don't accept af.mi1 as an alias for af.mil; > neither do I. > > Users who see af.mil on a business card have to type af.mil, not af.mi1, > into the computer. If they don't know how to do that, too bad. that's not the problem. the problem is that there are multiple, legal, on-the-wire representations for af.mil which produce the same glyphs, and different systems will generate different representations when the same keys are pressed. > Keith Moore writes: > > you're testing the wrong things. > > Setting up domain names in DNS, arranging for them to receive mail, > sending mail to them, and reading the mail, are the ``wrong things''? yes. you're testing the things which were most likely to work, and ignoring the things which are least likely to work. there's nothing wrong with testing everything, but claims of victory that are based on partial success of the tests that are chosen to be most likely to work are meaningless...sort of like testing the resiliance of O rings in warm temperatures, observing that they fail some of the time, and then expecting them to work just as well when it's cold. > Do you also think that putting up web pages and reading them are the > ``wrong things''? yes. try putting up web pages with links to URLs containing IDNs which are encoded in UTF-8 (using various URL prefixes and various protocols with servers on a variety of platforms) and seeing whether those links work in various browsers. Then try putting URLs containing IDNs into text files, mailing them around, and using cut-and-paste to enter them into a broswer's "get URL" dialog box. Then try printing URLs containing IDNs on business cards, and typing them in to browsers dialog boxes. now devise similar tests for all other applications that use DNS names. of course ACE approaches will fail some of these tests also, but the tests have to be realistic if you want meaningful results. > > we also know that the vast majority of applications cannot properly > > input or display UTF-8 strings, and that some applications will either > > break or improperly handle UTF-8 strings when they appear in domain names. > > Several of us keep asking for details of what exactly will break. The > anti-UTF-8 people keep refusing to provide those details. Why? Could it > be because the failures aren't as widespread as they claim? even with a small sample size, when all of your trials produce failures, there's a good chance that it won't work on a large scale. and especially when the cost of failure is a serious disruption of critical services, it makes sense to be conservative. (and your trial produced a failure, you just refuse to recognize it) > Yes, sendmail corrupts UTF-8 IDNs. Perhaps other programs have trouble > too. How difficult will it be to fix them? Why should we believe that > painful MIME-style IDNs will be less expensive? the real cost of upgrades isn't the effort to fix the code for current releases, it's: - identifying the nature of the problems caused and tracing them to their source - getting millions of individuals to upgrade their software - supporting older systems and old releases of software that are still in use [*] - dealing with the disruption until everything gets upgraded [*] upgrades tend to have a domino effect. to upgrade an application you might well need a newer version of the OS, which might in turn require more memory, which might justify the cost of entirely new hardware, which then requires that all of the other tools on that system be re-installed, which tends to imply that other apps get updated also... so the barrier to upgrading even a single component can be significant a strategy for minimal disruption is: - affect as few components as possible (since the effort required to deal with breakage is on a per-component basis rather than a per-line-of-code basis) - put most of the burden of upgrading on those who benefit most it appears that ACE schemes fare better at this strategy than UTF-8 schemes. > All I'm asking for is an accurate evaluation of the costs and benefits > of each IDN proposal. I'm sure the list would appreciate it if you did more experiments and reported the results, as long as you were looking at realistic scenarios. but even with such results about which cases work and which ones fail, "costs and benefits" are highly subjective. bottom line is that each WG participant will have to evaluate the costs and benefits on his or her own, and each participant will have to invest the amount of effort that he or she believes is sufficient to reach a conclusion. we have to reach rough consensus on the design decisions, we don't have to reach rough consensus on the motivations. > > most UNIX users today are not using UTF-8 as a local charset. > > XFree86 4.0 uses the UTF-8 version of xterm. It's easy to configure > Emacs and vim and less to treat text as UTF-8. This is going to replace > 8859-1 as the default; UNIX users are tired of dealing with deficient > character sets. > > Is this upgrade free? No. People will be stuck with 8859-1 text files > for years, and will have to go through extra effort to view them until > they're converted to UTF-8 on disk. I think it's the other way around. people will not give up their favorite tools en masse in favor of unfamiliar tools that support UTF-8, especially when their existing files are in other formats. And changing to a new xterm won't automatically make the old tools work (actually it will probably break some tools that expect each character takes one octet). and this process won't be driven by UNIX users anyway. > But choosing another IDN proposal isn't going to reduce this cost. you haven't said anything to support this argument. Keith > > illegal message header > > Irrelevant. The format was extended. Calling a successful experiment > unsuccessful because it wasn't IETF-sanctioned is silly. perhaps. but calling an experiement successful when the proferred solution (a) didn't get deployed and (b) didn't solve the problem, is even sillier. fortuantely, your ersatz header doesn't actually break things that ignore it - unlike MUAs that generate UTF-8 in message headers. From owner-idn@ops.ietf.org Fri Jan 5 16:06:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22554 for ; Fri, 5 Jan 2001 16:06:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Edmi-000ENT-00 for idn-data@psg.com; Fri, 05 Jan 2001 12:48:24 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14Edmh-000ENG-00 for idn@ops.ietf.org; Fri, 05 Jan 2001 12:48:23 -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 MAA19053 for ; Fri, 5 Jan 2001 12:47:53 -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 f05Kls524558 for ; Fri, 5 Jan 2001 12:47:54 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA03707 for ; Fri, 5 Jan 2001 12:47:50 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010105184141.18748.qmail@cr.yp.to> References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> Date: Fri, 5 Jan 2001 20:37:06 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] An experiment with UTF-8 domain names Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 18.41 +0000 01-01-05, D. J. Bernstein c/o James Seng wrote: >paf writes: >> They have to be changed because of the nameprep stage, > >Ah, yes, the stage where af.mi1 is converted to af.mil. Not at all. There are other cases which doesn't look as stupid as this one which you just suggested. Several examples have been brought up on this mailing list about a year ago, so I will not repeat. Se Unicode specification. paf From owner-idn@ops.ietf.org Fri Jan 5 20:46:39 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26727 for ; Fri, 5 Jan 2001 20:46:38 -0500 (EST) From: owner-idn@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EiBM-000Pgj-00 for idn-data@psg.com; Fri, 05 Jan 2001 17:30:08 -0800 Date: Fri, 5 Jan 2001 19:49:36 +0000 (GMT) To: "D. J. Bernstein" Cc: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: <20010105184141.18748.qmail@cr.yp.to> References: <200101051007.f05A7ll14252@malmo.trab.se> Message-Id: <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <20010105184141.18748.qmail@cr.yp.to> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14934.9164.34347.942257@joanna.william.org> From: Martin Oldfield Sender: owner-idn@ops.ietf.org Precedence: bulk >>>>> "D" == D J Bernstein c/o James Seng writes: --> snip <-- D> Yes, sendmail corrupts UTF-8 IDNs. Perhaps other programs have D> trouble too. How difficult will it be to fix them? Why should D> we believe that painful MIME-style IDNs will be less expensive? --> snip <-- Please can I ask a dumb question ? Suppose Boris and Ivan want to communicate by email. Boris has a wonderfully efficient ISP who is good at upgrading to the latest software, and lives in a region where IDNs will make a really big difference. Accordingly he acquires a swanky new domain and email address very quickly. By contrast. Ivan's ISP is lazy and lives in a country where IDNs probably aren't so big a deal. Perhaps Ivan's an emigre. Am I right in thinking that UTF-8 style IDNs are used then Boris and Ivan can't communicate unless Ivan can persuade his ISP to upgrade his sendmail, but an ACE would only need Ivan to upgrade his mail client ? In fact if Boris starts the exchange and although it would look odd, wouldn't Ivan be able to just hit `Reply' on his existing email client ? Cheers, -- Martin Oldfield, AdamsNames Ltd. From owner-idn@ops.ietf.org Fri Jan 5 21:16:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26966 for ; Fri, 5 Jan 2001 21:16:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Eiib-0001y4-00 for idn-data@psg.com; Fri, 05 Jan 2001 18:04:29 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14EiiZ-0001xx-00 for idn@ops.ietf.org; Fri, 05 Jan 2001 18:04:28 -0800 Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA18476; Fri, 5 Jan 2001 21:04:17 -0500 (EST) Message-Id: <200101060204.VAA18476@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin Oldfield cc: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-reply-to: Your message of "Fri, 05 Jan 2001 19:49:36 GMT." Date: Fri, 05 Jan 2001 21:03:02 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Am I right in thinking that UTF-8 style IDNs are used then Boris and > Ivan can't communicate unless Ivan can persuade his ISP to upgrade his > sendmail, but an ACE would only need Ivan to upgrade his mail client ? probably so. the chance is good that a UTF-8 return address will either be mangled or be unusuable for some other reason. > In fact if Boris starts the exchange and although it would look odd, > wouldn't Ivan be able to just hit `Reply' on his existing email client ? probably so. though if experience with RFC 2047 is any guide, there is some chance that some MTA or gateway will prematurely "decode" the IDN and and thereby make it unusable. we could try to write the specifications clearly enough that this wouldn't happen very often. but people often mis-implement much more subtle things than this. Keith From owner-idn@ops.ietf.org Sat Jan 6 03:56:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14272 for ; Sat, 6 Jan 2001 03:56:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Eoqu-0005eK-00 for idn-data@psg.com; Sat, 06 Jan 2001 00:37:28 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14Eoqt-0005Up-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 00:37:27 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA04588 for ; Sat, 6 Jan 2001 00:37:04 -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 f068avP06545 for ; Sat, 6 Jan 2001 00:36:58 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id AAA17350 for ; Sat, 6 Jan 2001 00:36:45 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: <200101051007.f05A7ll14252@malmo.trab.se> Date: Sat, 6 Jan 2001 09:24:32 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] An experiment with UTF-8 domain names 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 19.49 +0000 01-01-05, owner-idn@ops.ietf.org wrote: >Am I right in thinking that UTF-8 style IDNs are used then Boris and >Ivan can't communicate unless Ivan can persuade his ISP to upgrade his >sendmail, but an ACE would only need Ivan to upgrade his mail client ? Correct. >In fact if Boris starts the exchange and although it would look odd, >wouldn't Ivan be able to just hit `Reply' on his existing email client ? Even this is true. It is even the case that Boris can give his ACE-version of his real email address to people in a form as "if you can not enter cyrillic characters in my email address, please enter this instead". I.e. I could register one day maybe: fältström.com ...but could also on my buissness card have (if the ACE ends up being RACE): bq--abtoi3duon2hf5tn .com Yes, it looks ugly, it explicitly is leakage which we all hate, but, it makes it possible for people with non-IDN software to access the domain. Of course, I can in parallell have a domain which is "faltstrom.com" or whatever, but I might think that my customers if I help them that way never update their software. I.e. I _WANT_ people to be able to use "fältström.com" probably, so I would only help them to some degree, and that might be to give them the ace encoding in paralel with the real name. paf From owner-idn@ops.ietf.org Sat Jan 6 05:28:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14629 for ; Sat, 6 Jan 2001 05:28:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EqO5-000Dp6-00 for idn-data@psg.com; Sat, 06 Jan 2001 02:15:49 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EqO4-000Doz-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 02:15:49 -0800 Received: from enoshima (ppp3ppp65.sfc.keio.ac.jp [133.27.12.131]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id TAA05135; Sat, 6 Jan 2001 19:16:37 +0900 (JST) Message-Id: <4.2.0.58.J.20010106190820.035f07c0@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 06 Jan 2001 19:08:38 +0900 To: RJ Atkinson , "J. William Semich" From: "Martin J. Duerst" Subject: Re: [idn] What's wrong with skwan-utf8? Cc: idn@ops.ietf.org In-Reply-To: <5.0.0.25.2.20010103130157.00a924d0@gnat.inet.org> References: <3.0.5.32.20010103125254.03d67160@mail.nic.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Sorry, but none of them handles ACE correctly. Regards, Martin. At 01/01/03 13:02 -0500, RJ Atkinson wrote: >At 12:52 03/01/01, J. William Semich wrote: > >Yes. Windows 2000 Professional - Multililanguage version. > > Many applications, including some widely used MUAs, >on Win2k Multilingual do NOT handle UTF8 correctly. If this >is the best you can come up with, you aren't being persuasive. > >Ran > From owner-idn@ops.ietf.org Sat Jan 6 05:28:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14648 for ; Sat, 6 Jan 2001 05:28:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EqNx-000DoZ-00 for idn-data@psg.com; Sat, 06 Jan 2001 02:15:41 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EqNv-000DoT-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 02:15:40 -0800 Received: from enoshima (ppp3ppp65.sfc.keio.ac.jp [133.27.12.131]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id TAA05128; Sat, 6 Jan 2001 19:16:35 +0900 (JST) Message-Id: <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 06 Jan 2001 18:42:22 +0900 To: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?= , idn@ops.ietf.org From: "Martin J. Duerst" Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: References: <20010105184141.18748.qmail@cr.yp.to> <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01/01/05 20:37 +0100, Patrik F$BgM(Btstr$B‹N(B wrote: >At 18.41 +0000 01-01-05, D. J. Bernstein c/o James Seng wrote: >>paf writes: >>> They have to be changed because of the nameprep stage, >> >>Ah, yes, the stage where af.mi1 is converted to af.mil. > >Not at all. There are other cases which doesn't look as stupid as this one >which you just suggested. > >Several examples have been brought up on this mailing list about a year >ago, so I will not repeat. Se Unicode specification. I think we should be realistic on both sides here. We don't have conversions for ASCII, but we have prohibited characters. Dan, what would happen if you try to register e.g. +-+.cr.yp.to ? Also, we have case mapping, currently done on the server but for many reasons better moved to the client for UCS. Also, for UCS, there are quite a few cases where the degree of determinism and success can be significantly improved for the end user by additional foldings. The best example probably is the full-width/half-width folding for Japanese and some other contexts. However, we should also be clear about the following: - Even with the best name preparation, some ambiguities, hopefully not worse than mil vs. mi1, will remain. - Trying to be too inclusive in folding will lead to work on cases that may occur once in a million or a billion. A rather typical example is the 'fi' ligature. [An additional argument for not folding that into 'f','i' is that it would change the behaviour for ASCII-only names, which is probably not something we want.] - Expecting that every single software component that will deal with internationalized domain names will do name preparation on every processing step is not realistic (Patrick, I'm not saying that you have such expectations, I just want to make sure others don't). Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 05:29:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14659 for ; Sat, 6 Jan 2001 05:29:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EqO1-000Dox-00 for idn-data@psg.com; Sat, 06 Jan 2001 02:15:45 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EqO0-000Doi-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 02:15:44 -0800 Received: from enoshima (ppp3ppp65.sfc.keio.ac.jp [133.27.12.131]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id TAA05131; Sat, 6 Jan 2001 19:16:36 +0900 (JST) Message-Id: <4.2.0.58.J.20010106184428.03a85850@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 06 Jan 2001 19:06:46 +0900 To: Keith Moore , "D. J. Bernstein" From: "Martin J. Duerst" Subject: Re: [idn] An experiment with UTF-8 domain names Cc: idn@ops.ietf.org In-Reply-To: <200101052022.PAA15331@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01/01/05 15:21 -0500, Keith Moore wrote: > > Do you also think that putting up web pages and reading them are the > > ``wrong things''? > >yes. try putting up web pages with links to URLs containing IDNs >which are encoded in UTF-8 (using various URL prefixes and various >protocols with servers on a variety of platforms) and seeing whether >those links work in various browsers. Then try putting URLs >containing IDNs into text files, mailing them around, and using >cut-and-paste to enter them into a broswer's "get URL" dialog box. >Then try printing URLs containing IDNs on business cards, and typing >them in to browsers dialog boxes. Keith, are you assuming that we are doing all this work so that people can put 'ace--blah' into their URIs, mail them around, put them in their 'location:' fields, and so on? It's clear that that would work with ACE, but that's not the point of our work, is it? If that's an argument for using ACE instead of UTF-8, then that's the wrong one. Please note that mailing truely internationalized URIs or domain names around does work quite nicely now, there is absolutely no need for any standards upgrades, although some implementations still leave room for improvement. The same applies for printing and typing. The only point where work is needed is where the domain name or URI is taken as characters (independent of how they are encoded, just the way the user sees them on the screen) and then resolved. >a strategy for minimal disruption is: > >- affect as few components as possible (since the effort required to > deal with breakage is on a per-component basis rather than a > per-line-of-code basis) If it's by component, I doubt that ACE is better than UTF-8. ACE needs a lot of special considerations, scripts that have to be fixed, and so on, in order to work. >- put most of the burden of upgrading on those who benefit most I'm not sure I agree with this. First of all, it implies that internationalized domain names have to be usable everywhere, immediately. I don't think that's really the demand we are facing. > > > most UNIX users today are not using UTF-8 as a local charset. > > > > XFree86 4.0 uses the UTF-8 version of xterm. It's easy to configure > > Emacs and vim and less to treat text as UTF-8. This is going to replace > > 8859-1 as the default; UNIX users are tired of dealing with deficient > > character sets. > > > > Is this upgrade free? No. People will be stuck with 8859-1 text files > > for years, and will have to go through extra effort to view them until > > they're converted to UTF-8 on disk. > >I think it's the other way around. people will not give up their >favorite tools en masse in favor of unfamiliar tools that support UTF-8, They don't have to. On unix, the general thing you will have to do is to create aliases or wrapper shell scripts for your editor to either set the locale to work with UTF-8 or to convert the file to the encoding your editor can handle and back. Do you expect editors that can handle ACE transparently to become prominent? Do you think it is sufficient to handle ACE as ASCII? >especially when their existing files are in other formats. And changing >to a new xterm won't automatically make the old tools work (actually >it will probably break some tools that expect each character takes one >octet). First, UTF-8 is *extremely* well designed to work in most cases even for such tools (shell scripts, filter programs,...). If you can give a concrete example of such a breakage in such kinds of programs, I would appreciate it. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 05:35:53 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14689 for ; Sat, 6 Jan 2001 05:35:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EqO0-000Dop-00 for idn-data@psg.com; Sat, 06 Jan 2001 02:15:44 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EqNy-000Dob-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 02:15:43 -0800 Received: from enoshima (ppp3ppp65.sfc.keio.ac.jp [133.27.12.131]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id TAA05139; Sat, 6 Jan 2001 19:16:38 +0900 (JST) Message-Id: <4.2.0.58.J.20010106190910.03596650@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 06 Jan 2001 19:09:49 +0900 To: "Carl S. Gutekunst" , idn@ops.ietf.org From: "Martin J. Duerst" Subject: Re: [idn] What's wrong with skwan-utf8? In-Reply-To: References: <"Your message with ID" <5.0.0.25.2.20010103130157.00a924d0@gnat.inet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01/01/03 11:17 -0800, Carl S. Gutekunst wrote: >If Microsoft didn't get LDAP right -- which natively uses UTF-8 -- I really >don't really think we can depend on anyone to get anything else right, either. Then, can we rely on them getting ACE correct? Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 05:39:43 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14639 for ; Sat, 6 Jan 2001 05:28:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EqO0-000Doo-00 for idn-data@psg.com; Sat, 06 Jan 2001 02:15:44 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EqNz-000Doc-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 02:15:43 -0800 Received: from enoshima (ppp3ppp65.sfc.keio.ac.jp [133.27.12.131]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id TAA05125; Sat, 6 Jan 2001 19:16:34 +0900 (JST) Message-Id: <4.2.0.58.J.20010106182347.0350a1e0@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 06 Jan 2001 18:28:37 +0900 To: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?= , idn@ops.ietf.org From: "Martin J. Duerst" Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: References: <200101051007.f05A7ll14252@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01/01/06 09:24 +0100, Patrik F$BgM(Btstr$B‹N(B wrote: >At 19.49 +0000 01-01-05, owner-idn@ops.ietf.org wrote: >>In fact if Boris starts the exchange and although it would look odd, >>wouldn't Ivan be able to just hit `Reply' on his existing email client ? > >Even this is true. Yes. But if Ivan writes back to Boris and asks why he is suddenly using such a strange mail address, then Boris will be surprised, even embarrassed, and will not know what happened and why. >It is even the case that Boris can give his ACE-version of his real email >address to people in a form as "if you can not enter cyrillic characters >in my email address, please enter this instead". > >I.e. I could register one day maybe: > > f$BgM(Btstr$B‹N(B.com > >...but could also on my buissness card have (if the ACE ends up being RACE): > > bq--abtoi3duon2hf5tn .com Sorry, but I very strongly doubt that this should be done, and that very many people will want to embarrass themselves that way. >Yes, it looks ugly, it explicitly is leakage which we all hate, but, >it makes it possible for people with non-IDN software to access the >domain. Of course, I can in parallell have a domain which is >"faltstrom.com" or whatever, Yes, that's what will happen. People want names, not garbage. We all know that very well. >but I might think that my customers if I help them that way never update >their software. I.e. I _WANT_ people to be able to use "f$BgM(Btstr$B‹N(B.com" >probably, so I would only help them to some degree, and that might be to >give them the ace encoding in paralel with the real name. This sounds like a very secondary argument. If you want them to upgrade, you will point them to your nice address and tell them what they have to do to use it. Annoying your friends or business partners to get them to upgrade is a really strange idea. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 06:05:28 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14831 for ; Sat, 6 Jan 2001 06:05:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Eqvy-000H1I-00 for idn-data@psg.com; Sat, 06 Jan 2001 02:50:50 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14Eqvx-000H1C-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 02:50:50 -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 f06Aohl15535; Sat, 6 Jan 2001 11:50:44 +0100 (MET) Message-Id: <200101061050.f06Aohl15535@malmo.trab.se> Date: Sat, 6 Jan 2001 11:49:59 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] An experiment with UTF-8 domain names To: mark@macchiato.com Cc: idn@ops.ietf.org, paf@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0/3S54f6uvSZXtAKK/ecZw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Mark wrote: >> So if the applications use the correct normalisation of UTF-8 today they >need not be changed. > >There are many ways to normalize data. NamePrep is designed to provide a >single, absolutely determinate process for this IDN normalization. The >chances that the average application would, by chance, duplicate the same >normalization is minimal. > Depends on what you mean with normalisation. When I talk about normalisation of text, I mean order the character encoding in a standard way without destroying any important information in the text. For example Unicode normalisation form C and probably KC is like this. As ISO 10646 is defined with several alternative ways to encode a character, you need to normalise it to one way, if you want to have a simple handling of it. This type of normalisation is needed to make interoperability really work (because handling all possible ways of character encoding in your code is a lot of work and makes your code bigger). NamePrep defines how to transform the text into a form that can be used when comparing host names for equvalence using host name semantics. It destroys important information in the text. This type of "normalisation" is only needed when you want to compare two host names (and probably domain names). If both the above things are going to be called "normalisation" we need some way to separate the two. Anybody with a good idea for what to call them? Dan From owner-idn@ops.ietf.org Sat Jan 6 06:18:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14881 for ; Sat, 6 Jan 2001 06:18:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ErDx-000IjX-00 for idn-data@psg.com; Sat, 06 Jan 2001 03:09:25 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14ErDw-000IjQ-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 03:09:24 -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 f06B9Kl17774; Sat, 6 Jan 2001 12:09:20 +0100 (MET) Message-Id: <200101061109.f06B9Kl17774@malmo.trab.se> Date: Sat, 6 Jan 2001 12:08:35 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] An experiment with UTF-8 domain names To: duerst@w3.org Cc: idn@ops.ietf.org, paf@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8tq+F7KsVKWU4gnsbH+rTg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Martin said: >I think we should be realistic on both sides here. >We don't have conversions for ASCII, but we have >prohibited characters. Dan, what would happen if >you try to register e.g. +-+.cr.yp.to ? >Also, we have case mapping, currently done on the >server but for many reasons better moved to the >client for UCS. Moving case mapping to the client will break some applications. While DNS is case insensitive, many applications are not. Today I have several applications doing a reverse lookup to get the name of a host, and then use it to compare with application data. Today the reverse lookup preserves case and can therefore be used to compare with hosts names that have mixed case. If we move case folding to the client, we must teach everybody that "Peter" is not equivalent to "peter". It might be easy to a C programmer but not to the normal person. For them a "p" is a "p" independantly if it is written in upper or lower case. We will not be backward compatible. Regards, Dan From owner-idn@ops.ietf.org Sat Jan 6 07:47:22 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15176 for ; Sat, 6 Jan 2001 07:47:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EsVx-000OiN-00 for idn-data@psg.com; Sat, 06 Jan 2001 04:32:05 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14EsVw-000Ohz-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 04:32:04 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA04895; Sat, 6 Jan 2001 04:31:08 -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 f06CV2129403; Sat, 6 Jan 2001 04:31:02 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA24666; Sat, 6 Jan 2001 04:30:50 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <4.2.0.58.J.20010106190820.035f07c0@sh.w3.mag.keio.ac.jp> References: <3.0.5.32.20010103125254.03d67160@mail.nic.nu> <4.2.0.58.J.20010106190820.035f07c0@sh.w3.mag.keio.ac.jp> Date: Sat, 6 Jan 2001 13:29:25 +0100 To: "Martin J. Duerst" , RJ Atkinson , "J. William Semich" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] What's wrong with skwan-utf8? Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 19.08 +0900 01-01-06, Martin J. Duerst wrote: >Sorry, but none of them handles ACE correctly. But the discussion was not about ACE, but instead that UTF-8 already works. What myself, Ran and others try to say is that is not the case. paf > >Regards, Martin. > >At 01/01/03 13:02 -0500, RJ Atkinson wrote: >>At 12:52 03/01/01, J. William Semich wrote: >>>Yes. Windows 2000 Professional - Multililanguage version. >> >> Many applications, including some widely used MUAs, >>on Win2k Multilingual do NOT handle UTF8 correctly. If this >>is the best you can come up with, you aren't being persuasive. >> >>Ran From owner-idn@ops.ietf.org Sat Jan 6 07:48:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15188 for ; Sat, 6 Jan 2001 07:48:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EsZU-000P3v-00 for idn-data@psg.com; Sat, 06 Jan 2001 04:35:44 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14EsZT-000P3P-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 04:35:43 -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 EAA10786 for ; Sat, 6 Jan 2001 04:35:13 -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 f06CZAs29697 for ; Sat, 6 Jan 2001 04:35:10 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA24796 for ; Sat, 6 Jan 2001 04:35:03 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200101061109.f06B9Kl17774@malmo.trab.se> References: <200101061109.f06B9Kl17774@malmo.trab.se> Date: Sat, 6 Jan 2001 13:34:46 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] An experiment with UTF-8 domain names Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12.08 +0100 01-01-06, Dan wrote: >Moving case mapping to the client will break some applications. >While DNS is case insensitive, many applications are not. >Today I have several applications doing a reverse lookup >to get the name of a host, and then use it to compare with >application data. If you read the nameprep draft, draft-ietf-idn-nameprep-00.txt, you will see that the case mapping is done in the client for the non-us-ascii names. So, we will be backward compatible for ascii characters. paf From owner-idn@ops.ietf.org Sat Jan 6 07:50:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15207 for ; Sat, 6 Jan 2001 07:50:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EsVn-000Oi9-00 for idn-data@psg.com; Sat, 06 Jan 2001 04:31:55 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14EsVm-000Ohu-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 04:31:54 -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 EAA08895; Sat, 6 Jan 2001 04:30:48 -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 f06CUnM29395; Sat, 6 Jan 2001 04:30:49 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA24658; Sat, 6 Jan 2001 04:30:26 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> References: <20010105184141.18748.qmail@cr.yp.to> <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> Date: Sat, 6 Jan 2001 13:27:08 +0100 To: "Martin J. Duerst" , idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] An experiment with UTF-8 domain names 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 18.42 +0900 01-01-06, Martin J. Duerst wrote: >- Expecting that every single software component that > will deal with internationalized domain names will > do name preparation on every processing step is not > realistic (Patrick, I'm not saying that you have such > expectations, I just want to make sure others don't). I agree completely with this. My point in all of this discussion is exactly that, that we _have_ to change software regardless of what we decide, to get full IDN functionality -- and because of this, we will live in a world where people have not upgraded their software yet, so backward compatibility is really important. Some examples I use involve my own name which is Patrik H:son Fältström If you look closely, you will see that "H:son" might be problematic to have as a domain part because of the colon, and the 'ä' can be written in two ways, which are equal according to the normalization forms defined by the Unicode Consortium. One of the ways will probably be used in Sweden more (where the 'ä' is a special character) and another outside of Sweden (where the 'ä' is an accented 'a'). Martin gives another good example which is the full-width and half-width characters. This is not easy, and claiming that "this works already if we choose UTF-8 encoded Unicode is too naive. What I said some mail ago was that "what the encoding of Unicode is, UTF-8 or ACE, is the simple part of this puzzle -- and the big difference is that an ACE encoding guarantees that the encoded words work in the application protocols we have today". I still claim that is the case. paf From owner-idn@ops.ietf.org Sat Jan 6 09:07:11 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15567 for ; Sat, 6 Jan 2001 09:07:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Etj2-0004Sm-00 for idn-data@psg.com; Sat, 06 Jan 2001 05:49:40 -0800 Received: from h00508b5474ca.ne.mediaone.net ([24.91.78.68] helo=BILL) by psg.com with esmtp (Exim 3.16 #1) id 14Etj1-0004Sg-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 05:49:39 -0800 Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Sat, 6 Jan 2001 08:48:31 -0500 Message-Id: <3.0.5.32.20010106084830.03eea5b0@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 06 Jan 2001 08:48:30 -0500 To: idn@ops.ietf.org From: "J. William Semich" Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: References: <200101051007.f05A7ll14252@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 09:24 AM 1/6/01 +0100, Patrik F=E4ltstr=F6m wrote: < >I.e. I could register one day maybe: > > f=E4ltstr=F6m.com > >...but could also on my business card have (if the ACE ends up being RACE): > > bq--abtoi3duon2hf5tn .com > >Yes, it looks ugly, ... Not to mention it would be hard for most people to remember. It looks a lot simpler to put "patrik@MS Sans Serif208.184.130.48" on your business card as the "ASCII alternative", and probably is much easier to remember. Exposing ACE to users begins to defeat the whole idea of using meaningful "domain names", ASCII or UNICODE, to simplify identification of hosts because "you can't remember all those numbers." Numbers suddenly look a lot easier to remember than the ACE equivalences, I expect, ignoring the "portability" issue. Bill Bill Semich President and Founder WorldNames, Inc. http://www.worldnames.net bsemich@worldnames.net From owner-idn@ops.ietf.org Sat Jan 6 09:30:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15660 for ; Sat, 6 Jan 2001 09:30:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Eu8t-0006XP-00 for idn-data@psg.com; Sat, 06 Jan 2001 06:16:23 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14Eu8s-0006XJ-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 06:16:22 -0800 Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA20338; Sat, 6 Jan 2001 09:16:03 -0500 (EST) Message-Id: <200101061416.JAA20338@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Martin J. Duerst" cc: Keith Moore , "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-reply-to: Your message of "Sat, 06 Jan 2001 19:06:46 +0900." <4.2.0.58.J.20010106184428.03a85850@sh.w3.mag.keio.ac.jp> Date: Sat, 06 Jan 2001 09:14:48 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > At 01/01/05 15:21 -0500, Keith Moore wrote: > > > Do you also think that putting up web pages and reading them are the > > > ``wrong things''? > > > >yes. try putting up web pages with links to URLs containing IDNs > >which are encoded in UTF-8 (using various URL prefixes and various > >protocols with servers on a variety of platforms) and seeing whether > >those links work in various browsers. Then try putting URLs > >containing IDNs into text files, mailing them around, and using > >cut-and-paste to enter them into a broswer's "get URL" dialog box. > >Then try printing URLs containing IDNs on business cards, and typing > >them in to browsers dialog boxes. > > Keith, are you assuming that we are doing all this work so > that people can put 'ace--blah' into their URIs, mail them > around, put them in their 'location:' fields, and so on? no. you're correct in saying that - at least in email - all of the necessary standards are in place. whether the deployed implementations support those standards is a completely different question. my point is that IDNs (and URIs containing IDNs) will be passed around from one program to another via a variety of means - including protocols, cut-and-paste, and human transcription. due to (in some cases) lack of protocol support (in others) different things being upgraded at different times, some of those programs will be able to input, or display IDNs natively, and some will not. the primary reason for using ACE is within protocols - i.e. in contexts that most humans do not see. but we of course realize that ACE-encoded IDNs will leak into contexts that humans do see, just as native IDNs will leak into protocols that cannot deal with UTF8. and those IDNs will get passed to other protocols. the point I was making in my message to Dan is that the success or failure of whatever scheme we choose for IDNs will be determined by the degree to which things fail when IDNs get passed around in a wide variety of ways. we therefore cannot predict success or failure by only looking at one or two test cases with one or two implementations of a single protocol. > >a strategy for minimal disruption is: > > > >- affect as few components as possible (since the effort required to > > deal with breakage is on a per-component basis rather than a > > per-line-of-code basis) > > If it's by component, I doubt that ACE is better than UTF-8. > ACE needs a lot of special considerations, scripts that have > to be fixed, and so on, in order to work. we need to look at this more carefully then, and choose an ACE which is unlikely to break things that currently deal successfully with domain names. this is of paramount concern. > >- put most of the burden of upgrading on those who benefit most > > I'm not sure I agree with this. First of all, it implies that > internationalized domain names have to be usable everywhere, > immediately. I don't think that's really the demand we are > facing. depends on what you mean by 'usable'. I think IDNs need to provide minimum disruption everwhere, immediately. but my point is that those who benefit most from being able to input or display IDNs are the ones who are most likely to be willing to upgrade their applications. if we adopted a scheme that required *everyone* to upgrade to new applications - regardless of whether they saw any benefit from IDNs - it would be more likely to result in pushback against IDNs. > >I think it's the other way around. people will not give up their > >favorite tools en masse in favor of unfamiliar tools that support UTF-8, > > They don't have to. On unix, the general thing you will have to > do is to create aliases or wrapper shell scripts for your editor > to either set the locale to work with UTF-8 or to convert the > file to the encoding your editor can handle and back. I suspect that most UNIX users are unwilling to do even this much - they'd have to remember to run a different command when editing a UTF-8 file than when editing a normal file. though perhaps emacs would acquire a UTF-8 mode that would automagically detect UTF-8 - that's quite doable. > Do you expect editors that can handle ACE transparently to become prominent? > Do you think it is sufficient to handle ACE as ASCII? Depends on what you mean by 'sufficient'. But a lot of people, if faced with the choice between using a new tool (or a new script) and handling IDNs in ACE format, would choose the latter. > >especially when their existing files are in other formats. And changing > >to a new xterm won't automatically make the old tools work (actually > >it will probably break some tools that expect each character takes one > >octet). > > First, UTF-8 is *extremely* well designed to work in most cases even > for such tools (shell scripts, filter programs,...). If you can give > a concrete example of such a breakage in such kinds of programs, > I would appreciate it. I agree that UTF-8 is quite well designed, but it does break the common assumption that all characters are a single octet. anything that uses '.' in a regular expression to match a single character will fail given UTF-8 as input, as will anything that tries to parse input by columns. Keith From owner-idn@ops.ietf.org Sat Jan 6 09:40:59 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15727 for ; Sat, 6 Jan 2001 09:40:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EuNg-0007Yv-00 for idn-data@psg.com; Sat, 06 Jan 2001 06:31:40 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14EuNf-0007Yp-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 06:31:39 -0800 Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA20590; Sat, 6 Jan 2001 09:31:34 -0500 (EST) Message-Id: <200101061431.JAA20590@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Martin J. Duerst" cc: RJ Atkinson , "J. William Semich" , idn@ops.ietf.org Subject: Re: [idn] What's wrong with skwan-utf8? In-reply-to: Your message of "Sat, 06 Jan 2001 19:08:38 +0900." <4.2.0.58.J.20010106190820.035f07c0@sh.w3.mag.keio.ac.jp> Date: Sat, 06 Jan 2001 09:30:19 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Sorry, but none of them handles ACE correctly. you mean they cannot input or display ASCII? From owner-idn@ops.ietf.org Sat Jan 6 10:58:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16077 for ; Sat, 6 Jan 2001 10:58:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EvW8-000DSo-00 for idn-data@psg.com; Sat, 06 Jan 2001 07:44:28 -0800 Received: from attila.bofh.it ([213.92.8.2] ident=postfix) by psg.com with esmtp (Exim 3.16 #1) id 14EvW7-000DSi-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 07:44:27 -0800 Received: by attila.bofh.it (Postfix, from userid 10) id 7176E5FFD2; Sat, 6 Jan 2001 16:44:32 +0100 (CET) Received: by wonderland.linux.it (Postfix/Md, from userid 1001) id 4AF7017EDB; Sat, 6 Jan 2001 15:33:03 +0100 (CET) Date: Sat, 6 Jan 2001 15:33:03 +0100 From: "Marco d'Itri" Cc: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names Message-ID: <20010106153302.A1896@wonderland.linux.it> References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.12i In-Reply-To: ; from paf@cisco.com on Sat, Jan 06, 2001 at 01:27:08PM +0100 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Jan 06, Patrik Fältström wrote: >>- Expecting that every single software component that >> will deal with internationalized domain names will >> do name preparation on every processing step is not >> realistic >I agree completely with this. Maybe this is a good argument for doing nameprep in the resolver? -- ciao, Marco From owner-idn@ops.ietf.org Sat Jan 6 11:10:47 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16129 for ; Sat, 6 Jan 2001 11:10:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EviP-000ESQ-00 for idn-data@psg.com; Sat, 06 Jan 2001 07:57:09 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EviO-000ESK-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 07:57:08 -0800 Received: from enoshima (ppp3ppp34.sfc.keio.ac.jp [133.27.12.100]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id AAA06041; Sun, 7 Jan 2001 00:57:51 +0900 (JST) Message-Id: <4.2.0.58.J.20010107000910.0360b220@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 07 Jan 2001 00:11:37 +0900 To: Keith Moore From: "Martin J. Duerst" Subject: Re: [idn] What's wrong with skwan-utf8? Cc: RJ Atkinson , "J. William Semich" , idn@ops.ietf.org In-Reply-To: <200101061431.JAA20590@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01/01/06 09:30 -0500, Keith Moore wrote: > > Sorry, but none of them handles ACE correctly. > >you mean they cannot input or display ASCII? This is out of context. But anyway, in many contexts, I do not consider that ACE is handled correctly if it's just being passed around as ASCII. If we want to bother users with weird ASCII domain names, we can do that without an IETF WG. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 11:10:54 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16140 for ; Sat, 6 Jan 2001 11:10:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Evi9-000EOn-00 for idn-data@psg.com; Sat, 06 Jan 2001 07:56:53 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14Evi8-000EOO-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 07:56:52 -0800 Received: from enoshima (ppp3ppp34.sfc.keio.ac.jp [133.27.12.100]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id AAA05955; Sun, 7 Jan 2001 00:57:22 +0900 (JST) Message-Id: <4.2.0.58.J.20010107001149.03601eb0@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 07 Jan 2001 00:56:10 +0900 To: Keith Moore From: "Martin J. Duerst" Subject: Re: [idn] An experiment with UTF-8 domain names Cc: Keith Moore , "D. J. Bernstein" , idn@ops.ietf.org In-Reply-To: <200101061416.JAA20338@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01/01/06 09:14 -0500, Keith Moore wrote: >no. you're correct in saying that - at least in email - all of the >necessary standards are in place. whether the deployed implementations >support those standards is a completely different question. They support them to the degree that native users can send around text in their own language. That support is very solid, otherwise email wouldn't exist in some places at all. What is missing is Japanese mailers being able to do Arabic,..., but that's secondary. >the primary reason for using ACE is within protocols - i.e. >in contexts that most humans do not see. but we of course >realize that ACE-encoded IDNs will leak into contexts that >humans do see, just as native IDNs will leak into protocols >that cannot deal with UTF8. and those IDNs will get passed >to other protocols. It's not necessarily needed that protocols deal with UTF-8. Mail and Web pages are typical cases. If I send a mail in iso-2022-jp or put up a web page in iso-8859-1, the IDNs will be in these encodings, not in UTF-8. Everything else, including ACE, would be wrong. And that already works (Again with the problem that you can't put an ARABIC domain name into an iso-2022-jp mail. But you can put it in a web page using the &#dddd; syntax.) > > >a strategy for minimal disruption is: > > > > > >- affect as few components as possible (since the effort required to > > > deal with breakage is on a per-component basis rather than a > > > per-line-of-code basis) > > > > If it's by component, I doubt that ACE is better than UTF-8. > > ACE needs a lot of special considerations, scripts that have > > to be fixed, and so on, in order to work. > >we need to look at this more carefully then, and choose an ACE >which is unlikely to break things that currently deal >successfully with domain names. this is of paramount concern. It's not really a question of which ACE to pick. Scripts are in many ways at the boundary of the protocols and the user. That means that a lot of conversion between ACE and something readable will have to go on. For ACE, all of this will have to be hand-knitted, because you will continuously have to parse the data to separate domain names from other stuff. In many ways, we will get into a very NAT-like situation. NAT can be dealt with by knowing exactly what's going on on the wire, for each and every protocol, in particular to know all the places where internet addresses turn up. But it has turned out that this isn't feasible. ACE depends on knowing exactly where domain names turn up. The only difference is that the problem is not on the wire, it's at each end, but it's nevertheless a mess. For UTF-8, things just go through. If you want to use another encoding, you don't have to know where the domain names are, you can convert everything, including comments,... > > >I think it's the other way around. people will not give up their > > >favorite tools en masse in favor of unfamiliar tools that support UTF-8, > > > > They don't have to. On unix, the general thing you will have to > > do is to create aliases or wrapper shell scripts for your editor > > to either set the locale to work with UTF-8 or to convert the > > file to the encoding your editor can handle and back. > >I suspect that most UNIX users are unwilling to do even this much - >they'd have to remember to run a different command when editing >a UTF-8 file than when editing a normal file. The alternative is to have the files in the encoding of their preference, and insert an additional step in situations such as when loading a zone file. The important point is that users and administrators will with close to absolute certainty prefer to edit text they can read and understand rather than ACEed stuff. And for this, UTF-8 is much less painful than ACE. >though perhaps emacs >would acquire a UTF-8 mode that would automagically detect UTF-8 - >that's quite doable. That has already been done. See e.g. http://packages.debian.org/stable/editors/mule-ucs.html > > Do you expect editors that can handle ACE transparently to become > prominent? > > Do you think it is sufficient to handle ACE as ASCII? > >Depends on what you mean by 'sufficient'. But a lot of people, if faced >with the choice between using a new tool (or a new script) and handling >IDNs in ACE format, would choose the latter. Not in Japan, not in any other place of the world where people actually can read and understand these characters. Or would you prefer to edit configuration files in nonsense sequences of Greek characters rather than define and use an alias or two? And if you think you would prefer it that way, do you think that that's what people would prefer in general? Very hard for me to believe! >I agree that UTF-8 is quite well designed, but it does break the common >assumption that all characters are a single octet. Which is anyway wrong in large parts of the world. >anything that uses >'.' in a regular expression to match a single character will fail given >UTF-8 as input, Yes. But how many such regular expressions do you expect for handling domain names? Can you give a reasonable example? >as will anything that tries to parse input by columns. Good point. But not exactly. The problems will appear if applications that assume one octet=one column position and applications that assume one character=one column position get combined. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 11:11:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16155 for ; Sat, 6 Jan 2001 11:11:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EviB-000EOv-00 for idn-data@psg.com; Sat, 06 Jan 2001 07:56:55 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EviA-000EOm-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 07:56:54 -0800 Received: from enoshima (ppp3ppp34.sfc.keio.ac.jp [133.27.12.100]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id AAA06038; Sun, 7 Jan 2001 00:57:48 +0900 (JST) Message-Id: <4.2.0.58.J.20010106235642.03609940@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 07 Jan 2001 00:24:32 +0900 To: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?= , idn@ops.ietf.org From: "Martin J. Duerst" Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: References: <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> <20010105184141.18748.qmail@cr.yp.to> <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01/01/06 13:27 +0100, Patrik F$BgM(Btstr$B‹N(B wrote: >My point in all of this discussion is exactly that, that we _have_ to >change software regardless of what we decide, to get full IDN >functionality -- and because of this, we will live in a world where people >have not upgraded their software yet, so backward compatibility is really >important. > >Some examples I use involve my own name which is > > Patrik H:son F$BgM(Btstr$B‹N(B > >If you look closely, you will see that "H:son" might be problematic to >have as a domain part because of the colon, and the '$Bg(B can be written in >two ways, which are equal according to the normalization forms defined by >the Unicode Consortium. One of the ways will probably be used in Sweden >more (where the '$Bg(B is a special character) and another outside of Sweden >(where the '$Bg(B is an accented 'a'). No, the data will almost always contain the precombined version as it is used in Sweden. This is independent of what people think about it or how they may input it, where you can indeed see quite some difference. So for this case, normalization is mainly needed to avoid surprises in very rare and strange cases, not to bring too variants together. >Martin gives another good example which is the full-width and half-width >characters. This is much more of a problem, because both exist side-by-side, at least in Japan. >This is not easy, and claiming that "this works already if we choose UTF-8 >encoded Unicode is too naive. > >What I said some mail ago was that "what the encoding of Unicode is, UTF-8 >or ACE, is the simple part of this puzzle -- and the big difference is >that an ACE encoding guarantees that the encoded words work in the >application protocols we have today". I still claim that is the case. Well, let's try with some picture. ACE assures that all cars can pass all tunnels by squeezing them together in a way that makes them look like bikes. They pass, but they are not cars anymore, and you have to be really lucky if somebody can help you to make a car again out of a bike that came through the tunnel. And even if the tunnels get wider, we will still squeeze all cars in the future. Of course, that's only half of the story; it may be worth noting that in principle, all tunnels nowadays are wide enough for cars, indeed it's easier to build wide tunnels, but there are some extremely old tunnels still remaining, and there are still some engineers that, by accident or whatever, that don't clean up their tunnels. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 11:20:26 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16194 for ; Sat, 6 Jan 2001 11:20:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Evpz-000F0L-00 for idn-data@psg.com; Sat, 06 Jan 2001 08:04:59 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14Evpy-000F0E-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 08:04:58 -0800 Received: from enoshima (ppp3ppp34.sfc.keio.ac.jp [133.27.12.100]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id BAA06104; Sun, 7 Jan 2001 01:04:57 +0900 (JST) Message-Id: <4.2.0.58.J.20010107010031.038d2100@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 07 Jan 2001 01:03:43 +0900 To: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?= , "James Seng/Personal" , "D. J. Bernstein" , From: "Martin J. Duerst" Subject: Re: [idn] What's wrong with skwan-utf8? Cc: In-Reply-To: References: <4.2.0.58.J.20001227171746.02e6aae0@sh.w3.mag.keio.ac.jp> <4.2.0.58.J.20001227171746.02e6aae0@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01/01/03 16:37 +0100, Patrik F$BgM(Btstr$B‹N(B wrote: >Existing implementations of UTF-8 will not be possible to use, so we have >to update quite some amount of code regardless of what solution is chosen. Nameprep is needed at one or two crucial points; for the rest, off-the-shelf UTF-8 tools can be used. >Also, I want you to please differentiate between implementations of >standards and the standards themselves. RFC 821 took 6 years to clearify >in RFC 2821... Well, UTF-8 is also being clarified; some clarifications happened just recently. I'd hope we could avoid the same timespan for ACE. If all the intellectual energy that currently went into various ACE proposals went into upgrading protocols and implementations for UTF-8, we would already be quite a bit ahead. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 11:49:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16292 for ; Sat, 6 Jan 2001 11:49:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EwOL-000IHx-00 for idn-data@psg.com; Sat, 06 Jan 2001 08:40:29 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14EwOL-000ICR-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 08:40:29 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29619; Sat, 6 Jan 2001 08:40:07 -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 f06GdwR00415; Sat, 6 Jan 2001 08:39:58 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05712; Sat, 6 Jan 2001 08:39:29 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3.0.5.32.20010106084830.03eea5b0@mail.nic.nu> References: <200101051007.f05A7ll14252@malmo.trab.se> <3.0.5.32.20010106084830.03eea5b0@mail.nic.nu> Date: Sat, 6 Jan 2001 17:36:01 +0100 To: "J. William Semich" , idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] An experiment with UTF-8 domain names Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 08.48 -0500 01-01-06, J. William Semich wrote: >Not to mention it would be hard for most people to remember. That was my point when I said that people would try to use the original IDN version. >It looks a lot simpler to put "patrik@208.184.130.48" on your >business card as the "ASCII alternative", and probably is much >easier to remember. But, that would not work if not the top level domain "48" exists. If it was an IPv4 address literal you wanted to write it is syntactically wrong (you forgot the '[' and ']') and even if that was what you wanted that would not work either as the IP address change quite often for my mail host. paf From owner-idn@ops.ietf.org Sat Jan 6 11:54:09 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16315 for ; Sat, 6 Jan 2001 11:54:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EwOl-000IIE-00 for idn-data@psg.com; Sat, 06 Jan 2001 08:40:55 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14EwOk-000IHq-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 08:40:54 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29776; Sat, 6 Jan 2001 08:40:27 -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 f06GeIH00536; Sat, 6 Jan 2001 08:40:18 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05748; Sat, 6 Jan 2001 08:40:03 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010106153302.A1896@wonderland.linux.it> References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> <20010106153302.A1896@wonderland.linux.it> Date: Sat, 6 Jan 2001 17:38:29 +0100 To: "Marco d'Itri" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] An experiment with UTF-8 domain names 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 15.33 +0100 01-01-06, Marco d'Itri wrote: >On Jan 06, Patrik F”ltstr–m wrote: > > >>- Expecting that every single software component that > >> will deal with internationalized domain names will > >> do name preparation on every processing step is not > >> realistic > >I agree completely with this. >Maybe this is a good argument for doing nameprep in the resolver? Definitly _NO_ as the domain part is used not only in the DNS protocol but also in the various application protocols that exist, such as SMTP and HTTP. The nameprep have to be done on a higher level than in the resolver. If your point was that the operating system (standard libraries or wherever) should have such a conversion routine which should be called by any program when using IDN domain names wherever, yes, I agree with you. paf From owner-idn@ops.ietf.org Sat Jan 6 13:14:42 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16667 for ; Sat, 6 Jan 2001 13:14:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ExcT-000PNz-00 for idn-data@psg.com; Sat, 06 Jan 2001 09:59:09 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14ExcS-000PIO-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 09:59:08 -0800 Received: from admin1.corp.walid.com (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with ESMTP id RAA30484; Sat, 6 Jan 2001 17:55:17 GMT Date: Sat, 6 Jan 2001 17:55:17 +0000 (GMT) From: "Brian W. Spolarich" X-Sender: briansp@admin1.corp.walid.com To: "Martin J. Duerst" cc: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: <4.2.0.58.J.20010106184428.03a85850@sh.w3.mag.keio.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Sat, 6 Jan 2001, Martin J. Duerst wrote: | Do you expect editors that can handle ACE transparently to become | prominent? | | Do you think it is sufficient to handle ACE as ASCII? I'm not sure that this behaviour is a requirement. Applications should be able to deal with IDNs in native scripts (codepage or hopefully Unicode). Applications and/or resolvers will need to do the job of IDN (to Unicode) to nameprepped Unicode to ACE conversion, ensuring that what goes on the wire is ASCII. It sounds like there is a diversity of opinion as to where the IDN processing will happen, and how far up and down the stack the ACE handling will go. -bws From owner-idn@ops.ietf.org Sat Jan 6 13:15:52 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16682 for ; Sat, 6 Jan 2001 13:15:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Exhi-000PqA-00 for idn-data@psg.com; Sat, 06 Jan 2001 10:04:34 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14Exhh-000PlS-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 10:04:34 -0800 Received: from admin1.corp.walid.com (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with ESMTP id SAA30601; Sat, 6 Jan 2001 18:01:17 GMT Date: Sat, 6 Jan 2001 18:01:17 +0000 (GMT) From: "Brian W. Spolarich" X-Sender: briansp@admin1.corp.walid.com To: "J. William Semich" cc: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: <3.0.5.32.20010106084830.03eea5b0@mail.nic.nu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Sat, 6 Jan 2001, J. William Semich wrote: | >...but could also on my business card have (if the ACE ends up being | RACE): | > bq--abtoi3duon2hf5tn .com | | >Yes, it looks ugly, ... | | Not to mention it would be hard for most people to remember. I don't think this is in reality a requirement. If you decide to put an IDN on your business card, some people may have problems using it, but I would suspect rather quickly that most users, particularly non-English speakers, will become aware that they will need to update their software to use these names. Its sort of like the situation you had a few years ago when URLs and e-mail addresses started appearing on business cards. Many people who received those cards weren't able to use those new identifiers as they didn't have e-mail or web access. This I think helped encourage more rapid adoption of those technologies. Something similar will probably happen with IDN. Probably a common scenario will be a non-technical person receiving a business card with an IDN on it. They'll try to type the name into their browser, and it will fail to resolve. They'll contact their IT support staff, who will tell them what they need to do to use the IDN (and educate them a little bit on this 'new thing'), they'll update their software as required, and they'll move on. Its not clear to me that you really need to expose ACE in a context like this. -bws From owner-idn@ops.ietf.org Sat Jan 6 13:55:34 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16913 for ; Sat, 6 Jan 2001 13:55:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EyC0-0002hA-00 for idn-data@psg.com; Sat, 06 Jan 2001 10:35:52 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14EyBz-0002h1-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 10:35:51 -0800 Received: from enoshima (ppp3ppp84.sfc.keio.ac.jp [133.27.12.150]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id DAA06422; Sun, 7 Jan 2001 03:36:29 +0900 (JST) Message-Id: <4.2.0.58.J.20010105221107.009e1620@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 07 Jan 2001 03:00:53 +0900 To: Kenneth Whistler , briansp@walid.com From: "Martin J. Duerst" Subject: Re: [idn] What's wrong with skwan-utf8? Cc: idn@ops.ietf.org In-Reply-To: <200101041914.LAA24879@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Thanks Ken for explaining this clearly. A bit of follow up: At 01/01/04 11:14 -0800, Kenneth Whistler wrote: >A terminological quibble here: > > > I guess I still don't get why some people are so focused on UTF-8. > > UTF-8 is an 8-bit encoding of the UCS. ACE (whatever flavor) is a 7-bit > > encoding of the UCS. ACE is not a 7-bit encoding of the UCS. It's a two-step encoding, first from the UCS to the legacy host name repertoire, and then from there to 7-bit octets (using US-ASCII). Of course, for most people on this list, the second step is just ignored, because US-ASCII is taken for granted anyway. To get to truly solid internationalization, it is highly desirable that there is no difference between the handling of US-ASCII and non-US-ASCII characters, and in particular that the later are represented directly, and not via the former. Also, because ACE maps to ASCII, it is only a very restricted encoding of the UCS. Can you imagine a terminal emulator for ACE? An XML page starting with ? An editor that reads in a file in ACE, allows to edit it, and write it back out again? It's possible to create such things, but they won't be useful at all for IDN, because kind of data has a special pattern of where domain names appear. Regards, Martin. From owner-idn@ops.ietf.org Sat Jan 6 14:11:11 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17010 for ; Sat, 6 Jan 2001 14:11:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EyYP-0004pf-00 for idn-data@psg.com; Sat, 06 Jan 2001 10:59:01 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14EyYO-0004pY-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 10:59:00 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07590 for ; Sat, 6 Jan 2001 10:54:16 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4.2.0.58.J.20010105221107.009e1620@sh.w3.mag.keio.ac.jp> References: <4.2.0.58.J.20010105221107.009e1620@sh.w3.mag.keio.ac.jp> Date: Sat, 6 Jan 2001 10:58:00 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] What's wrong with skwan-utf8? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:00 AM +0900 1/7/01, Martin J. Duerst wrote: >Also, because ACE maps to ASCII, it is only a very restricted >encoding of the UCS. Can you imagine a terminal emulator for ACE? >An XML page starting with ? >An editor that reads in a file in ACE, allows to edit it, and >write it back out again? It's possible to create such things, >but they won't be useful at all for IDN, because kind of >data has a special pattern of where domain names appear. ACE was never meant for anything other than host name parts. Saying "it doesn't work well for things that it was not designed for" is both true and wholly irrelevant. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sat Jan 6 15:35:21 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17524 for ; Sat, 6 Jan 2001 15:35:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ezn4-000CNv-00 for idn-data@psg.com; Sat, 06 Jan 2001 12:18:14 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14Ezn2-000CNo-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 12:18:13 -0800 Received: from P2 ("port 2278"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G6R00937CEANY@a4.jck.com> for idn@ops.ietf.org; Sat, 06 Jan 2001 15:18:11 -0500 (EST) Date: Sat, 06 Jan 2001 15:18:09 -0500 From: John C Klensin Subject: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) To: "Brian W. Spolarich" Cc: idn@ops.ietf.org Message-id: <3836713798.978794289@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Saturday, 06 January, 2001 18:01 +0000 "Brian W. Spolarich" wrote: > On Sat, 6 Jan 2001, J. William Semich wrote: > > | >...but could also on my business card have (if the ACE ends > up being | RACE): > | > bq--abtoi3duon2hf5tn .com > |... > I don't think this is in reality a requirement. If you > decide to put an IDN on your business card, some people may > have problems using it, but I would suspect rather quickly > that most users, particularly non-English speakers, will > become aware that they will need to update their software to > use these names. Brian, the problem really isn't updating software but updating people -- an activity that we know, experimentally, tends to take a few generations at least. Let me use myself as an example (this one is inherently European-language-oriented, but I assume it has Asian and African analogues that are as bad or worse). If I'm handed a business card with an IDN on it, in the "native" character glyph set for that name, the next encoding step depends on my knowledge and pattern-recognition and discrimination skills, and not on any computer issues. I need to be able to take that collection of glyphs and somehow transcribe and enter them into a computer. Now, if the characters used are Latin-based, I can probably cope (and I do today). I'm going to recognize the basic structures. Even if I have to consult a table, I can match what I see on the card with what I see on the screen. In the worst case --in which I have no idea how to "type" the character-- I can then enter the character position from the table into a software program. Interestingly, for that purpose, a simple hexadecimal encoding of UCS-4 (or UCS-2) is "easier" than UTF-8 which is a good deal "easier" than ACE. While tedious, 0x000000E4 is quite easy to figure out and write. And selection of characters from tablets is not exactly a new technology; I'd expect user interface software to show up quickly and be widely deployed that uses table-selection technologies to build up strings that could then be pasted. But that is the easy part and it is conditioned on my being able to recognize Latin-based characters well enough to tell them apart. Extrapolating from it as an example is dangerous: First, I can't tell European characters apart to the degree needed by IDN. If you had me a card with a native-glyph IDN on it, I need to know the language (or a surrogate for the language) to pick the right glyphs from a table. I simply cannot tell U+0041 from U+0391 from U+0410 by looking at a glyph written on a page (and those are, of course, not the only examples). I have to know the language context, or apply heuristics, to pick one. And, if I can't be guaranteed to consistently get it right, we are going to need character-matching rules much more subtle than anything yet seriously contemplated. But that isn't the serious problem either. It turns out that I can do just about the same pattern-matching job --looking at a glyph, deducing its essential characteristics because I'm familiar with the repertorie from which it comes, finding it in a table and picking it or entering it by table position-- if that card contains Greek, Cyrillic, or Hebrew glyphs. That puts me a bit ahead of most of my American and Western European colleagues, for which those sets of glyphs may look like indistinguishable chicken-scratches. I've even been around this work long enough that I've learned to distinguish enough kana that I might be able to successfully look them up in a table (but not pronounce them), although it would take me a long time since I don't know the table order. But most Han, Kanji, and Hangul are hopeless for me: there are lots of them, I can't (in general) tell them apart, and I just don't have the pattern recognition skills (or training in distinguishing radicals) to be able to look them up, especially if the font-rendering on the business card is different from that in my table. That is not, of course, an alphabetic versus ideographic issue: I'm equally hopeless with Arabic, and Devanagari, and Bengali, and Thai, and dozens (if not hundreds) of languages and character collections, most of which I've never even seen in print. Anything I can't recognize well enough to match with a table is something I can't copy from a business card. Whether the DNS interface is UTF-8, or an ACE, or UCS-4, or some other encoding is irrelevant, and software isn't going to fix that. So, for the business card, we need, I think, to start asking different questions. If want an address on my business card to be recognized and usable, after the translator leaves, by a Thai native who lacks familiarity with Latin alphabets, I had best figure out how to get a Thai rendering (or something else recognizable) of my address on that card. And, operationally, I had better fix it so that rendering does the right thing when looked up in the DNS. Note that this is my problem and not hers: she has a problem only if I don't do something reasonable and she decides to try to communicate with my anyway. Another important inference from this story is almost certainly that a solution that works for "ASCII" and "other language" is, at least in the long term, inadequate. The same issues exist between "other language 1" and "other language 2", and the virtual business card will need to be many-sided. And that may imply that I may need many DNS identities, associated with different character sets, to be accessible from all over the world. Or we can try to turn it into an ACE-like question, where what goes on the business card is the "native" set of glyphs plus some Latin-based encoding. I'm not sure, as argued above, that there is a "native" set of glyphs for the general case. But, more important, if one is going to put an encoding on a card from which one can get back and forth from 10646/Unicode, it is not clear to me that ACE is superior to hexified UTF-8. And neither may be as convenient as hexified UCS-4 (or UCS-2) or a PGP-like biometric word list encoding. Any of these are going to require software to get from the business card form to the DNS one; the correct answer for encoding them may be different from the correct answer for what should actually go into the DNS. > Probably a common scenario will be a non-technical person > receiving a business card with an IDN on it. They'll try to > type the name into their browser, and it will fail to resolve. > They'll contact their IT support staff, who will tell them > what they need to do to use the IDN (and educate them a little > bit on this 'new thing'), they'll update their software as > required, and they'll move on. Sigh. JU: Hello, IT support staff, this is Joe User. I've got a business card in front of me with a URL on it, and I don't know how to type it in. ITSS: Just copy the letters from the card into the "Go to" box on the browser. Haven't you learned that yet? JU: But I don't recognize any of the characters.. they aren't on my keyboard. ITSS: We can send you out a keyboard for Latin-1, which covers Swedish, German, French,... and instructions for installing it. (A week later) JU: Hello, IT Support Staff, your technician put in the nice new keyboard and software. Some of my applications now say "Guten Tag", rather than "Hello", but that is ok. I still can't type that URL in, the characters still aren't on the keyboard. ITSS: Huh? What language did you say it was in? JU: Beats me. Doesn't look much like either English or Klingon. ITSS: (The next two or three exchanges are left as an exercise for the reader. You may assume, if convenient, that the IT support staff speaks Klingon and has been studying the use of the Batlef (sp?)) Sorry Brian, I don't believe "a little education, update the software, and move on" is going to do it. john From owner-idn@ops.ietf.org Sat Jan 6 16:06:41 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17742 for ; Sat, 6 Jan 2001 16:06:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14F0Gx-000FLn-00 for idn-data@psg.com; Sat, 06 Jan 2001 12:49:07 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14F0Gw-000FK8-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 12:49:06 -0800 Received: from P2 ("port 2294"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G6R00942DTQNY@a4.jck.com> for idn@ops.ietf.org; Sat, 06 Jan 2001 15:49:03 -0500 (EST) Date: Sat, 06 Jan 2001 15:49:01 -0500 From: John C Klensin Subject: Re: [idn] An experiment with UTF-8 domain names To: "Martin J. Duerst" Cc: idn@ops.ietf.org Message-id: <3838565278.978796141@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Sunday, 07 January, 2001 00:56 +0900 "Martin J. Duerst" wrote: >... > Yes. But how many such regular expressions do you expect > for handling domain names? Can you give a reasonable > example? Martin, for better or worse, there has been a trend in many organizations to reflect the flatness at the top level with flatness in subdomains. E.g., if the StupidAcme company had departments for collections and customer abuse, their IT department might set up a domain structure of collections-hostA.StupidAcme.biz collections-hostB.StupidAcme.biz customer-abuse-hostA.StupidAcme.biz customer-abuse-hostD.StupidAcme.biz rather than hostA.collections.StupidAcme.biz hostB.collections.StupidAcme.biz ... And that situation leads precisely to wildcard searches on zone files or copies of them. Emacs is probably still the most commonly-used tool for zone file editing and maintenance worldwide. This is arguably a really stupid way to use the DNS, but not one that violates protocols or over which the IETF has any control. john From owner-idn@ops.ietf.org Sat Jan 6 16:57:21 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18126 for ; Sat, 6 Jan 2001 16:57:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14F17A-000KkU-00 for idn-data@psg.com; Sat, 06 Jan 2001 13:43:04 -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 14F179-000KkA-00 for idn@ops.ietf.org; Sat, 06 Jan 2001 13:43:04 -0800 Received: from QSM3 (bzq-158-31.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G6R0037NFYIUZ@mail.bezeqint.net> for idn@ops.ietf.org; Sat, 6 Jan 2001 23:35:08 +0200 (IST) Date: Sat, 06 Jan 2001 23:37:20 +0200 From: Jonathan Rosenne Subject: RE: [idn] An experiment with UTF-8 domain names In-reply-to: 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: 8BIT 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: 8BIT I would like to note that my numeric IP address (for www.qsm.co.il) is shared with other companies hosted by my ISP and they use the domain name to sort things out. A numeric IP on my business card would not necessarily be equivalent to an ACE or IDN. Jony > -----Original Message----- > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf > Of Patrik Fältström > Sent: Saturday, January 06, 2001 6:36 PM > To: J. William Semich; idn@ops.ietf.org > Subject: Re: [idn] An experiment with UTF-8 domain names > > > At 08.48 -0500 01-01-06, J. William Semich wrote: > >Not to mention it would be hard for most people to remember. > > That was my point when I said that people would try to use the > original IDN version. > > >It looks a lot simpler to put "patrik@208.184.130.48" on your > >business card as the "ASCII alternative", and probably is much > >easier to remember. > > But, that would not work if not the top level domain "48" exists. If > it was an IPv4 address literal you wanted to write it is > syntactically wrong (you forgot the '[' and ']') and even if that was > what you wanted that would not work either as the IP address change > quite often for my mail host. > > paf > > From owner-idn@ops.ietf.org Sun Jan 7 04:01:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07137 for ; Sun, 7 Jan 2001 04:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FBB0-000Ka0-00 for idn-data@psg.com; Sun, 07 Jan 2001 00:27:42 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.16 #1) id 14FBB0-000KZu-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 00:27:42 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JYLG3X448W0000JR@mauve.mrochek.com> for idn@ops.ietf.org; Sat, 06 Jan 2001 18:34:10 -0700 (PDT) Date: Sat, 06 Jan 2001 18:33:11 -0700 (PDT) From: ned.freed@innosoft.com Subject: Re: [idn] An experiment with UTF-8 domain names In-reply-to: "Your message dated Sun, 07 Jan 2001 00:24:32 +0900" <4.2.0.58.J.20010106235642.03609940@sh.w3.mag.keio.ac.jp> To: "Martin J. Duerst" Cc: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?= , idn@ops.ietf.org Message-id: <01JYLHWKT58C0000JR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=ISO-2022-JP Content-transfer-encoding: 7BIT References: <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> <20010105184141.18748.qmail@cr.yp.to> <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010105075541.26564.qmail@cr.yp.to> <200101051440.JAA11820@astro.cs.utk.edu> <200101051007.f05A7ll14252@malmo.trab.se> <20010105075541.26564.qmail@cr.yp.to> <20010105184141.18748.qmail@cr.yp.to> <4.2.0.58.J.20010106182855.0350c840@sh.w3.mag.keio.ac.jp> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > Well, let's try with some picture. ACE assures that all cars can pass > all tunnels by squeezing them together in a way that makes them look > like bikes. They pass, but they are not cars anymore, and you have > to be really lucky if somebody can help you to make a car again > out of a bike that came through the tunnel. And even if the tunnels > get wider, we will still squeeze all cars in the future. > Of course, that's only half of the story; it may be worth noting > that in principle, all tunnels nowadays are wide enough for cars, > indeed it's easier to build wide tunnels, but there are some > extremely old tunnels still remaining, and there are still > some engineers that, by accident or whatever, that don't clean > up their tunnels. That may be your belief, but saying it is so doesn't make it true. My experiencce with this sort of stuff is extensive, and it is exactly the opposite of what you claim. Ned From owner-idn@ops.ietf.org Sun Jan 7 05:43:17 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07447 for ; Sun, 7 Jan 2001 05:43:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FCz6-000AP4-00 for idn-data@psg.com; Sun, 07 Jan 2001 02:23:32 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192]) by psg.com with esmtp (Exim 3.16 #1) id 14FCz6-000AOx-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 02:23:32 -0800 Received: from amc by arwen.cs.berkeley.edu with local (Exim 3.20 #1 (Debian)) id 14FCz5-0003z4-00; Sun, 07 Jan 2001 02:23:31 -0800 Date: Sun, 7 Jan 2001 10:23:30 +0000 To: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names Message-ID: <20010107102330.B13287@arwen.cs.berkeley.edu> References: <3836713798.978794289@P2> <200101041914.LAA24879@birdie.sybase.com> <4.2.0.58.J.20010105221107.009e1620@sh.w3.mag.keio.ac.jp> <200101061416.JAA20338@astro.cs.utk.edu> <4.2.0.58.J.20010107001149.03601eb0@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <4.2.0.58.J.20010107001149.03601eb0@sh.w3.mag.keio.ac.jp>; from duerst@w3.org on Sun, Jan 07, 2001 at 12:56:10AM +0900 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk "Martin J. Duerst" wrote: > If I send a mail in iso-2022-jp or put up a web page in iso-8859-1, > the IDNs will be in these encodings, not in UTF-8. Everything else, > including ACE, would be wrong. That's an interesting problem. People exchanging Japanese email do indeed use iso-2022-jp, not utf-8. If one of them wants to include a Japanese domain name in the body of a message (as part of a URL, for example), it would be a shame to use ACE, because it will be visible to both sender and recipient, unless the MUAs do some kludgy conversions on message bodies. On the other hand, suppose the URL in question refers to an image, and the sender wants his non-Japanese friend to see the image. If we don't use ACE, then there may not exist a charset that the sender and recipient are both able to use that's capable of representing the domain name. This suggests that users should have some way of representing any domain name using ASCII (as a last resort), regardless of what goes on the wire. This scenario raises a big question about URIs. According to RFC 2396, a URI is a sequence of characters (not bytes) from a very small repertoire (smaller than printable ASCII); this sequence of characters can be used to represent a sequence of bytes (using ASCII and %hh), which in turn could be used to represent characters from a larger repertoire, but that last mapping is not standardized. In any case, when a URI is presented to the user, the characters making up the URI itself are supposed to be shown, not the characters represented by the octets represented by the URI. If we want URIs to appear to contain non-ASCII characters, we need to alter the URI model somehow. Here are three possibilities (there may be others): 1. Use ACE, and add a rule saying that user agents should convert to/from ACE when interacting with the user. This has the advantage of changing nothing at the lower layers, but doesn't immediately answer the next obvious question: how to allow non-ASCII characters to appear in the rest of the URI. Perhaps ACE should be generalized to be usable in other parts of URIs in addition to the domain names. This approach exposes the ACE to people editing files containing URIs. 2. Change the rule about how URIs are presented to the user, so that %hh sequences (except those for excluded ASCII characters) are unescaped and interpreted as UTF-8. When URIs are obtained from the user, they must be converted to UTF-8 and escaped before being dereferenced. This has the same advantages and disadvantages as the previous approach. 3. Allow a much larger set of characters in URIs. This approach suffers from the same problem as in the non-Japanese friend scenario above. It would also require changing any protocol that embeds URIs without specifying a sufficiently expressive encoding, most notably HTTP. HTTP does not say what encoding is used for URIs; it is implicitly ASCII or an extension of ASCII. HTTP assumes ISO-8859-1 for comments and unstructured text in message headers, so it would not go without saying that 8-bit URIs are in UTF-8; that would have to be added to the spec, and who knows how existing implementations would react to 8-bit URIs. Allowing URIs to appear to contain non-ASCII characters (using any approach) is counter to the URI design goal of transcribability (the business card scenario), but if we value transcribability more than i18n then we should forget about IDN altogether. > ACE is not a 7-bit encoding of the UCS. It's a two-step encoding, > first from the UCS to the legacy host name repertoire, and then from > there to 7-bit octets (using US-ASCII). Thank you! I had missed that subtlety, but you're right, host names are not required to be represented in ASCII; they are just sequences of characters. An EBCDIC system would apply an EBCDIC-to-ASCII transformation to any outgoing host names; if ACE mapped Unicode to bytes rather than characters, the ACE host names leaving the EBCDIC system would get scrambled. John C Klensin wrote: [business-card scenario] Ouch. IDN is so difficult, maybe it's hopeless. The unaccented Latin alphabet and Arabic numerals (and a few punctuation marks) make an excellent set of characters for universal names, because it's a small set that is recognized by more humans and more machines than any other. That's surely a big part of why this set was chosen for domain names and URIs, which are intended to be usable by anyone, anywhere. A giant character set is by nature ill-suited to the task of universal naming. Perhaps we have no choice but to view IDNs as deliberately non-interoperable things, optimized for particular communities. As for the business cards, maybe people will just register two names, one native and one romanized (perhaps translated), with one being a CNAME for the other. I can't immediately think of anything easier for the people trying to use the names on the card. AMC From owner-idn@ops.ietf.org Sun Jan 7 09:16:00 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08116 for ; Sun, 7 Jan 2001 09:15:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FG9M-000E4U-00 for idn-data@psg.com; Sun, 07 Jan 2001 05:46:20 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14FG9L-000E4E-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 05:46:19 -0800 Received: from admin1.corp.walid.com (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with ESMTP id NAA03873; Sun, 7 Jan 2001 13:41:43 GMT Date: Sun, 7 Jan 2001 13:41:43 +0000 (GMT) From: "Brian W. Spolarich" X-Sender: briansp@admin1.corp.walid.com To: John C Klensin cc: idn@ops.ietf.org Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-Reply-To: <3836713798.978794289@P2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk [thanks for thinking to change the subject] On Sat, 6 Jan 2001, John C Klensin wrote: [ much Good Stuff snipped ] | Sorry Brian, I don't believe "a little education, update the software, | and move on" is going to do it. You've of course uncovered the hidden assumption in my thinking, which is that the recipient of the business card can operate in the language(s) displayed on the card. This is, as you point out, a people problem, and not a software one. Its also not clear if this problem is really ours to solve, or is solveable by us. My working problem definition for IDN is to enable rational support (and deployment of support) for UCS in the DNS. While usability, particularly in the context of a diverse and global audience, has to be carefully considered, I don't think we need to address the whole range of communication problems imposed by an increasingly globalized and interconnected world. I recall when I visited Hong Kong last year my Japanese and Chinese colleagues at UUNET gave me business cards with English on one side, Japanese or Chinese on the other. This seemed like a reasonable compromise. Its likely that this is the only version that they had available, but I could imagine a very careful global enterprise having multiple sets of cards printed with the 'flip side' language being Arabic, English, Russian, etc. depending on who the recipient was. As an aside, two-sided business cards are kind of annoying. How often do you write notes on the back of someone's card? The point here I think is that, when two parties are going to communicate, it is incumbent upon them to negotiate a common language or communications protocol. If they cannot, then communication will be extremely difficult. This is true whether we're talking about domain names/URLs on business cards, or more prosaic things like addresses, telephone numbers, etc. Being the enterprising creatures we are, I can see any number of solutions to this kind of problem. So-called 'smart paper' will be available economically within a few years. The static business card may be replaced with a 'smart' version that has multiple translations the user can switch between (or even a wireless network connection). Simpler solutions could be extensions of the practice the VIDN draft author identifies, such as having an alternative form of a domain name available in transliterated Latin characters. This begs the question of whether the Latin alphabet is the appropriate 'interchange' alphabet (and all of the cultural hegemony issues, and much history). Over a billion Chinese speakers would probably disagree. But again, is this our problem to solve? -bws From owner-idn@ops.ietf.org Sun Jan 7 16:22:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10202 for ; Sun, 7 Jan 2001 16:22:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FMgx-000Mpx-00 for idn-data@psg.com; Sun, 07 Jan 2001 12:45:27 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14FMgw-000Mnx-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 12:45:26 -0800 Received: (qmail 20403 invoked by uid 1001); 7 Jan 2001 20:44:33 -0000 Date: 7 Jan 2001 20:44:33 -0000 Message-ID: <20010107204433.27758.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein c/o James Seng" To: idn@ops.ietf.org Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) Reply-To: "D. J. Bernstein" References: <3836713798.978794289@P2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Operating systems are all going to support direct input of Unicode characters by number. The ISO standard method is Shift-Ctrl-222E for character 222E. People who put hard-to-recognize characters onto their business cards are going to add a line giving the Unicode numbers, perhaps in boxes: postmaster@S.cr.yp.to (with a contour-integral sign) +----+ postmaster@|222E|.cr.yp.to (in smaller type) +----+ The second line won't distract the people in the intended audience who recognize the contour-integral sign and have, say, Alt-S configured to produce it. End of problem. Notice that this doesn't require any extra DNS names. The conversion of Shift-Ctrl-222E to \342\210\256 is isolated inside the keyboard interface; other software doesn't have to worry about it. ---Dan From owner-idn@ops.ietf.org Sun Jan 7 17:04:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10334 for ; Sun, 7 Jan 2001 17:04:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FNQq-000Olz-00 for idn-data@psg.com; Sun, 07 Jan 2001 13:32:52 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14FNQp-000Olo-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 13:32:51 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03387 for ; Sun, 7 Jan 2001 13:28:01 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010107204433.27758.qmail@cr.yp.to> References: <3836713798.978794289@P2> <20010107204433.27758.qmail@cr.yp.to> Date: Sun, 7 Jan 2001 13:31:46 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 8:44 PM +0000 1/7/01, D. J. Bernstein said: >People who put hard-to-recognize characters onto their business cards >are going to add a line giving the Unicode numbers, perhaps in boxes: *Are* going to?! It is incredibly presumptuous of anyone, even Dan Bernstein, to say what people all over the world are going to do on their business cards. > > postmaster@S.cr.yp.to (with a contour-integral sign) > > +----+ > postmaster@|222E|.cr.yp.to (in smaller type) > +----+ That almost works for host names that contain a single non-ASCII character. A typical company name in Arabic, for example, might have ten non-ASCII characters, and the TLD might contain another five (yes, we should be assuming longer TLDs that contain country names that use non-ASCII characters!). So, the proposition is that the translation from 15 characters in the "real" address will expand to 60 characters, plus "perhaps boxes" around each set of four characters. This might barely work for Europeans; it is unworkable for the majority of the world. >End of problem. For your host name; others might have a few more problems than you. Maybe the IETF should work a bit harder on a solution that meets the needs of more than a tiny audience. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Sun Jan 7 18:01:11 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10479 for ; Sun, 7 Jan 2001 18:01:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FOKD-0001RC-00 for idn-data@psg.com; Sun, 07 Jan 2001 14:30:05 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14FOKC-0001Qp-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 14:30:04 -0800 Received: (qmail 25643 invoked by uid 1001); 7 Jan 2001 22:29:17 -0000 Date: 7 Jan 2001 22:29:17 -0000 Message-ID: <20010107222917.4166.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein c/o James Seng" To: idn@ops.ietf.org Subject: [idn] Where will we see bad domain names? Reply-To: "D. J. Bernstein" References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Why do we need name preparation in applications? I'm not saying the nameprep work is useless. We should provide a program to detect bad names: names with confusing characters, or with uppercase characters, or that aren't KC-normalized. Registries will then prohibit bad names. But what will go wrong if these rules are hidden from applications? Why should a typical application worry about bad names? Good names will be accurately copied by cut-and-paste. When will bad names show up? Mark Davis writes: > The chances that the average application would, by chance, duplicate > the same normalization is minimal. You're saying that a user will see a good name on paper, type it into his computer in his favorite way, and end up with a bad name that looks the same. Can you please give some real examples? What were the good names? What keyboard-interface software was involved? What did the user type? Why didn't the user end up with good names? Was it a bug in the software? Perhaps there's a need for a tool that fixes bad Chinese domain names. However, I don't see why this conversion should be stuck into every piece of software that reads domain names from configuration files. ---Dan P.S. RFC 1034 says ``When you receive a domain name or label, you should preserve its case.'' Are we going to scrap this part of RFC 1034, and encourage clients to fold case for ASCII characters? Or are we going to say that the case of ASCII characters should be preserved? Of course, for interoperability, DNS software and mail software and so on will continue _comparing_ ASCII characters without regard to case. From owner-idn@ops.ietf.org Sun Jan 7 19:04:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10629 for ; Sun, 7 Jan 2001 19:04:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FPP1-0004y2-00 for idn-data@psg.com; Sun, 07 Jan 2001 15:39:07 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14FPP0-0004xv-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 15:39:06 -0800 Received: (qmail 24475 invoked by uid 1001); 7 Jan 2001 23:38:18 -0000 Date: 7 Jan 2001 23:38:18 -0000 Message-ID: <20010107233818.3880.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein c/o James Seng" To: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names Reply-To: "D. J. Bernstein" References: <200101051007.f05A7ll14252@malmo.trab.se> <20010105184141.18748.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Oldfield writes: > although it would look odd, If you think that incorrectly displayed IDNs are acceptable, why are you here? You can move from mail.tc to fifth-word-is-ace-xyzzy-mail.tc, and we'll pretend that xyzzy has some accents in it. They aren't displayed as accents, but that doesn't matter to you! > Am I right in thinking that UTF-8 style IDNs are used then Boris and > Ivan can't communicate What you mean here is that Ivan can't send mail to Boris's IDN. > unless Ivan can persuade his ISP to upgrade his sendmail, Maybe, maybe not. The specific problem is that sendmail discards bytes \200 through \237. This doesn't affect the UTF-8 encodings of the lowercase characters that you can find in 8859-1. For example, a-circumflex is \303\242. But I don't find this situation acceptable. sendmail has to be fixed or replaced. Note that USENET messages now use UTF-8 in the header and are often gatewayed verbatim to mail, so sendmail has to be fixed no matter what happens with IDNs. > but an ACE would only need Ivan to upgrade his mail client ? By saying ``only,'' you are implying that UTF-8 IDNs require a client upgrade. In fact, there are already clients that handle UTF-8 IDNs. Certainly ACE IDNs require a mail client upgrade. When the mail client sees a From line with an ACE IDN, it has to display some international characters for the user. Now, your question is whether ACE IDNs require a sendmail upgrade, if the system administrator doesn't need IDNs in his configuration files, and if addresses in outgoing messages are converted to ACE by the MUA. The answer is still yes, because sendmail often copies domain names into text that users are supposed to read. ---Dan From owner-idn@ops.ietf.org Sun Jan 7 19:56:34 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10742 for ; Sun, 7 Jan 2001 19:56:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FQBz-0007PV-00 for idn-data@psg.com; Sun, 07 Jan 2001 16:29:43 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14FQBy-0007PM-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 16:29:42 -0800 Received: (qmail 16406 invoked by uid 1001); 8 Jan 2001 00:28:55 -0000 Date: 8 Jan 2001 00:28:55 -0000 Message-ID: <20010108002855.20166.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein c/o James Seng" Reply-To: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: <200101052022.PAA15331@astro.cs.utk.edu> Sender: owner-idn@ops.ietf.org Precedence: bulk UNIX is switching to UTF-8. I said a bit about the cost of this conversion. I commented that ACE IDNs wouldn't reduce this cost. ``You haven't said anything to support this argument,'' Keith wrote. Do you believe that standardizing ACE IDNs will stop UNIX from switching to UTF-8, Keith? Will it also return us to the age of 16-bit processors, and give us tidy houses with porches and yards and white picket fences? Or do you believe that standardizing ACE will somehow reduce the cost of the switch? If so, how? Exactly what cost will we avoid? Do you believe that we won't have to install X Unicode fonts, for example, because ACE IDNs will shield us from the plague of un-American characters? Keith Moore writes: > (and your trial produced a failure, you just refuse to recognize it) Keith, when you refer to a successful experiment as a ``failure'' merely because it used protocol extensions that haven't been approved by the IESG, could you please surround your comments by and ? Thanks. > "costs and benefits" are highly subjective Tell that to the users who have suffered needlessly because of your previous protocol design screwups, Keith. ---Dan From owner-idn@ops.ietf.org Sun Jan 7 22:03:44 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12144 for ; Sun, 7 Jan 2001 22:03:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FSET-000Fiq-00 for idn-data@psg.com; Sun, 07 Jan 2001 18:40:25 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14FSES-000Ffn-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 18:40:25 -0800 Received: from astro.cs.utk.edu (astro.cs.utk.edu [128.169.93.168]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA03758; Sun, 7 Jan 2001 21:40:16 -0500 (EST) Message-Id: <200101080240.VAA03758@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] An experiment with UTF-8 domain names In-reply-to: Your message of "08 Jan 2001 00:28:55 GMT." <20010108002855.20166.qmail@cr.yp.to> Date: Sun, 07 Jan 2001 21:39:01 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk Dan, Even if "UNIX" switches to UTF-8 there will still be legacy systems, legacy application codes, and legacy text files, in use for many years. It's not as if everybody will upgrade en masse. Keith From owner-idn@ops.ietf.org Sun Jan 7 22:29:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12286 for ; Sun, 7 Jan 2001 22:29:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FSll-000I6V-00 for idn-data@psg.com; Sun, 07 Jan 2001 19:14:49 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192]) by psg.com with esmtp (Exim 3.16 #1) id 14FSlk-000I6O-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 19:14:48 -0800 Received: from amc by arwen.cs.berkeley.edu with local (Exim 3.20 #1 (Debian)) id 14FSlj-0007qx-00; Sun, 07 Jan 2001 19:14:47 -0800 Date: Mon, 8 Jan 2001 03:14:47 +0000 To: idn@ops.ietf.org Subject: Re: [idn] The Business Card problem Message-ID: <20010108031447.B29921@arwen.cs.berkeley.edu> References: <3836713798.978794289@P2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from briansp@walid.com on Sun, Jan 07, 2001 at 01:41:43PM +0000 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk "Brian W. Spolarich" wrote: > This begs the question of whether the Latin alphabet is the > appropriate 'interchange' alphabet... Over a billion Chinese speakers > would probably disagree. Why would they? Chinese speakers would like to use Chinese characters when communicating with other Chinese speakers, but when they're communicating with non-Chinese speakers, Chinese characters are pretty useless. What symbols would they choose to use then? Do you think there are some symbols other than the Latin letters and Arabic numerals that would be easier for them? AMC From owner-idn@ops.ietf.org Sun Jan 7 22:37:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13238 for ; Sun, 7 Jan 2001 22:37:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FSs3-000IWR-00 for idn-data@psg.com; Sun, 07 Jan 2001 19:21:19 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192]) by psg.com with esmtp (Exim 3.16 #1) id 14FSs2-000IWL-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 19:21:18 -0800 Received: from amc by arwen.cs.berkeley.edu with local (Exim 3.20 #1 (Debian)) id 14FSs2-0007ra-00; Sun, 07 Jan 2001 19:21:18 -0800 Date: Mon, 8 Jan 2001 03:21:17 +0000 To: idn working group Subject: [idn] internationalized email addresses Message-ID: <20010108032117.C29921@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk It just occurred to me that once people can put Unicode characters into domain names, they'll also want to put them before the @-sign in email addresses. How is that going to work? I'm not sure it makes sense to try to allow Unicode characters in domain names without simultaneously thinking about how to allow them in the other parts of email addresses and URIs. Are there other name/address-like things that need to be considered as well? AMC From owner-idn@ops.ietf.org Sun Jan 7 22:44:30 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13273 for ; Sun, 7 Jan 2001 22:44:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FT53-000Je3-00 for idn-data@psg.com; Sun, 07 Jan 2001 19:34:45 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14FT52-000Jdx-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 19:34:44 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12710; Sun, 7 Jan 2001 19:29:53 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010108032117.C29921@arwen.cs.berkeley.edu> References: <20010108032117.C29921@arwen.cs.berkeley.edu> Date: Sun, 7 Jan 2001 19:33:40 -0800 To: "Adam M. Costello" , idn working group From: Paul Hoffman / IMC Subject: Re: [idn] internationalized email addresses Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 3:21 AM +0000 1/8/01, Adam M. Costello wrote: >It just occurred to me that once people can put Unicode characters into >domain names, they'll also want to put them before the @-sign in email >addresses. How is that going to work? It won't, yet. It is likely that the mail standards will be updated to allow internationalized left-hand sides. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jan 8 01:07:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14912 for ; Mon, 8 Jan 2001 01:07:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FV6b-0003VL-00 for idn-data@psg.com; Sun, 07 Jan 2001 21:44:29 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14FV6b-0003Qi-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 21:44:29 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA16726; Sun, 7 Jan 2001 21:43:51 -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 f085hkb20055; Sun, 7 Jan 2001 21:43:46 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id VAA02935; Sun, 7 Jan 2001 21:43:37 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010108032117.C29921@arwen.cs.berkeley.edu> References: <20010108032117.C29921@arwen.cs.berkeley.edu> Date: Mon, 8 Jan 2001 06:34:34 +0100 To: "Adam M. Costello" , idn working group From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] internationalized email addresses 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 03.21 +0000 01-01-08, Adam M. Costello wrote: >It just occurred to me that once people can put Unicode characters into >domain names, they'll also want to put them before the @-sign in email >addresses. How is that going to work? Work is initiated to look at this problem in the applications area of the IETF. It is not an open mailing list yet because the work should not interfer with the work the IDN wg is doing. paf -- Patrik Fältström 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 Mon Jan 8 02:30:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28162 for ; Mon, 8 Jan 2001 02:30:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FWLf-0009xB-00 for idn-data@psg.com; Sun, 07 Jan 2001 23:04:07 -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 14FWLe-0009wx-00 for idn@ops.ietf.org; Sun, 07 Jan 2001 23:04:06 -0800 Received: from QSM3 (bzq-182-161.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G6U002DA0RN4A@mail.bezeqint.net> for idn@ops.ietf.org; Mon, 8 Jan 2001 08:59:49 +0200 (IST) Date: Mon, 08 Jan 2001 09:02:01 +0200 From: Jonathan Rosenne Subject: RE: [idn] Where will we see bad domain names? In-reply-to: <20010107222917.4166.qmail@cr.yp.to> 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 For example, when I type a name, or even cut and paste, I have no control over the encoding. Since the UCS offers alternative equivalent encodings, they must be normalized before they are used. Jony > -----Original Message----- > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf > Of D. J. Bernstein c/o James Seng > Sent: Monday, January 08, 2001 12:29 AM > To: idn@ops.ietf.org > Subject: [idn] Where will we see bad domain names? > > > Why do we need name preparation in applications? > > I'm not saying the nameprep work is useless. We should provide a program > to detect bad names: names with confusing characters, or with uppercase > characters, or that aren't KC-normalized. Registries will then prohibit > bad names. > > But what will go wrong if these rules are hidden from applications? Why > should a typical application worry about bad names? Good names will be > accurately copied by cut-and-paste. When will bad names show up? > > Mark Davis writes: > > The chances that the average application would, by chance, duplicate > > the same normalization is minimal. > > You're saying that a user will see a good name on paper, type it into > his computer in his favorite way, and end up with a bad name that looks > the same. > > Can you please give some real examples? What were the good names? What > keyboard-interface software was involved? What did the user type? Why > didn't the user end up with good names? Was it a bug in the software? > > Perhaps there's a need for a tool that fixes bad Chinese domain names. > However, I don't see why this conversion should be stuck into every > piece of software that reads domain names from configuration files. > > ---Dan > > P.S. RFC 1034 says ``When you receive a domain name or label, you should > preserve its case.'' Are we going to scrap this part of RFC 1034, and > encourage clients to fold case for ASCII characters? Or are we going to > say that the case of ASCII characters should be preserved? > > Of course, for interoperability, DNS software and mail software and so > on will continue _comparing_ ASCII characters without regard to case. > From owner-idn@ops.ietf.org Mon Jan 8 05:17:14 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29058 for ; Mon, 8 Jan 2001 05:17:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FZ1u-000Pen-00 for idn-data@psg.com; Mon, 08 Jan 2001 01:55:54 -0800 Date: Sun, 7 Jan 2001 20:33:00 -0500 (EST) From: William Morris To: idn@ops.ietf.org Subject: [idn] A case for *ACE, other good/bad ideas, and a rant... Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Clients or servers that can not be upgraded Many embedded devices can't be updated because their code is stored in ROM or ASICs. Who knows how many are out there or how they will react. *ACE deals with this issue well, UTF-8 does not. It is not possible to determine how many devices will be affected. Imagine a UPS failing silently in communicating its status. Clients or servers that can be upgraded Non-IDN Systems There will be systems on the Internet for the foreseeable future that can handle IDN but will not be upgraded due to various reasons. Unless someone takes over the Internet again, there will continue to be systems running cc: mail or worse. Clients will attempt to communicate with these systems directly, therefore *ACE translation MUST be done on the client if it is implemented. Last week I spoke with a customer who is running a cc: mail to uucp gateway to send mail to the Internet. If you dont mind losing communications between those who cant or wont upgrade and those that must use IDN, then something other then *ACE is an option. Input devices All known systems that are capable of connecting to the Internet and can accept user input, have support for entering the 37 possible characters a-z,0-9,- currently possible in a domain name. The user may not understand them, but the worst case is someone who only understands klingon can look at a business card and select characters from a chart of 37, and the most confusing would be O vs 0 which could be resolved by using a better font or guessing. Worst case two email addresses per card, one in their native language, one in ASCII. Most likely they will have another domain name they use or they can use the *ACE version. Other (bad/good)Ideas... Update all of the network protocols to support UTF-8, and make UTF-8 mandatory for IPv6. Add an opcode to DNS to support UTF-8 query and response. Nameprep is manditory for IDN. there is no way around it. Using the Japanese input method for Win98 if you hit period you get one of two characters depending on which mode (Japanese/English) you are in. Both of these must map to ".", because end users have enough trouble double clicking much less typing (ALT+SPACE).com Despite everything, I think losing a small percentage of communications on the Internet is better then continuing to prevent a greater population of potential users who cannot read or write English. Given that many will agree that UTF-8 is an ideal end goal, I would rather go thru the hell of upgrading customers(wetware/etc) to support IDN once. While sad, I would rather that I had problems communicating with a friend in Japan because pine doesnt support UTF-8 email addresses then deal with something that in my opinion is a hack, a clever hack but a hack none the less. I say force everyone to support or upgrade to UTF-8, if they need to give their email address to someone who cant type it they should register 5464786464.com or something... -Bill From owner-idn@ops.ietf.org Mon Jan 8 05:18:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29069 for ; Mon, 8 Jan 2001 05:18:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FZ1z-000Pev-00 for idn-data@psg.com; Mon, 08 Jan 2001 01:55:59 -0800 From: William Morris To: "Adam M. Costello" cc: idn working group Subject: Re: [idn] internationalized email addresses Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 08 Jan 2001 01:55:59 -0800 On Mon, 8 Jan 2001, Adam M. Costello wrote: > It just occurred to me that once people can put Unicode characters into > domain names, they'll also want to put them before the @-sign in email > addresses. How is that going to work? > > I'm not sure it makes sense to try to allow Unicode characters in > domain names without simultaneously thinking about how to allow them > in the other parts of email addresses and URIs. Are there other > name/address-like things that need to be considered as well? Lets see... unix shell accounts, pop accounts, ftp accounts, anonymous ftp password. contact management, the list covers almost everything. Perhaps it would be better to consider what wouldnt be affected. I dont see how breaking things can be avoided... does the username get *ACE encoded as well? -Bill From owner-idn@ops.ietf.org Mon Jan 8 07:47:30 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01191 for ; Mon, 8 Jan 2001 07:47:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FbPP-00071u-00 for idn-data@psg.com; Mon, 08 Jan 2001 04:28:19 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14FbPO-00071o-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 04:28:18 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00485; Mon, 8 Jan 2001 07:28:12 -0500 (EST) Message-Id: <200101081228.HAA00485@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-lace-01.txt Date: Mon, 08 Jan 2001 07:28:11 -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 : LACE: Length-based ASCII Compatible Encoding for IDN Author(s) : M. Davis, P. Hoffman Filename : draft-ietf-idn-lace-01.txt Pages : Date : 05-Jan-01 This document describes a transformation method for representing non-ASCII characters in host name parts in a fashion that is completely compatible with the current DNS. It is a potential candidate for an ASCII-Compatible Encoding (ACE) for internationalized host names, as described in the comparison document from the IETF IDN Working Group. This method is based on the observation that many internationalized host name parts will have a few substrings from a small number of rows of the ISO 10646 repertoire. Run-length encoding for these types of host names will be fairly compact, and is fairly easy to describe. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-lace-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-lace-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-lace-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: <20010105145813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-lace-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-lace-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010105145813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jan 8 08:15:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02057 for ; Mon, 8 Jan 2001 08:15:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FbjS-0007QG-00 for idn-data@psg.com; Mon, 08 Jan 2001 04:49:02 -0800 Received: from rly-ip01.mx.aol.com ([205.188.156.49]) by psg.com with esmtp (Exim 3.16 #1) id 14FbjR-0007Pr-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 04:49:01 -0800 Received: from tot-we.proxy.aol.com (tot-we.proxy.aol.com [205.188.195.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id HAA21026; Mon, 8 Jan 2001 07:48:12 -0500 (EST) Received: from enoshima (AC8B73C7.ipt.aol.com [172.139.115.199]) by tot-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f08CmAJ28251; Mon, 8 Jan 2001 07:48:11 -0500 (EST) Message-Id: <4.2.0.58.J.20010107120954.038c6b60@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 07 Jan 2001 12:18:21 +0900 To: John C Klensin From: "Martin J. Duerst" Subject: Re: [idn] An experiment with UTF-8 domain names Cc: idn@ops.ietf.org In-Reply-To: <3838565278.978796141@P2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Apparently-From: Mjduerst@aol.com Sender: owner-idn@ops.ietf.org Precedence: bulk At 01/01/06 15:49 -0500, John C Klensin wrote: >--On Sunday, 07 January, 2001 00:56 +0900 "Martin J. Duerst" > wrote: > > >... > > Yes. But how many such regular expressions do you expect > > for handling domain names? Can you give a reasonable > > example? > >Martin, for better or worse, there has been a trend in many >organizations to reflect the flatness at the top level with >flatness in subdomains. E.g., if the StupidAcme company had >departments for collections and customer abuse, their IT >department might set up a domain structure of > > collections-hostA.StupidAcme.biz > collections-hostB.StupidAcme.biz > customer-abuse-hostA.StupidAcme.biz > customer-abuse-hostD.StupidAcme.biz >And that situation leads precisely to wildcard searches on zone >files or copies of them. Good example. Somebody in Sweden could just go on after Z with additional letters, which would need two bytes in UTF-8. But in most places, people will go to AA, AB, AC,... after Z. >Emacs is probably still the most >commonly-used tool for zone file editing and maintenance >worldwide. Nice. I just tested, and Emacs (newer version with the multilingual stuff integrated) does handle such regular expressions correctly (it doesn't use Unicode or UTF-8 inside, but that's not a problem, it can read and write Unicode). Regards, Martin. From owner-idn@ops.ietf.org Mon Jan 8 09:16:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04324 for ; Mon, 8 Jan 2001 09:16:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Fcl9-0008Rj-00 for idn-data@psg.com; Mon, 08 Jan 2001 05:54:51 -0800 Received: from nic.cafax.se ([192.71.228.17]) by psg.com with esmtp (Exim 3.16 #1) id 14Fcl8-0008Rd-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 05:54:50 -0800 Received: (from bygg@localhost) by nic.cafax.se (8.10.2/8.11.2.Beta0) id f08DsmU22997 for idn@ops.ietf.org; Mon, 8 Jan 2001 14:54:48 +0100 (MET) Date: Mon, 8 Jan 2001 14:54:48 WET From: Johnny Eriksson To: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names In-Reply-To: Your message of Sat, 06 Jan 2001 18:28:37 +0900 Message-ID: Sender: owner-idn@ops.ietf.org Precedence: bulk "Martin J. Duerst" wrote: > >...but could also on my buissness card have (if the ACE ends up being RACE): > > > > bq--abtoi3duon2hf5tn .com > > Sorry, but I very strongly doubt that this should be done, and that > very many people will want to embarrass themselves that way. If I had a domain name with non-ASCII characters in it, I would certainly provide the ACE-encoded version as well, to help people that might not be able to use the non-ASCII characters. As noted by other people in this discussion there might be several reasons for this. When AT&T publish something like "1-800-CALL-ATT" they usually embarrass themselves by providing "1-800-2255-288" as well. Final note: In this thread the ACE encoded string "bq--abtoi3duon2hf5tn" has survived in several messages. Patriks family name, on the other hand... > Regards, Martin. --Johnny From owner-idn@ops.ietf.org Mon Jan 8 11:06:08 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08917 for ; Mon, 8 Jan 2001 11:06:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FeX7-000ARb-00 for idn-data@psg.com; Mon, 08 Jan 2001 07:48:29 -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 14FeX6-000ARL-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 07:48:28 -0800 Received: from QSM3 (bzq-182-63.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G6U0034LOZRSP@mail.bezeqint.net> for idn@ops.ietf.org; Mon, 8 Jan 2001 17:43:06 +0200 (IST) Date: Mon, 08 Jan 2001 17:45:16 +0200 From: Jonathan Rosenne Subject: RE: [idn] internationalized email addresses In-reply-to: To: idn working group Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="windows-1255" 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 > -----Original Message----- > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf Of > William Morris > Sent: Monday, January 08, 2001 11:56 AM > To: Adam M. Costello > Cc: idn working group > Subject: Re: [idn] internationalized email addresses > > > > > On Mon, 8 Jan 2001, Adam M. Costello wrote: > > > It just occurred to me that once people can put Unicode characters into > > domain names, they'll also want to put them before the @-sign in email > > addresses. How is that going to work? > > > > I'm not sure it makes sense to try to allow Unicode characters in > > domain names without simultaneously thinking about how to allow them > > in the other parts of email addresses and URIs. Are there other > > name/address-like things that need to be considered as well? > > Lets see... unix shell accounts, pop accounts, ftp accounts, anonymous ftp > password. contact management, the list covers almost everything. No - it should be everything. It should be possible to use computers and the Internet without any English. Jony > Perhaps it would be better to consider what wouldnt be affected. > > I dont see how breaking things can be avoided... does the username get > *ACE encoded as well? > > -Bill > > From owner-idn@ops.ietf.org Mon Jan 8 15:05:44 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15539 for ; Mon, 8 Jan 2001 15:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Fi5K-000Ebi-00 for idn-data@psg.com; Mon, 08 Jan 2001 11:36:02 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.16 #1) id 14Fi5J-000Ebc-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 11:36:01 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JYNUGHNRKW0000CO@mauve.mrochek.com> for idn@ops.ietf.org; Mon, 08 Jan 2001 11:35:56 -0700 (PDT) Date: Mon, 08 Jan 2001 11:34:00 -0700 (PDT) From: ned.freed@innosoft.com Subject: Re: [idn] internationalized email addresses In-reply-to: "Your message dated Mon, 08 Jan 2001 01:55:59 -0800" To: William Morris Cc: "Adam M. Costello" , idn working group Message-id: <01JYNVVQ1AV60000CO@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > On Mon, 8 Jan 2001, Adam M. Costello wrote: > > It just occurred to me that once people can put Unicode characters into > > domain names, they'll also want to put them before the @-sign in email > > addresses. How is that going to work? > > > > I'm not sure it makes sense to try to allow Unicode characters in > > domain names without simultaneously thinking about how to allow them > > in the other parts of email addresses and URIs. Are there other > > name/address-like things that need to be considered as well? > Lets see... unix shell accounts, pop accounts, ftp accounts, anonymous ftp > password. contact management, the list covers almost everything. > Perhaps it would be better to consider what wouldnt be affected. > I dont see how breaking things can be avoided... does the username get > *ACE encoded as well? It seems premature to consider such details until the solution on the right hand side of the @ is nailed down. How can we answer the question of whether or not an ACE is to be used until we know for sure there is an ACE? Ned From owner-idn@ops.ietf.org Mon Jan 8 17:58:28 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18205 for ; Mon, 8 Jan 2001 17:58:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FkoH-000I2z-00 for idn-data@psg.com; Mon, 08 Jan 2001 14:30:37 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14FkoG-000I25-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 14:30:36 -0800 Received: (qmail 3691 invoked by uid 1001); 8 Jan 2001 22:29:39 -0000 Date: 8 Jan 2001 22:29:39 -0000 Message-ID: <20010108222939.16067.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk William Morris writes: > Nameprep is manditory for IDN. there is no way around it. Using the > Japanese input method for Win98 if you hit period you get one of two > characters depending on which mode (Japanese/English) you are in. You are confusing two separate issues: the dots, and the stuff between the dots. The nameprep discussion is all about the stuff between the dots. There's nothing in the nameprep draft about normalizing dots. In fact, dots and things that look like dots are specifically prohibited. [ embedded devices ] > *ACE deals with this issue well, UTF-8 does not. What if the sysadmin has to use an embedded device that can't deal with name components longer than, say, 10 bytes? He has a much better chance of finding a tolerable 10-byte UTF-8 string than of finding a tolerable 10-byte ACE string with any of the ACE proposals. (Of course, neither chance is good if the name is supposed to be in Chinese.) Why should we believe that failures to handle 8-bit data cleanly are more common than failures to handle long domain names cleanly? > Unless someone takes over the Internet again, there will continue to > be systems running cc: mail or worse. Are you saying that cc:Mail isn't 8-bit clean? Are you also saying that cc:Mail has no trouble with long domain names? (It has been a while since I've spotted any cc:Mail systems, so I don't have an easy way to test any of this.) ---Dan From owner-idn@ops.ietf.org Mon Jan 8 18:03:02 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18261 for ; Mon, 8 Jan 2001 18:03:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Fl79-000IPf-00 for idn-data@psg.com; Mon, 08 Jan 2001 14:50:07 -0800 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.16 #1) id 14Fl77-000IPX-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 14:50:06 -0800 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09423; Mon, 8 Jan 2001 14:50:02 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA27525; Mon, 8 Jan 2001 14:50:01 -0800 (PST) Received: from sundrop.eng.sun.com (hobo233.Eng.Sun.COM [129.146.31.233]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f08Mnrv520885; Mon, 8 Jan 2001 14:49:54 -0800 (PST) Date: Mon, 8 Jan 2001 14:50:20 -0800 (PST) From: "Carl S. Gutekunst" Reply-To: "Carl S. Gutekunst" Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant... To: "D. J. Bernstein" Cc: idn@ops.ietf.org In-Reply-To: "Your message with ID" <20010108222939.16067.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 > > Unless someone takes over the Internet again, there will continue to > > be systems running cc: mail or worse. > > Are you saying that cc:Mail isn't 8-bit clean? cc:Mail could best be described as "8-bit erratic." An instance of the cc:Mail client inherits the default charset for the platform on which it's running, which might mean PC-437, PC-850, Shift-JIS, or whatever. This was an artifact of MS-DOS that carried over to the MS-Windows client, and as a conseqeunce the Windows client does character conversions between Windows 8-bit charsets and the old PC charsets. These conversions are very dirty and irrecoverably munge the data. Shift-JIS is a great challange in its own right. Raw UTF-8, when passed to an 8859-1 application, is legal and replayable even though unintelligible. Not so with Shift-JIS; a UTF-8 stream will contain many many code sequences that are illegal in Shift-JIS, causing a well-behaved client to discard the data. All of the native-language Japanese clients I know of also have this problem. They use Shift-JIS natively, and will thoroughly destroy UTF-8 streams. > Are you also saying that cc:Mail has no trouble with long domain names? The length of Internet domain names when presented to cc:Mail is a complex issue, depending on how the SMTP gateway is configured and whether the recipient is listed in the cc:Mail directory. As a rule of thumb, however, the limit should be the size of a cc:Mail postoffice name, which on older (but still widely used systems) is 64 bytes. From owner-idn@ops.ietf.org Mon Jan 8 18:43:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18716 for ; Mon, 8 Jan 2001 18:43:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Fllb-000JF2-00 for idn-data@psg.com; Mon, 08 Jan 2001 15:31:55 -0800 Received: from epa.secret.org ([206.220.140.150] ident=0) by psg.com with esmtp (Exim 3.16 #1) id 14Flla-000JEv-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 15:31:54 -0800 Received: from localhost (lucid@localhost) by epa.secret.org (8.9.3/8.9.1) with ESMTP id SAA52108; Mon, 8 Jan 2001 18:31:52 -0500 (EST) Date: Mon, 8 Jan 2001 18:31:52 -0500 (EST) From: William Morris X-Sender: lucid@epa.secret.org To: "D. J. Bernstein" cc: idn@ops.ietf.org Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant... In-Reply-To: <20010108222939.16067.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 8 Jan 2001, D. J. Bernstein wrote: > William Morris writes: > > Nameprep is manditory for IDN. there is no way around it. Using the > > Japanese input method for Win98 if you hit period you get one of two > > characters depending on which mode (Japanese/English) you are in. > > You are confusing two separate issues: the dots, and the stuff between > the dots. > > The nameprep discussion is all about the stuff between the dots. There's > nothing in the nameprep draft about normalizing dots. In fact, dots and > things that look like dots are specifically prohibited. For Non-ASCII languages, most text input is modal; you are either typing in ASCII or Non-ASCII. Since users may not enter .com properly, and application developers have been known to implement things oddly enough when there are standards. I would really like dot handling in applications to be standardized. It may not be nameprep but it needs to be dealt with. I should be able to hit the period while in Japanese mode and have the application do the right thing. > Why should we believe that failures to handle 8-bit data cleanly are > more common than failures to handle long domain names cleanly? Because I have seen more then enough systems that choke at anything over 7 bits, and thats just in the past month. People are still using windows 3.11 to connect to the internet, 8bit-dirty terminal servers, old versions of netware. At least you can work around long domain names. > Are you saying that cc:Mail isn't 8-bit clean? Are you also saying that > cc:Mail has no trouble with long domain names? I know cc:mail will have much more problems with 8-bit data then long domain names. -Bill From owner-idn@ops.ietf.org Mon Jan 8 19:53:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19158 for ; Mon, 8 Jan 2001 19:53:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Fmij-000KUp-00 for idn-data@psg.com; Mon, 08 Jan 2001 16:33:01 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192]) by psg.com with esmtp (Exim 3.16 #1) id 14Fmii-000KUj-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 16:33:00 -0800 Received: from amc by arwen.cs.berkeley.edu with local (Exim 3.20 #1 (Debian)) id 14Fmih-0000ve-00; Mon, 08 Jan 2001 16:32:59 -0800 Date: Tue, 9 Jan 2001 00:32:59 +0000 To: idn working group Subject: Re: [idn] internationalized email addresses Message-ID: <20010109003259.A3434@arwen.cs.berkeley.edu> References: <01JYNVVQ1AV60000CO@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <01JYNVVQ1AV60000CO@mauve.mrochek.com>; from ned.freed@innosoft.com on Mon, Jan 08, 2001 at 11:34:00AM -0700 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk ned.freed@innosoft.com wrote: > It seems premature to consider such details until the solution on > the right hand side of the @ is nailed down. How can we answer the > question of whether or not an ACE is to be used until we know for sure > there is an ACE? How can we decide whether or not there should be an ACE, or design a good one, before we've considered whether or not it will be useful in other contexts facing the same problem? If we need to cook up some method to get Unicode characters into domain names, and another method to get them into email address local parts, and another method to get them into URI paths, it would be nice if we could arrange for the same method (or at least very similar ones) to work in all three places. Maybe it will turn out to be impossible, but it would be a shame to charge ahead with domain names only to realize too late that some other solution could have covered all three cases. AMC From owner-idn@ops.ietf.org Mon Jan 8 20:51:25 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19587 for ; Mon, 8 Jan 2001 20:51:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FngU-000LpN-00 for idn-data@psg.com; Mon, 08 Jan 2001 17:34:46 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14FngU-000LpH-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 17:34:46 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA13753 for ; Mon, 8 Jan 2001 17:29:49 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010109003259.A3434@arwen.cs.berkeley.edu> References: <01JYNVVQ1AV60000CO@mauve.mrochek.com> <20010109003259.A3434@arwen.cs.berkeley.edu> Date: Mon, 8 Jan 2001 17:33:35 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] internationalized email addresses Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12:32 AM +0000 1/9/01, Adam M. Costello wrote: >How can we decide whether or not there should be an ACE, or design a >good one, before we've considered whether or not it will be useful in >other contexts facing the same problem? Host names come first. They span all of the protocol elements you are concerned with. As for whether ACE would be a good solution for email local parts if they are chosen for host names, all I can say is: of course they would. Any presentation layer change that works for the host part of an email address will work for the local part. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jan 8 21:07:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19664 for ; Mon, 8 Jan 2001 21:07:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FnlK-000Lwh-00 for idn-data@psg.com; Mon, 08 Jan 2001 17:39:46 -0800 Date: Mon, 8 Jan 2001 10:57:11 +0000 (GMT) To: "D. J. Bernstein" Cc: idn@ops.ietf.org Subject: Re: [idn] An experiment with UTF-8 domain names From: Martin Oldfield Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Thank you for your clarification. I was trying to find out to what extent UTF-8 and ACE would be interoperable with existing, rather than upgraded systems. I really think that this is the important consideration, because I think everyone agrees that if all the world used either system then it would work. >From what you've said, it seems clear to me that for email IDNs containing a byte in the range \200 through \237, would be significantly less useful under a UTF-8 system than under an ACE encoding. Obviously my definition of useful puts gives more weight to `can exchange email with people who have old software' than to `will display the IDN correctly'. Whilst I quite accept that you might order these things differently, I'd quite like to sort out in my own mind the pros and cons of the two encodings. Please could you tell me if you think that UTF-8 would display the IDN correctly in more places, whilst ACE would pass through more of the existing infrastructure without error ? Cheers, -- Martin Oldfield, AdamsNames Ltd. From owner-idn@ops.ietf.org Tue Jan 9 03:13:53 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07641 for ; Tue, 9 Jan 2001 03:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FtSh-0003Bw-00 for idn-data@psg.com; Mon, 08 Jan 2001 23:44:55 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14FtSg-0003Bp-00 for idn@ops.ietf.org; Mon, 08 Jan 2001 23:44:55 -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 f097ipl00819; Tue, 9 Jan 2001 08:44:51 +0100 (MET) Received: from valinor by valinor.malmo.trab.se (8.10.1/TRM-1-KLIENT); Tue, 9 Jan 2001 08:44:50 +0100 (MET) (MET) Message-Id: <200101090744.f097ioX06115@valinor.malmo.trab.se> Date: Tue, 9 Jan 2001 08:44:50 +0100 (MET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant... To: djb@cr.yp.to, me@williammorris.com Cc: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zu0BmMqXIzOB7A3X6+b4eQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk William Morris writes: >For Non-ASCII languages, most text input is modal; you are either typing >in ASCII or Non-ASCII. Why do you think this? It might be correct for Non-LATIN based alphabets, but not for non-ascii. I am using Swedish and Swedish is having a 29 character latin alphabet. The text input is not modal! Dan From owner-idn@ops.ietf.org Tue Jan 9 03:27:05 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07715 for ; Tue, 9 Jan 2001 03:27:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FtiL-0003TR-00 for idn-data@psg.com; Tue, 09 Jan 2001 00:01:05 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.16 #1) id 14FtiK-0003TJ-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 00:01:04 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JYOG89YUGG0002SZ@mauve.mrochek.com> for idn@ops.ietf.org; Tue, 09 Jan 2001 00:00:53 -0700 (PDT) Date: Mon, 08 Jan 2001 23:52:42 -0700 (PDT) From: ned.freed@innosoft.com Subject: Re: [idn] internationalized email addresses In-reply-to: "Your message dated Mon, 08 Jan 2001 17:33:35 -0800" To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Message-id: <01JYOLWBLNIE0002SZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <01JYNVVQ1AV60000CO@mauve.mrochek.com> <20010109003259.A3434@arwen.cs.berkeley.edu> <20010109003259.A3434@arwen.cs.berkeley.edu> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > At 12:32 AM +0000 1/9/01, Adam M. Costello wrote: > >How can we decide whether or not there should be an ACE, or design a > >good one, before we've considered whether or not it will be useful in > >other contexts facing the same problem? > Host names come first. They span all of the protocol elements you are > concerned with. Exactly. There is little point in considering local parts now unless they additionally constrain the problem. (AFAIK they do not.) And even if they did, the requirements for host names are already so onerous that adding additional ones imposed by other identifier spaces seems like a really bad idea. We need closure, not further muddying of the waters. > As for whether ACE would be a good solution for email local parts if > they are chosen for host names, all I can say is: of course they > would. Any presentation layer change that works for the host part of > an email address will work for the local part. Yes, but there are some other facets to the local part problem. However, now is not the time... Ned From owner-idn@ops.ietf.org Tue Jan 9 04:13:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07937 for ; Tue, 9 Jan 2001 04:13:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FuSr-0004ON-00 for idn-data@psg.com; Tue, 09 Jan 2001 00:49: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 14FuSq-0004OG-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 00:49:08 -0800 Received: from r2.jck.com ("port 1056"@[209.187.148.221]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G6W009E30HRVZ@a4.jck.com> for idn@ops.ietf.org; Tue, 09 Jan 2001 03:49:07 -0500 (EST) Date: Tue, 09 Jan 2001 03:49:01 -0500 From: John C Klensin Subject: Re: [idn] internationalized email addresses In-reply-to: <01JYOLWBLNIE0002SZ@mauve.mrochek.com> To: ned.freed@innosoft.com Cc: idn@ops.ietf.org Message-id: <4054565778.979012141@r2.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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, January 08, 2001 11:52 PM -0700 ned.freed@innosoft.com wrote: > Exactly. There is little point in considering local parts now > unless they additionally constrain the problem. (AFAIK they do > not.) And even if they did, the requirements for host names are > already so onerous that adding additional ones imposed by other > identifier spaces seems like a really bad idea. We need > closure, not further muddying of the waters. While I agree, we do need to be a bit careful about this, e.g., (i) As we move functionality from DNS resolvers to the nameprep function we need to remember that local-parts are case-sensitive in ASCII while FQDNs are not. Preserving that distinction may require slightly different rules in the two situations. (ii) While I don't see any obvious issues with local-parts that would argue for either UTF-8 or ?ACE against the other, we again will need to be careful: the variety of conventions used in local-parts around the world is such that a string that looks like an ACE prefix is perhaps more likely to occur by accident in a mail local-part than in a DNS name. That said, we probably have more experience with adverse impact of unexpected appearance of 8bit strings in email clients than with other classes of clients. And much of that experience has been fairly horrifying. Or is that what you meant by "other facets"? john From owner-idn@ops.ietf.org Tue Jan 9 07:08:52 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09200 for ; Tue, 9 Jan 2001 07:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14FxGu-0006Uf-00 for idn-data@psg.com; Tue, 09 Jan 2001 03:49:00 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14FxGt-0006UZ-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 03:49:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08869; Tue, 9 Jan 2001 06:48:57 -0500 (EST) Message-Id: <200101091148.GAA08869@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Date: Tue, 09 Jan 2001 06:48:57 -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 : Internationalized Domain Names in URIs and IRIs Author(s) : M. Duerst Filename : draft-ietf-idn-uri-00.txt Pages : Date : 08-Jan-01 This document is a first draft for the provisions necessary to upgrade the definitions of URIs [RFC 2396] and IRIs (Internationalized Resource Identifiers, [IRI]) to work with internationalized domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-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-uri-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-uri-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: <20010108124847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-uri-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-uri-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010108124847.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Tue Jan 9 07:59:54 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10260 for ; Tue, 9 Jan 2001 07:59:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Fxyi-00072N-00 for idn-data@psg.com; Tue, 09 Jan 2001 04:34:16 -0800 Received: from nanashi.nic-se.se ([212.247.3.69]) by psg.com with esmtp (Exim 3.16 #1) id 14Fxyh-00072B-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 04:34:16 -0800 Received: (from mansaxel@localhost) by nanashi.nic-se.se (8.9.3+Sun/8.9.3) id NAA14842; Tue, 9 Jan 2001 13:34:09 +0100 (MET) Date: Tue, 9 Jan 2001 13:34:09 +0100 From: =?iso-8859-1?Q?M=E5ns_Nilsson?= To: idn@ops.ietf.org Cc: djb@cr.yp.to Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant... Message-ID: <20010109133409.B14759@nic-se.se> References: <200101090744.f097ioX06115@valinor.malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200101090744.f097ioX06115@valinor.malmo.trab.se>; from Dan.Oscarsson@trab.se on Tue, Jan 09, 2001 at 08:44:50AM +0100 X-URL: http://vvv.besserwisser.org X-availability: Geek seeks Geekette X-Purpose: More of everything NOW! Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant... Date: Tue, Jan 09, 2001 at 08:44:50AM +0100 Quoting Dan Oscarsson (Dan.Oscarsson@trab.se): > > William Morris writes: > > >For Non-ASCII languages, most text input is modal; you are either typing > >in ASCII or Non-ASCII. > > Why do you think this? > > It might be correct for Non-LATIN based alphabets, but not for non-ascii. > I am using Swedish and Swedish is having a 29 character latin alphabet. > The text input is not modal! If one is using "classical Unix" keyboard layout but still cares about correct characters, there is a certain "modality" involved, in form of using the Compose key. But that surely is of minor importance, especially since most people have (in this sense) nonmodal keyboards or don't care about åäö being [}| (or whatever).. -- Måns Nilsson DNS Technichian +46 709 174 840 NIC-SE +46 8 545 85 707 MN1334-RIPE I had pancake makeup for brunch! From owner-idn@ops.ietf.org Tue Jan 9 12:12:09 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17198 for ; Tue, 9 Jan 2001 12:12:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G1zu-000AWd-00 for idn-data@psg.com; Tue, 09 Jan 2001 08:51:46 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14G1zt-000AWF-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 08:51:46 -0800 Received: from enoshima ([199.84.165.115]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id BAA17908; Wed, 10 Jan 2001 01:52:33 +0900 (JST) Message-Id: <4.2.0.58.J.20010109205454.0397e220@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 09 Jan 2001 21:08:51 +0900 To: "D. J. Bernstein" , idn@ops.ietf.org From: "Martin J. Duerst" Subject: Re: [idn] Where will we see bad domain names? In-Reply-To: <20010107222917.4166.qmail@cr.yp.to> References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 01/01/07 22:29 +0000, D. J. Bernstein c/o James Seng wrote: >Why do we need name preparation in applications? > >I'm not saying the nameprep work is useless. We should provide a program >to detect bad names: names with confusing characters, or with uppercase >characters, or that aren't KC-normalized. Registries will then prohibit >bad names. > >But what will go wrong if these rules are hidden from applications? Why >should a typical application worry about bad names? Good names will be >accurately copied by cut-and-paste. When will bad names show up? > >Mark Davis writes: > > The chances that the average application would, by chance, duplicate > > the same normalization is minimal. I think what Mark meant is that the chance that an average implementation trying to do something in this area as virtually zero chance to by chance get everything the same as another one or a well-defined standard. I agree with this. This is different from the chance that an average user typing in an average internationalized domain name will get different character codes without nameprep than with nameprep from his keyboard software are in most cases extremely minimal, with a few very notable exceptions. >You're saying that a user will see a good name on paper, type it into >his computer in his favorite way, and end up with a bad name that looks >the same. > >Can you please give some real examples? What were the good names? What >keyboard-interface software was involved? What did the user type? Why >didn't the user end up with good names? Was it a bug in the software? The classical case is half-width and full-width alphabetics and Katakana in Japan. It's not a bug in the software, but a configuration option. Many people are not aware of the fact that full-width Latin letters are different character codes than half-width (ASCII), and their keyboard may come set to full-width, or they may set it that way. >Perhaps there's a need for a tool that fixes bad Chinese domain names. There are quite some things that may go wrong with Chinese domain names, but there are so many characters, with so many subtly or totally different relations, that it is impossible to use a uniform (e.g. table-based) approach. The solution here is to register more than one form if it's needed; the number necessary is usually very small (not as in case folding). >---Dan > >P.S. RFC 1034 says ``When you receive a domain name or label, you should >preserve its case.'' Are we going to scrap this part of RFC 1034, and >encourage clients to fold case for ASCII characters? Or are we going to >say that the case of ASCII characters should be preserved? > >Of course, for interoperability, DNS software and mail software and so >on will continue _comparing_ ASCII characters without regard to case. The idea is to: - Have different case versions behave as equivalents. - Move case-folding away from the servers because of performance and updating issues (and potentially because of cultural differences that cannot be handled on the server side). Whether ASCII case folding is treated as up to now or will be integrated with the rest isn't clear to me yet. Regards, Martin. From owner-idn@ops.ietf.org Tue Jan 9 12:12:44 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17216 for ; Tue, 9 Jan 2001 12:12:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G206-000AXA-00 for idn-data@psg.com; Tue, 09 Jan 2001 08:51:58 -0800 Received: from sh.w3.mag.keio.ac.jp ([133.27.194.41]) by psg.com with esmtp (Exim 3.16 #1) id 14G205-000AX4-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 08:51:58 -0800 Received: from enoshima ([199.84.165.115]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id BAA17918; Wed, 10 Jan 2001 01:52:35 +0900 (JST) Message-Id: <4.2.0.58.J.20010109211335.05ded720@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 09 Jan 2001 21:52:31 +0900 To: John C Klensin , "Brian W. Spolarich" From: "Martin J. Duerst" Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domainnames) Cc: idn@ops.ietf.org In-Reply-To: <3836713798.978794289@P2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk Hello John, I think your considerations are important, but I think you went a bit overboard on some issues. At 01/01/06 15:18 -0500, John C Klensin wrote: >Let me use myself as an example (this one is inherently >European-language-oriented, but I assume it has Asian and >African analogues that are as bad or worse). If I'm handed a >business card with an IDN on it, in the "native" character glyph >set for that name, the next encoding step depends on my >knowledge and pattern-recognition and discrimination skills, and >not on any computer issues. I need to be able to take that >collection of glyphs and somehow transcribe and enter them into >a computer. There is one very clear reason that this problem will in practice be more serious for what you call European languages (really, the Latin script) than for other scripts. It's interestingly enough the fact that Latin is easier for many. French or Swedish business cards are not usually double-sided, because they are recognizable even if there are some accents. If you use them to send a letter, the letter will arrive even without the accents. So there is quite some danger that people happily create domain names with accents or other diacritics, and put them on their business card. On the other hand, for Arabic or Japanese (or even just Greek or Cyrillic), there is no expectation nor that your international business partners will somewhat be able to send you snail mail with just the 'local' side of the business card, or even for that matter have any idea of whom they met when they look at the card a few days later. Therefore I think we will quickly see things develop to have dual domain names, one for each side of the business card. As Paul has noted, in the European context (with few non- ASCII characters), an approach such as Dan's might even work, although I don't think it will become widespread, for various reasons including the fact that people don't know how to use the hex input feature. >Now, if the characters used are Latin-based, I can probably cope >(and I do today). I'm going to recognize the basic structures. >Even if I have to consult a table, I can match what I see on the >card with what I see on the screen. In the worst case --in >which I have no idea how to "type" the character-- I can then >enter the character position from the table into a software >program. Interestingly, for that purpose, a simple hexadecimal >encoding of UCS-4 (or UCS-2) is "easier" than UTF-8 which is a >good deal "easier" than ACE. While tedious, 0x000000E4 is quite >easy to figure out and write. And selection of characters from >tablets is not exactly a new technology; I'd expect user >interface software to show up quickly and be widely deployed >that uses table-selection technologies to build up strings that >could then be pasted. Already available, in any Japanese input method (not really for Latin) and in software such as MS Word, and probably quite a few others. >But that is the easy part and it is conditioned on my being able >to recognize Latin-based characters well enough to tell them >apart. Extrapolating from it as an example is dangerous: Yes, it's dangerous, because things are not linear. >First, I can't tell European characters apart to the degree >needed by IDN. If you had me a card with a native-glyph IDN on >it, I need to know the language (or a surrogate for the >language) to pick the right glyphs from a table. I simply >cannot tell U+0041 from U+0391 from U+0410 by looking at a glyph >written on a page (and those are, of course, not the only >examples). I have to know the language context, or apply >heuristics, to pick one. Well, there are situations where this can go wrong. But as I said above, for Cyrillic and Greek, we'll probably see a 'two-sided business card' approach. Also, please note that if there are ambiguities, the main people who will suffer from them are the locals, so they will try to avoid them. Although for them less things may be ambiguous than for you, and it may be easier for you to start inputing an ascii A and then somehow continue on the rest with tables (rather than switch the keyboard at the start, as they will do), the cases where this won't work won't be that frequent. >But that isn't the serious problem either. It turns out that I >can do just about the same pattern-matching job --looking at a >glyph, deducing its essential characteristics because I'm >familiar with the repertorie from which it comes, finding it in >a table and picking it or entering it by table position-- if >that card contains Greek, Cyrillic, or Hebrew glyphs. That puts >me a bit ahead of most of my American and Western European >colleagues, for which those sets of glyphs may look like >indistinguishable chicken-scratches. I've even been around >this work long enough that I've learned to distinguish enough >kana that I might be able to successfully look them up in a >table (but not pronounce them), although it would take me a long >time since I don't know the table order. But most Han, Kanji, >and Hangul are hopeless for me: there are lots of them, I can't >(in general) tell them apart, and I just don't have the pattern >recognition skills (or training in distinguishing radicals) to >be able to look them up, especially if the font-rendering on the >business card is different from that in my table. You are explorating this too far. Just because you personally can handle (with a lot of pain) some part of this, don't expect that this is what your business partners will expect from you, or what everybody will have to do, and so on. >So, for the business card, we need, I think, to start asking >different questions. If want an address on my business card to >be recognized and usable, after the translator leaves, by a Thai >native who lacks familiarity with Latin alphabets, I had best >figure out how to get a Thai rendering (or something else >recognizable) of my address on that card. Yes. Visitors to such countries interested in business contacts with such people regularly prepare double-sided namecards. But it's usually just the name of the person, and maybe the name of the institution, that is transcribed/translated. I would not expect the street address or the email address to be translated, because this may raise expectations that you can be sent Thai email. For the Web address, that's different, if your company has a Thai Web site with a Thai address, it should go on there. >Another important inference from this story is almost certainly >that a solution that works for "ASCII" and "other language" is, >at least in the long term, inadequate. The same issues exist >between "other language 1" and "other language 2", and the >virtual business card will need to be many-sided. And that may >imply that I may need many DNS identities, associated with >different character sets, to be accessible from all over the >world. For Web sites for a multinational, clearly yes. For email addresses, clearly no. If somebody can't type an ASCII address, how are they going to send you email you can read? >Or we can try to turn it into an ACE-like question, where what >goes on the business card is the "native" set of glyphs plus >some Latin-based encoding. I'm not sure, as argued above, that >there is a "native" set of glyphs for the general case. But, >more important, if one is going to put an encoding on a card >from which one can get back and forth from 10646/Unicode, it is >not clear to me that ACE is superior to hexified UTF-8. And >neither may be as convenient as >hexified UCS-4 (or UCS-2) or a PGP-like biometric word list >encoding. Any of these are going to require software to get >from the business card form to the DNS one; the correct answer >for encoding them may be different from the correct answer for >what should actually go into the DNS. People want names, words, whatever you call it, for their Web and email addresses. Trying to provide a fallback for a business card won't work. And translating or transliterating names is not something that can be automated, so this has to be solved by double registrations. > > Probably a common scenario will be a non-technical person > > receiving a business card with an IDN on it. They'll try to > > type the name into their browser, and it will fail to resolve. > > They'll contact their IT support staff, who will tell them > > what they need to do to use the IDN (and educate them a little > > bit on this 'new thing'), they'll update their software as > > required, and they'll move on. > > Sigh. > > JU: Hello, IT support staff, this is Joe User. I've > got a business card in front of me with a URL on it, and > I don't know how to type it in. > > ITSS: Just copy the letters from the card into the "Go > to" box on the browser. Haven't you learned that yet? > > JU: But I don't recognize any of the characters.. they > aren't on my keyboard. > > ITSS: We can send you out a keyboard for Latin-1, which > covers Swedish, German, French,... and instructions for > installing it. > > (A week later) > > JU: Hello, IT Support Staff, your technician put in the > nice new keyboard and software. Some of my applications > now say "Guten Tag", rather than "Hello", but that is > ok. I still can't type that URL in, the characters > still aren't on the keyboard. > > ITSS: Huh? What language did you say it was in? > > JU: Beats me. Doesn't look much like either English or > Klingon. This is the point where your example becomes extremely unrealistic. Do you really think somebody from Japan will hand you a Japanese-only business card and tell you: "Here is my business card, I don't bother whether it's of any use to you."? People are a bit more intelligent than that. The case of languages written with the Latin script really leaves me much more to worry, because people are accustomed to the fact that the accents can be dropped (e.g. in snail mail, or for the pronunciation of the name, where the average foreigner will anyway not get it right). I'm not saying that we should ignore Latin accents, not at all. But it may take people much more time to understand that putting an accented email address on their name card will not work for every recipient, than it will take somebody in Russia, Egypt,... to understand that a Latin equivalent is needed. Regards, Martin. From owner-idn@ops.ietf.org Tue Jan 9 13:27:38 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19014 for ; Tue, 9 Jan 2001 13:27:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G3EW-000ByJ-00 for idn-data@psg.com; Tue, 09 Jan 2001 10:10:56 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.16 #1) id 14G3ES-000Bxn-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 10:10:55 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JYOG89YUGG0002SZ@mauve.mrochek.com> for idn@ops.ietf.org; Tue, 09 Jan 2001 10:10:43 -0700 (PDT) Date: Tue, 09 Jan 2001 09:48:54 -0700 (PDT) From: ned.freed@innosoft.com Subject: Re: [idn] Where will we see bad domain names? In-reply-to: "Your message dated Tue, 09 Jan 2001 21:08:51 +0900" <4.2.0.58.J.20010109205454.0397e220@sh.w3.mag.keio.ac.jp> To: idn@ops.ietf.org Message-id: <01JYP77F1JZA0002SZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010107222917.4166.qmail@cr.yp.to> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > This is different from the chance that an average user typing > in an average internationalized domain name will get different > character codes without nameprep than with nameprep from his > keyboard software are in most cases extremely minimal, with a > few very notable exceptions. I think you grossly underestimate the liklihood of this happening. Here's one example. Suppose I'm sitting in front of a mail client that uses ISO-8859-whatever and which is attached to both an Internet and X.400 mail system. (Although I wish it were otherwise, such setups are quite common.) I send a message whose body contains a domain that in turn contains accented characters which, for whatever reason, takes two paths, one through X.400 and one not. Now, while X.400 has support for ISO-8859-whatever as part of generaltext, support for generaltext is so spotty in practice that it is best avoided. So many (even most) X.400 systems are configured to fall back to the T.61 character set. Unlike ISO-8559-whatever, T.61 represents accented characters as composed sequences. (The composition order is the opposite of Unicode, but no matter.) So we have one path that converts ISO-8859-whatever to Unicode directly and another that converts ISO-8859-whatever to T.61 and then to Unicode. But given that all ISO-8859-1 characters are directly representable in Unicode, the obvious thing to do is use the composed forms. And given that T.61 combining accents are all in Unicode as well, the obvious thing to do is use decomposed forms. The result is that the Unicode sequence depends on the path the message takes. Is this a contrived example? Hardly -- the reason it occurred to me is that I saw it happen. Such cases may be hard to think up in the abstact, but in practice software tends to do things that even its designers and implementors could not have imagined. This is why interoperability is a mandatory thing for us, not an optional one. When we find a standard where conforming behavior could result in an interoperability, we call that a bug and we fix the standard, regardless of whether or not we think the problem is likely to occur. One final note. The recent flap about UTF-8 security issues and the resulting prohibition of recognition non-shortest length forms illustrates that name comparison can have security implications. Given that applications frequently compare domain names as part of security checks this makes this a potential security problem as well as an interoperability problem. Ned From owner-idn@ops.ietf.org Tue Jan 9 14:09:18 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19782 for ; Tue, 9 Jan 2001 14:09:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G3vr-000ClB-00 for idn-data@psg.com; Tue, 09 Jan 2001 10:55:43 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14G3vp-000Ckv-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 10:55:42 -0800 Received: from r2.jck.com ("port 1131"@[209.187.148.221]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G6W00A5QSKMZT@a4.jck.com> for idn@ops.ietf.org; Tue, 09 Jan 2001 13:55:35 -0500 (EST) Date: Tue, 09 Jan 2001 13:55:33 -0500 From: John C Klensin Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domainnames) In-reply-to: <4.2.0.58.J.20010109211335.05ded720@sh.w3.mag.keio.ac.jp> To: "Martin J. Duerst" Cc: idn@ops.ietf.org Message-id: <4090957048.979048533@r2.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Tuesday, January 09, 2001 9:52 PM +0900 "Martin J. Duerst" wrote: > Hello John, > > I think your considerations are important, but I think > you went a bit overboard on some issues. Given that I was trying to identify the extreme cases, that would not be a surprise. > At 01/01/06 15:18 -0500, John C Klensin wrote: > >> Let me use myself as an example (this one is inherently >> European-language-oriented, but I assume it has Asian and >> African analogues that are as bad or worse). If I'm handed a >> business card with an IDN on it, in the "native" character >>... > There is one very clear reason that this problem will in > practice be more serious for what you call European languages > (really, the Latin script) than for other scripts. Actually, I really intended European languages, although that term too is a little sloppy. A "western-trending subset of the character sets derived from Old North Semitic" would have been better, but that isn't precise either, and fewer people would have understood it. Explanation below. > It's interestingly enough the fact that Latin is easier for > many. French or Swedish business cards are not usually > double-sided, because they are recognizable even if there are > some accents. If you use them to send a letter, the letter will > arrive even without the accents. So there is quite some danger > that people happily create domain names with accents or other > diacritics, and put them on their business card. I can't speak with any confidence about French or Swedish, but it is certainly possible --as has been pointed out on this list by others more expert than I-- to create some rather serious ambiguities in German by simply dropping diacriticals (not, strictly, accents) without substituting some in-stream convention. Whether the results are still deliverable in the postal system may depend more on the ability of humans to do fuzzy matching of an envelope with a known number of possible targets than with any characteristics that would do us good in the DNS. > > On the other hand, for Arabic or Japanese (or even just Greek > or Cyrillic), there is no expectation nor that your > international business partners will somewhat be able to send > you snail mail with just the 'local' side of the business card, > or even for that matter have any idea of whom they met when > they look at the card a few days later. Therefore I think we > will quickly see things develop to have dual domain names, one > for each side of the business card. And here I would argue that you are correct but, unless you are willing to walk the slippery slope that overhangs the "it would just be easier if everyone learned English" argument, you have it backwards. Your presumption seems to be that my Russian business partners will need to put English on their business cards and, for the DNS, dual-register. I don't see why they shouldn't take the position that it is my responsibility to put Cyrillic on my business cards (presumably the front side, with English on the back). And why they should use cards with English/ASCII on them at all when communicating with, say, their Korean business partners escapes me. Just in passing, there are interesting historical artifacts in some of this, but we should not confuse them with general principles. For example, most Greek characters bear more than a passing resemblance to Roman ones (no surprise, see comment about North Semitic above) and most of the rest are known to those who have studied mathematics. That makes Greek recognizable to a significant fraction of the educated US and Western European population. Does it mean single-sided cards and single-registrations? Well, if I were Greek and wanted to carry out commercial relationships with English-speakers, I wouldn't risk it. But I wouldn't risk it if I were Swedish, either. Similarly, these postal analogies are really very misleading. What is officially deliverable internationally is specified to a collection of treaties which, if my memory is correct, have their origins in the Napoleonic period and require that anything internationally-significant on envelopes moving between countries be in French. So things are deliverable, inter-country, either on the basis of tolerance and fuzzy matching (as mentioned above) or because they are in a Roman-based language. The ideological portion of the IDN discussion involves not imposing another few hundred years of French (or English) on people who aren't native users or those, or closely-related languages... and that position seems to me to be reasonable. > As Paul has noted, in the European context (with few non- > ASCII characters), an approach such as Dan's might even > work, although I don't think it will become widespread, > for various reasons including the fact that people don't > know how to use the hex input feature. I agree, although a reasonable person might suggest that hex input is significantly easier for the typical person than figuring out the algorithms to construct and write an ACE from scratch. >> Now, if the characters used are Latin-based, I can probably >> cope (and I do today). I'm going to recognize the basic >> structures. Even if I have to consult a table, I can match >> what I see on the card with what I see on the screen. In the >> worst case --in which I have no idea how to "type" the >> character-- I can then enter the character position from the >> table into a software program. Interestingly, for that >>... > Already available, in any Japanese input method (not really > for Latin) and in software such as MS Word, and probably > quite a few others. Available for Roman-based characters longer than there has been an Internet-- such tablets are widely used to enable writing (and sometime "speaking") by those who are impaired manually and/or orally. >> First, I can't tell European characters apart to the degree >> needed by IDN. If you had me a card with a native-glyph IDN on >> it, I need to know the language (or a surrogate for the >> language) to pick the right glyphs from a table. I simply >> cannot tell U+0041 from U+0391 from U+0410 by looking at a >> glyph written on a page (and those are, of course, not the only >> examples). I have to know the language context, or apply >> heuristics, to pick one. > > Well, there are situations where this can go wrong. But > as I said above, for Cyrillic and Greek, we'll probably > see a 'two-sided business card' approach. Also, please > note that if there are ambiguities, the main people who > will suffer from them are the locals, so they will try > to avoid them. Although for them less things may be ambiguous > than for you, and it may be easier for you to start inputing > an ascii A and then somehow continue on the rest with tables > (rather than switch the keyboard at the start, as they will > do), the cases where this won't work won't be that frequent. I'm sure it isn't what you intend, but I can't parse the above without a "Roman-based characters are the center of the universe" assumption. >> But that isn't the serious problem either. It turns out that I >> can do just about the same pattern-matching job --looking at a >> glyph, deducing its essential characteristics because I'm >> familiar with the repertorie from which it comes, finding it in >> a table and picking it or entering it by table position-- if >> that card contains Greek, Cyrillic, or Hebrew glyphs. That >>... > You are explorating this too far. Just because you personally > can handle (with a lot of pain) some part of this, don't > expect that this is what your business partners will expect > from you, or what everybody will have to do, and so on. That is exactly my point. I will rush right out and order some fifteen-sided business cards... as soon as a discover a sixteen-dimensional space in which to hand them out. >> So, for the business card, we need, I think, to start asking >> different questions. If want an address on my business card to >> be recognized and usable, after the translator leaves, by a >> Thai native who lacks familiarity with Latin alphabets, I had >>... > Yes. Visitors to such countries interested in business contacts > with such people regularly prepare double-sided namecards. > But it's usually just the name of the person, and maybe the > name of the institution, that is transcribed/translated. > I would not expect the street address or the email address > to be translated, because this may raise expectations that > you can be sent Thai email. For the Web address, that's > different, if your company has a Thai Web site with a > Thai address, it should go on there. But, if a Thai user has a keyboard without ASCII characters on it, and I expect him to communicate with me, I'd better be able to render an address into Thai. Yes? >> Another important inference from this story is almost certainly >> that a solution that works for "ASCII" and "other language" is, >> at least in the long term, inadequate. The same issues exist >> between "other language 1" and "other language 2", and the >> virtual business card will need to be many-sided. And that may >>... > For Web sites for a multinational, clearly yes. For email > addresses, clearly no. If somebody can't type an ASCII > address, how are they going to send you email you can > read? I don't mean to be faceteous here, but, if they wanted to send a picture, or a musical piece, there really would not be an issue, would there? And my examples don't imply that I can't read Thai (I can't, but...) or go find a translator and bring a diskette with me, only that, if my email address is only renderable in ASCII, there may be transmission problems if we are in a world in which such address-exclusivity is not considered problematic. >> Or we can try to turn it into an ACE-like question, where what >> goes on the business card is the "native" set of glyphs plus >> some Latin-based encoding. I'm not sure, as argued above, that >> there is a "native" set of glyphs for the general case. But, >>... > People want names, words, whatever you call it, for their > Web and email addresses. Trying to provide a fallback > for a business card won't work. And translating or > transliterating names is not something that can be automated, > so this has to be solved by double registrations. With the qualification that I think "double" is going to need to be a much larger number, we are probably in agreement about this. But think about what it means: As a database with synchronize and commit primitives, the DNS just stinks. CNAMEs are extremely limited in capability and often surprise people even within that range. So, "multiple registrations", if done in the DNS, will tend to imply multiple names (in different languages) mapping onto the same object/target (RHS of A, MX, or NS RR). But, when changes need to be made in, e.g., the address of some host, zone differences in propagation are going to get us badly, to say nothing of the odds of human errors (e.g., forgetting one or two). But that implies that all of the "multilingual" forms ought to map onto --perhaps with CNAMEs or some new RR or from outside the DNS-- a single ASCII-renderable name which is then the source for, e.g., name to address translation. And, whether it takes us toward a directory or a two-stage intra-DNS lookup, that is a rather different model from the current directions of the IDN WG. > > >> > Probably a common scenario will be a non-technical person >> > receiving a business card with an IDN on it. They'll try >> > to type the name into their browser, and it will fail to >> >... > This is the point where your example becomes extremely > unrealistic. Do you really think somebody from Japan will > hand you a Japanese-only business card and tell you: > "Here is my business card, I don't bother whether it's > of any use to you."? People are a bit more intelligent > than that. Not my example, just my (slightly sarcastic) comments on another note/ point of view. But, usually because I don't have time to prepare properly, I carry English-only cards into places where they may be of no direct (i.e., translator-free) use to the native population fairly regularly. I shouldn't, and I'm sensitive enough to feel bad about it, but I've done it too many times. And I don't know how anyone not intimately familiar with a language (and knowing the language, not just the script in which it is written, can distinguish between an "accent" and a diacritical symbol that is actually part of the character-symbol. john From owner-idn@ops.ietf.org Tue Jan 9 19:51:17 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23836 for ; Tue, 9 Jan 2001 19:51:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G96j-000Jvw-00 for idn-data@psg.com; Tue, 09 Jan 2001 16:27:17 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192]) by psg.com with esmtp (Exim 3.16 #1) id 14G96i-000Jvq-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 16:27:16 -0800 Received: from amc by arwen.cs.berkeley.edu with local (Exim 3.20 #1 (Debian)) id 14G96g-0001ln-00; Tue, 09 Jan 2001 16:27:14 -0800 Date: Wed, 10 Jan 2001 00:27:14 +0000 To: idn working group Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Message-ID: <20010110002714.B6377@arwen.cs.berkeley.edu> References: <200101091148.GAA08869@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200101091148.GAA08869@ietf.org>; from Internet-Drafts@ietf.org on Tue, Jan 09, 2001 at 06:48:57AM -0500 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk > Title : Internationalized Domain Names in URIs and IRIs > Author(s) : M. Duerst > Filename : draft-ietf-idn-uri-00.txt This is interesting. I'll give some comments after a very quick summary for those who haven't read it: URIs will continue to contain only ASCII characters, while IRIs will allow Unicode characters. IRIs can be converted to equivalent URIs by converting each non-ASCII character to UTF-8 and then %hh encoding it. If domain names are eventually allowed to include non-ASCII characters, they will be represented in URIs using the same method. There is a potential problem with host name comparisons. When URIs are compared, the comparison between the host parts is supposed to be case-insensitive. Software comparing IRIs presumably knows about case-equivalence among non-ASCII characters, but software comparing URIs might not. That means IRIs might use mixed-case host names, but when they are converted to URIs the non-ASCII characters must be forced to lower case (in the host part only, not the path). The draft tells how URIs can be converted back to IRIs. It would be nice if the case of the Unicode characters in the host names could be recovered. Fortunately, the UTF-8-%hh encoding of any non-ASCII character always begins with C, D, E, or F. Therefore I suggest recording the original case of the non-ASCII character as the case of the first letter of the %hh encoding. By the way, if an ACE is adopted for IDNs, there are two very different ways it could be viewed, which has implications for this URI proposal. Perhaps domain names really contain non-ASCII characters, and the ACE is merely a representation that's friendlier to existing software and protocols. In that case, this URI proposal applies. On the other hand, perhaps domain names do not really contain non-ASCII characters; the *ACE* is the real name, and the Unicode is merely a representation that's friendlier to humans. In that case, this URI proposal would be moot, because domain names would never contain non-ASCII characters. I'm not advocating either viewpoint (yet), but it will have to be decided. AMC From owner-idn@ops.ietf.org Tue Jan 9 21:53:44 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25667 for ; Tue, 9 Jan 2001 21:53:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GBBx-000MXt-00 for idn-data@psg.com; Tue, 09 Jan 2001 18:40:49 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14GBBw-000MXn-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 18:40:48 -0800 Received: (qmail 7621 invoked by uid 1001); 10 Jan 2001 02:40:03 -0000 Date: 10 Jan 2001 02:40:03 -0000 Message-ID: <20010110024003.3268.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Where will we see bad domain names? References: <200101051007.f05A7ll14252@malmo.trab.se> <002901c0772a$5c2eb2f0$6e5b8e18@mark> <20010107222917.4166.qmail@cr.yp.to> <4.2.0.58.J.20010109205454.0397e220@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Martin J. Duerst writes: > The classical case is half-width and full-width alphabetics and > Katakana in Japan. But we've already learned that nameprep doesn't solve the Japanese name-typing problem. People in Japan aren't getting the right dots. The obvious solution is to improve the address-typing support in the operating system's Japanese keyboard interface. That's the only piece of software that has to worry about bad domain names. It will provide a friendly Japanese-specific environment for typing good domain names. It will deal with the dot problem. Done. In contrast, Patrik and Bill want us to add bad->good conversion code (and Japanese dot handling) to Outlook, Messenger, Eudora, Mutt, Pine, Sendmail (which will have to check whether incoming IDNs match UTF-8 domain names in user-typed configuration files), qmail (same reason), Exchange, IMail, Exim, Post.Office, Explorer, Communicator, Opera, Lynx, w3m, Apache, IIS, Enterprise, WebLogic, Zeus, BIND, djbdns, Webmin, etc. That is not good software engineering. Of course, if every one of those programs has to be changed, then every one of them has to be redeployed. Patrik claims that this is necessary for full IDN support. But my solution will allow some of these programs to be left alone: they can already handle UTF-8 IDNs without trouble. ---Dan From owner-idn@ops.ietf.org Tue Jan 9 22:17:26 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25795 for ; Tue, 9 Jan 2001 22:17:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GBbe-000N5L-00 for idn-data@psg.com; Tue, 09 Jan 2001 19:07:22 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14GBbd-000N5E-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 19:07:21 -0800 Received: (qmail 22139 invoked by uid 1001); 10 Jan 2001 03:06:34 -0000 Date: 10 Jan 2001 03:06:34 -0000 Message-ID: <20010110030634.446.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt References: <200101091148.GAA08869@ietf.org> <20010110002714.B6377@arwen.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Adam M. Costello writes: > There is a potential problem with host name comparisons. All the problems you describe go away if nameprep is handled in the way I've been suggesting: registries prohibit bad names, users have whatever software is needed to type good names, and most programs are left alone. > Software comparing IRIs presumably knows about case-equivalence among > non-ASCII characters, but software comparing URIs might not. Good names never include uppercase non-ASCII characters. Comparisons of non-ASCII characters are bitwise comparisons. > That means IRIs might use mixed-case host names, but when they are > converted to URIs the non-ASCII characters must be forced to lower > case (in the host part only, not the path). All that complexity disappears. Converting IRI to URI is a simple matter of converting Unicode to UTF-8. ---Dan From owner-idn@ops.ietf.org Tue Jan 9 23:00:42 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26991 for ; Tue, 9 Jan 2001 23:00:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GC4Y-000Nhl-00 for idn-data@psg.com; Tue, 09 Jan 2001 19:37:14 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14GC4X-000Nhf-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 19:37:13 -0800 Received: (qmail 20881 invoked by uid 1001); 10 Jan 2001 03:36:30 -0000 Date: 10 Jan 2001 03:36:30 -0000 Message-ID: <20010110033630.21269.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] internationalized email addresses References: <01JYNVVQ1AV60000CO@mauve.mrochek.com> <20010109003259.A3434@arwen.cs.berkeley.edu> <20010109003259.A3434@arwen.cs.berkeley.edu> <01JYOLWBLNIE0002SZ@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk ned.freed@innosoft.com writes: > There is little point in considering local parts now unless they > additionally constrain the problem. (AFAIK they do not.) Actually, they do. There are a huge number of mailing lists run by my ezmlm software and its variants; these programs use Return-Path: for deliveries to user@userhost. If your mail software has small limits on address length, switching userhost from a UTF-8 IDN to an ACE IDN will drastically increase your chance of hitting those limits. ---Dan From owner-idn@ops.ietf.org Tue Jan 9 23:19:20 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27051 for ; Tue, 9 Jan 2001 23:19:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GCS3-000OFB-00 for idn-data@psg.com; Tue, 09 Jan 2001 20:01:31 -0800 Received: from epa.secret.org ([206.220.140.150] ident=0) by psg.com with esmtp (Exim 3.16 #1) id 14GCS2-000OF5-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 20:01:31 -0800 Received: from localhost (lucid@localhost) by epa.secret.org (8.9.3/8.9.1) with ESMTP id XAA73987; Tue, 9 Jan 2001 23:01:29 -0500 (EST) Date: Tue, 9 Jan 2001 23:01:28 -0500 (EST) From: William Morris X-Sender: lucid@epa.secret.org To: "D. J. Bernstein" cc: idn@ops.ietf.org Subject: Re: [idn] Where will we see bad domain names? In-Reply-To: <20010110024003.3268.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 10 Jan 2001, D. J. Bernstein wrote: > The obvious solution is to improve the address-typing support in the > operating system's Japanese keyboard interface. That's the only piece of > software that has to worry about bad domain names. It will provide a > friendly Japanese-specific environment for typing good domain names. It > will deal with the dot problem. > > Done. I am not sure I am following you. Are you suggesting that the Input Method Editor be rewritten to do the right thing? or the domain name text widget? > In contrast, Patrik and Bill want us to add bad->good conversion code > (and Japanese dot handling) to Outlook, Messenger, Eudora, Mutt, Pine, > Sendmail (which will have to check whether incoming IDNs match UTF-8 > domain names in user-typed configuration files), qmail (same reason), > Exchange, IMail, Exim, Post.Office, Explorer, Communicator, Opera, Lynx, > w3m, Apache, IIS, Enterprise, WebLogic, Zeus, BIND, djbdns, Webmin, etc. Something like nameprep is already in place. U+0061 == U+0041 aka A == a U+0041 LATIN CAPITAL LETTER A U+0061 LATIN SMALL LETTER A How do we handle the same characters at seperate code points? U+FF21 FULLWIDTH LATIN CAPITAL LETTER A U+FF41 FULLWIDTH LATIN SMALL LETTER A Should code point location be preserved or mapped? U+0061 == U+0041 == U+FF21 == U+FF41 or (U+FF21 -> U+0041) == (U+FF41 -> U+0061) Then how should this be handled? U+30F2 KATAKANA LETTER WO U+FF66 HALFWIDTH KATAKANA LETTER WO > Of course, if every one of those programs has to be changed, then every > one of them has to be redeployed. Patrik claims that this is necessary > for full IDN support. But my solution will allow some of these programs > to be left alone: they can already handle UTF-8 IDNs without trouble. My cynical view is that it is better to rewrite the applications and protocols to support UTF-8. Until then every other language will be second to thouse that map cleanly into ASCII. I dont see things changing after they get implemented. -Bill From owner-idn@ops.ietf.org Wed Jan 10 00:27:41 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27993 for ; Wed, 10 Jan 2001 00:27:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GDT8-000PdW-00 for idn-data@psg.com; Tue, 09 Jan 2001 21:06:42 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14GDT6-000PdQ-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 21:06:40 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA24521; Wed, 10 Jan 2001 00:06:37 -0500 (EST) Message-Id: <200101100506.AAA24521@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] internationalized email addresses In-reply-to: Your message of "10 Jan 2001 03:36:30 GMT." <20010110033630.21269.qmail@cr.yp.to> Date: Wed, 10 Jan 2001 00:06:37 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > There is little point in considering local parts now unless they > > additionally constrain the problem. (AFAIK they do not.) > > Actually, they do. agreed. I'm not sure that IDN is the place to discuss it, but there are several potentially hairy issues associated with using ACE for local-parts. including: - dots in local-parts (are they ACE encoded or do we just encode the atoms and leave the dots alone?) - quoted-strings, and the potential for multiple representations - specials (other than ".") within a local-part which is ACE-encoded - similarly for other Unicode characters that resemble specials now it's quite possibly the case that all of these can be worked out satisfactorily, and it Sure Would Be Nice if the same encoding routine that is used for IDNs could also be used for local-parts of an email address. but it's a bit of a leap to say that whatever ACE is chosen for IDNs will Just Work for local-parts. Keith From owner-idn@ops.ietf.org Wed Jan 10 01:21:15 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00156 for ; Wed, 10 Jan 2001 01:21:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GEQe-00011A-00 for idn-data@psg.com; Tue, 09 Jan 2001 22:08:12 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.16 #1) id 14GEQd-000112-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 22:08:11 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JYPF5070XC0002SZ@mauve.mrochek.com> for idn@ops.ietf.org; Tue, 09 Jan 2001 22:08:06 -0700 (PDT) Date: Tue, 09 Jan 2001 22:00:45 -0700 (PDT) From: ned.freed@innosoft.com Subject: Re: [idn] internationalized email addresses In-reply-to: "Your message dated Wed, 10 Jan 2001 00:06:37 -0500" <200101100506.AAA24521@astro.cs.utk.edu> To: idn@ops.ietf.org Message-id: <01JYPW9U4HP80002SZ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20010110033630.21269.qmail@cr.yp.to> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Since this is entirely out of scope for the WG this will be my last posting on the subject. > I'm not sure that IDN is the place to discuss it, It isn't. See the WG charter. > but > there are several potentially hairy issues associated with using > ACE for local-parts. including: > ... > now it's quite possibly the case that all of these can be worked out > satisfactorily, and it Sure Would Be Nice if the same encoding > routine that is used for IDNs could also be used for local-parts > of an email address. The constaints on local parts are a strict subset of those on parts of domain names, so I don't see a problem here. > but it's a bit of a leap to say that whatever > ACE is chosen for IDNs will Just Work for local-parts. Given the constraints on ACEs I disagree, but again, even if I'm wrong I think letting additional requirements from other identifier spaces leak in here is a really bad idea. Ned From owner-idn@ops.ietf.org Wed Jan 10 03:27:17 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12183 for ; Wed, 10 Jan 2001 03:27:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GG9y-0003H5-00 for idn-data@psg.com; Tue, 09 Jan 2001 23:59:06 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14GG9x-0003Gy-00 for idn@ops.ietf.org; Tue, 09 Jan 2001 23:59:05 -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 f0A7wvl00896; Wed, 10 Jan 2001 08:58:57 +0100 (MET) Received: from valinor by valinor.malmo.trab.se (8.10.1/TRM-1-KLIENT); Wed, 10 Jan 2001 08:58:57 +0100 (MET) (MET) Message-Id: <200101100758.f0A7wvX06473@valinor.malmo.trab.se> Date: Wed, 10 Jan 2001 08:58:57 +0100 (MET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domainnames) To: klensin@jck.com Cc: idn@ops.ietf.org, duerst@w3.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: SVY7y4ckwr8LrIaP4BsCNQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id DAA12183 >And I don't know how anyone not intimately familiar with a >language (and knowing the language, not just the script in which >it is written, can distinguish between an "accent" and a >diacritical symbol that is actually part of the character-symbol. > I agree very much on that. Swedish have a 29 character latin alphabet. It has all in the English alphabet and three more "åäö". Those three are true characters, it is not an accented a or o. But many who for example is used to just the English alphabet will think they are an a or o with a ring or diaresis above. On the other hand you can use accents in Swedish, for example "á", but this does not make "åäö" accented characters. - If we would like to have an alternate form of domain name on business cards that could be used in most countries, we could use something like this: Dan.Oscarsson@23.456.346.2.0 where this is a number registered as equivalent with my normal domain name. The number can be looked up through DNS and handled as normal domains. The only difference is that the name is composed of only digits (to be really portable) and is not related to the characters in the normal domain name. And here you could even change the spelling of the normal domain name and have the number version remain the same. Why not give everybody in the world their own domain name in the number format when they are born, to be theirs for life? Dan From owner-idn@ops.ietf.org Wed Jan 10 04:51:15 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12667 for ; Wed, 10 Jan 2001 04:51:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GHat-0005Ri-00 for idn-data@psg.com; Wed, 10 Jan 2001 01:30:59 -0800 Received: from arwen.cs.berkeley.edu ([128.32.46.192]) by psg.com with esmtp (Exim 3.16 #1) id 14GHas-0005RO-00 for idn@ops.ietf.org; Wed, 10 Jan 2001 01:30:59 -0800 Received: from amc by arwen.cs.berkeley.edu with local (Exim 3.20 #1 (Debian)) id 14GHas-00023W-00; Wed, 10 Jan 2001 01:30:58 -0800 Date: Wed, 10 Jan 2001 09:30:57 +0000 To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Message-ID: <20010110093057.A7861@arwen.cs.berkeley.edu> References: <01JYNVVQ1AV60000CO@mauve.mrochek.com> <20010109003259.A3434@arwen.cs.berkeley.edu> <20010109003259.A3434@arwen.cs.berkeley.edu> <01JYOLWBLNIE0002SZ@mauve.mrochek.com> <20010110033630.21269.qmail@cr.yp.to> <200101091148.GAA08869@ietf.org> <20010110002714.B6377@arwen.cs.berkeley.edu> <20010110030634.446.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010110030634.446.qmail@cr.yp.to>; from djb@cr.yp.to on Wed, Jan 10, 2001 at 03:06:34AM -0000 From: "Adam M. Costello" Sender: owner-idn@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: > Good names never include uppercase non-ASCII characters. That would solve the problem, but at a price. ASCII names are allowed to use mixed case. It would be unfair to deny the same flexibility to non-ASCII names. Maybe it's worth sacrificing that flexibility for the sake of simplicity, but it's something to consider. > If your mail software has small limits on address length, switching > userhost from a UTF-8 IDN to an ACE IDN will drastically increase your > chance of hitting those limits. UTF-8 gets less than 6 bits per octet on average for the non-ASCII octets, and the ACEs generally use base-32, which is 5 bits per character, so that's not much different. And since some of the ACEs employ compression techniques, they might even be shorter than UTF-8 for many strings. AMC From owner-idn@ops.ietf.org Wed Jan 10 04:57:15 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12695 for ; Wed, 10 Jan 2001 04:57:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GHiz-0005cu-00 for idn-data@psg.com; Wed, 10 Jan 2001 01:39:21 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14GHiz-0005cm-00 for idn@ops.ietf.org; Wed, 10 Jan 2001 01:39:21 -0800 Received: from P2 ("port 1275"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G6X00AKYXHAZT@a4.jck.com> for idn@ops.ietf.org; Wed, 10 Jan 2001 04:39:11 -0500 (EST) Date: Wed, 10 Jan 2001 04:39:09 -0500 From: John C Klensin Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domainnames) In-reply-to: <200101100758.f0A7wvX06473@valinor.malmo.trab.se> To: Dan Oscarsson Cc: idn@ops.ietf.org, duerst@w3.org Message-id: <4143973658.979101549@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Wednesday, 10 January, 2001 08:58 +0100 Dan Oscarsson wrote: > If we would like to have an alternate form of domain name on > business cards that could be used in most countries, we could > use something like this: Dan.Oscarsson@23.456.346.2.0 > where this is a number registered as equivalent with my normal > domain name. The number can be looked up through DNS and > handled as normal domains. The only difference is that the > name is composed of only digits (to be really portable) and is > not related to the characters in the normal domain name. And > here you could even change the spelling of the normal domain > name and have the number version remain the same. This is, of course, a slight variation on the argument that has been made to ICANN for supplementing the "normal" DNS with a system based on telephone numbers but with mappings paralleling normal DNS records rather than telephony ones (e.g., to A, MX, and NS RRs, not to NAPTR ones). > Why not give > everybody in the world their own domain name in the number > format when they are born, to be theirs for life? Besides the privacy outcry it would cause in some countries? :-( john From owner-idn@ops.ietf.org Wed Jan 10 21:21:01 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09396 for ; Wed, 10 Jan 2001 21:21:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GX1W-0004va-00 for idn-data@psg.com; Wed, 10 Jan 2001 17:59:30 -0800 Date: 11 Jan 2001 01:07:41 -0000 Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Adam M. Costello writes: > UTF-8 gets less than 6 bits per octet on average for the non-ASCII > octets, and the ACEs generally use base-32, which is 5 bits per > character, so that's not much different. ACEs also include several bytes to distinguish themselves from existing ASCII names. If you subscribe to my publicfile mailing list, you'll receive email asking you to confirm the subscription. The Reply-To in the email will look like this: publicfile-sc.942884323.agghmppopdgakhmfhbaf-amc=cs.berkeley.edu@list.cr.yp.to Now, what happens if your software rejects mail for usernames longer than 64 bytes? publicfile-sc.942884323.agghmppopdgakhmfhbaf-amc=.xxx is already 53 bytes, and the number is a timestamp that will soon increase by another digit, so you have only 10 bytes for the rest of the name. If you wanted an IDN, what would it be? Would it fit into 10 bytes with ACE, not counting the .com? > ASCII names are allowed to use mixed case. It would be unfair to deny > the same flexibility to non-ASCII names. I'd be happy to get rid of uppercase ASCII too. However, that would require a transition period. In contrast, we aren't saddled with existing uppercase IDNs. ---Dan From owner-idn@ops.ietf.org Thu Jan 11 00:56:59 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13890 for ; Thu, 11 Jan 2001 00:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GaQK-000Blf-00 for idn-data@psg.com; Wed, 10 Jan 2001 21:37:20 -0800 Received: from blake.i-email.net ([203.126.116.232]) by psg.com with esmtp (Exim 3.16 #1) id 14GaQJ-000BlY-00 for idn@ops.ietf.org; Wed, 10 Jan 2001 21:37:19 -0800 Received: from maynardibm (unknown [202.55.72.10]) by blake.i-email.net (Postfix) with SMTP id 2456BA8901; Thu, 11 Jan 2001 13:33:14 +0800 (SGT) Message-ID: <00e201c07b90$83d0f330$8f00a8c0@maynardibm> From: "Maynard Kang" To: "D. J. Bernstein" , References: Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Date: Thu, 11 Jan 2001 13:36:56 +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 Dan, > Now, what happens if your software rejects mail for usernames longer > than 64 bytes? publicfile-sc.942884323.agghmppopdgakhmfhbaf-amc=.xxx is > already 53 bytes, and the number is a timestamp that will soon increase > by another digit, so you have only 10 bytes for the rest of the name. > > If you wanted an IDN, what would it be? Would it fit into 10 bytes with > ACE, not counting the .com? The 10 byte constraint you are referring to is entirely an *application* problem rather than an *application layer* problem. If you use UTF-8 (or any 8-bit CES) in e-mail addresses, SMTP servers which adhere strictly to RFC 821 will blow up due to the US-ASCII restriction. If you use ACE, perhaps only your mailing list software will blow up. I think there are more systems which deal with SMTP than with mailing lists. The basic premise is this: any solution to an internetworking problem should first deal with layers as low as possible before moving upwards, as problems at lower layers tend to affect a greater number of systems. maynard From owner-idn@ops.ietf.org Thu Jan 11 03:29:40 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27488 for ; Thu, 11 Jan 2001 03:29:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Gcel-000Fzp-00 for idn-data@psg.com; Thu, 11 Jan 2001 00:00:23 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Gcek-000Fzj-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 00:00:22 -0800 Received: (qmail 13527 invoked by uid 1001); 11 Jan 2001 07:59:38 -0000 Date: 11 Jan 2001 07:59:38 -0000 Message-ID: <20010111075938.3619.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt References: <00e201c07b90$83d0f330$8f00a8c0@maynardibm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk The general question here is ``What will happen if we start using IDNs before we do the software upgrades necessary to make IDNs work?'' UTF-8 IDNs will cause trouble in this case. The point I'm making is that ACE IDNs will cause trouble too. UTF-8 IDNs will lead to additional non-821-compliant addresses in SMTP and additional non-822-compliant addresses in message header fields. The resulting 8-bit addresses are known to cause trouble for some programs. ACE IDNs will lead to additional non-821-compliant addresses in SMTP and additional non-822-compliant addresses in message header fields. The resulting long addresses are known to cause trouble for some programs. Maynard Kang writes: > If you use UTF-8 (or any 8-bit CES) in e-mail addresses, SMTP servers which > adhere strictly to RFC 821 will blow up due to the US-ASCII restriction. If > you use ACE, perhaps only your mailing list software will blow up. My software doesn't have any trouble. Please learn to read. What matters is that it effectively lowers any limits that your software might place on address length. > I think there are more systems which deal with SMTP than with mailing lists. ezmlm and its variants send a huge amount of mail every day. Keep in mind that (1) qmail is running on a very active 10% of the Internet's SMTP servers and (2) automatic bounce handling, via these long return addresses, is one of the top ten reasons that people install qmail. > problems at lower layers tend to affect a greater number of systems It would help to skip the ``layer'' commentary and focus on the effects. The effects are what users care about. ---Dan From owner-idn@ops.ietf.org Thu Jan 11 07:49:34 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29528 for ; Thu, 11 Jan 2001 07:49:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GgkK-000NqA-00 for idn-data@psg.com; Thu, 11 Jan 2001 04:22:24 -0800 Received: from blake.i-email.net ([203.126.116.232]) by psg.com with esmtp (Exim 3.16 #1) id 14GgkI-000Nq4-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 04:22:23 -0800 Received: from maynardibm (unknown [202.55.72.10]) by blake.i-email.net (Postfix) with SMTP id 44204A8904; Thu, 11 Jan 2001 20:18:12 +0800 (SGT) Message-ID: <022401c07bc9$17911180$8f00a8c0@maynardibm> From: "Maynard Kang" To: "D. J. Bernstein" , References: <00e201c07b90$83d0f330$8f00a8c0@maynardibm> <20010111075938.3619.qmail@cr.yp.to> Subject: ACE length in e-mail addresses (was: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt) Date: Thu, 11 Jan 2001 20:21:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 > UTF-8 IDNs will cause trouble in this case. The point I'm making is that > ACE IDNs will cause trouble too. > > UTF-8 IDNs will lead to additional non-821-compliant addresses in SMTP > and additional non-822-compliant addresses in message header fields. The > resulting 8-bit addresses are known to cause trouble for some programs. > > ACE IDNs will lead to additional non-821-compliant addresses in SMTP and > additional non-822-compliant addresses in message header fields. The > resulting long addresses are known to cause trouble for some programs. Right, I agree both solutions are potential troublemakers. However I still think that the negative implications of using UTF-8 IDNs will be more far-reaching than using ACE IDNs. Long addresses appear more tolerable than 8-bit addresses; as 821 speaks of "to the maximum possible, implementation techniques which impose no limits on the length of these objects should be used" in spite of stating a 64-byte limit on local-parts and 64-byte limit on domain. (An interesting side note: the latest incarnation of draft-ietf-drums-smtpupd seems to provide for a new 255-byte limit on domain but still keeps the 64-byte limit on local-parts. Maybe that should be changed too. Anyway, this is a drums issue) 822 imposes no limits, I believe. There is adequate provision for the folding of long header fields. > My software doesn't have any trouble. Please learn to read. What matters > is that it effectively lowers any limits that your software might place > on address length. My software doesn't either. I think we both mean "your" in a collective sense, right? > ezmlm and its variants send a huge amount of mail every day. Keep in > mind that (1) qmail is running on a very active 10% of the Internet's > SMTP servers and (2) automatic bounce handling, via these long return > addresses, is one of the top ten reasons that people install qmail. How about servers which are running sendmail and will fall over and die when they see UTF-8? According to their site, Sendmail "handles an estimated 75 percent of the Internet's email traffic". Actually I switched to qmail for a different reason, but anyway... maynard From owner-idn@ops.ietf.org Thu Jan 11 10:07:00 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02656 for ; Thu, 11 Jan 2001 10:06:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Gizj-0002a6-00 for idn-data@psg.com; Thu, 11 Jan 2001 06:46:27 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14Gizi-0002Zk-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 06:46:26 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA04417; Thu, 11 Jan 2001 09:46:18 -0500 (EST) Message-Id: <200101111446.JAA04417@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-D ACTION:draft-ietf-idn-uri-00.txt In-reply-to: Your message of "11 Jan 2001 07:59:38 GMT." <20010111075938.3619.qmail@cr.yp.to> Date: Thu, 11 Jan 2001 09:46:17 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > The general question here is ``What will happen if we start using IDNs > before we do the software upgrades necessary to make IDNs work?'' > > UTF-8 IDNs will cause trouble in this case. The point I'm making is that > ACE IDNs will cause trouble too. I doubt that anyone disagrees with you on that, but the presumption is that ACE IDNs will cause less trouble than UTF-8 IDNs. Every UTF-8 IDN (except for IDNs that consist of only ASCII characters) will cause trouble for a significant number of UAs and MTAs. But (assuming careful choice of the ACE) few ACE IDNs are likely to be significantly longer than UTF-8 IDNs, and the number of MTAs and UAs that have trouble with long addresses is significantly less than the number of MTAs and UAs that have trouble with 8-bit characters. Indeed, one of the complaints that has been frequently made about UTF-8 is that it's a very pessimal encoding for some languages; hence, some of the ACE schemes are designed to be more compact than UTF-8. > Maynard Kang writes: > > If you use UTF-8 (or any 8-bit CES) in e-mail addresses, SMTP servers which > > adhere strictly to RFC 821 will blow up due to the US-ASCII restriction. If > > you use ACE, perhaps only your mailing list software will blow up. > > My software doesn't have any trouble. You posted an example where you claimed that your software would have trouble, because that software generates unusually long local-parts, leaving very little room for domain names. You claimed that ACE IDNs would cause those addresses to become even longer, thus preventing your software from functioning. But you could just as easily find examples where UTF-8 IDNs would cause those addresses to become longer. And depending on your choice of ACE scheme and your choice of IDN, you can find examples to support an argument that either representation is longer than the other. It's almost inevitable that representation of strings with a character repertoire greater than 2**16 in size will take up more space than a representation of strings with a character repertoire less than 2**8 in size. Thus, longer names is part of the price of having IDNs, no matter what encoding scheme is used. Of course, we do want to find a compact encoding for IDNs, but the right answer seems to be a tradeoff between maximizing space efficiency, minimizing implementation complexity, and minimizing impact on existing software that expects ASCII. Keith From owner-idn@ops.ietf.org Thu Jan 11 14:43:28 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13304 for ; Thu, 11 Jan 2001 14:43:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Gn71-000BHb-00 for idn-data@psg.com; Thu, 11 Jan 2001 11:10:15 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Gn6z-000BHU-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 11:10:13 -0800 Received: (qmail 25379 invoked by uid 1001); 11 Jan 2001 19:09:29 -0000 Date: 11 Jan 2001 19:09:29 -0000 Message-ID: <20010111190929.13082.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt References: <20010111075938.3619.qmail@cr.yp.to> <200101111446.JAA04417@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Keith Moore writes: > You posted an example where you claimed that your software would have > trouble, False. > because that software generates unusually long local-parts, > leaving very little room for domain names. My mailing-list software often generates local-parts that include the _subscriber's_ local-part and domain name. The result may exceed length limits in the _subscriber's_ mail software, or in relays. > the presumption is that ACE IDNs will cause less trouble than UTF-8 > IDNs. Actually, people have been claiming that ACE IDNs will cause no trouble at all, and suggesting this as a litmus test for IDN solutions. RFC 2825, for example, says that _some_ of the proposals will cause failures if software isn't upgraded first. In fact, _all_ of the proposals will cause failures if software isn't upgraded first. As for the frequency and severity of failures: What matters is the software involved in deliveries _where IDNs appear_. People likely to use IDNs are also people likely to have already moved to 8-bit-clean software---because 8-bit data shows up all the time in Subject lines, despite Keith's efforts to force people to encode it. > But (assuming careful choice of the ACE) few ACE IDNs are likely to be > significantly longer than UTF-8 IDNs, That simply isn't true. A 10-byte limit causes much more trouble for the ACE proposals than for UTF-8. Try some examples! ---Dan From owner-idn@ops.ietf.org Thu Jan 11 15:02:01 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13567 for ; Thu, 11 Jan 2001 15:02:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Gnhe-000CVa-00 for idn-data@psg.com; Thu, 11 Jan 2001 11:48:06 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Gnhd-000CVT-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 11:48:05 -0800 Received: (qmail 8023 invoked by uid 1001); 11 Jan 2001 19:47:18 -0000 Date: 11 Jan 2001 19:47:18 -0000 Message-ID: <20010111194718.1192.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: [idn] Sendmail usage estimates References: <00e201c07b90$83d0f330$8f00a8c0@maynardibm> <20010111075938.3619.qmail@cr.yp.to> <022401c07bc9$17911180$8f00a8c0@maynardibm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idn@ops.ietf.org Precedence: bulk Maynard Kang writes: > How about servers which are running sendmail and will fall over and > die when they see UTF-8? According to their site, Sendmail "handles an > estimated 75 percent of the Internet's email traffic". That estimate is completely bogus. It's a wild misrepresentation of some obsolete information that was once on the Sendmail Inc. web pages: viz., that more than 75% of the Internet's SMTP servers were running Sendmail. (The current web pages also have obsolete information, but I don't see the wild misrepresentation. Where exactly did you get the quote?) See http://cr.yp.to/surveys/sendmail.html for the complete story. ---Dan From owner-idn@ops.ietf.org Thu Jan 11 15:28:11 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14008 for ; Thu, 11 Jan 2001 15:28:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Gnys-000D8T-00 for idn-data@psg.com; Thu, 11 Jan 2001 12:05:54 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14Gnyr-000D8N-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 12:05:53 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA07518; Thu, 11 Jan 2001 15:05:51 -0500 (EST) Message-Id: <200101112005.PAA07518@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-D ACTION:draft-ietf-idn-uri-00.txt In-reply-to: Your message of "11 Jan 2001 19:09:29 GMT." <20010111190929.13082.qmail@cr.yp.to> Date: Thu, 11 Jan 2001 15:05:50 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Keith Moore writes: > > You posted an example where you claimed that your software would have > > trouble, > > False. The fact that the bugs are detected elsewhere is hardly a justification for poor design choices in your software, especially when those choices exceed the design limitations that are documented in the mail protocol specifications. > > the presumption is that ACE IDNs will cause less trouble than UTF-8 > > IDNs. > > Actually, people have been claiming that ACE IDNs will cause no trouble > at all, and suggesting this as a litmus test for IDN solutions. Such claims are obviously exaggerated. Any IDN scheme will cause some degree of disruption, the question is how much. > As for the frequency and severity of failures: What matters is the > software involved in deliveries _where IDNs appear_. People likely to > use IDNs are also people likely to have already moved to 8-bit-clean > software---because 8-bit data shows up all the time in Subject lines, 8-bit data does show up all the time in Subject lines, and in other fields. It is also quite often mangled beyond recognition, due to a combination of software that is unable to cope with 8 bit text, software that attempts to convert 8-bit text to RFC 2047 form, and software that tries to perform character set conversions on such text without knowing the original character set. > > But (assuming careful choice of the ACE) few ACE IDNs are likely to be > > significantly longer than UTF-8 IDNs, > > That simply isn't true. A 10-byte limit causes much more trouble for the > ACE proposals than for UTF-8. Try some examples! A 10-byte limit causes trouble for lots of ordinary domain names, so I fail to see how this is terribly significant. Keith From owner-idn@ops.ietf.org Thu Jan 11 16:28:31 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15045 for ; Thu, 11 Jan 2001 16:28:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GosM-000F3v-00 for idn-data@psg.com; Thu, 11 Jan 2001 13:03:14 -0800 Received: from c193.150.248.34.cm-upc.chello.se ([193.150.248.34] helo=ledig.paf.se) by psg.com with esmtp (Exim 3.16 #1) id 14GosK-000F3o-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 13:03:13 -0800 Received: from [192.168.1.11] (dhcp-11.paf.se [192.168.1.11]) by ledig.paf.se (8.9.3/8.9.3) with ESMTP id WAA74865; Thu, 11 Jan 2001 22:03:01 +0100 (CET) (envelope-from paf@cisco.com) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200101112005.PAA07518@astro.cs.utk.edu> References: <200101112005.PAA07518@astro.cs.utk.edu> Date: Thu, 11 Jan 2001 21:57:01 +0100 To: Keith Moore , "D. J. Bernstein" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 15.05 -0500 01-01-11, Keith Moore wrote: >It is also quite often mangled beyond recognition, due to >a combination of software that is unable to cope with 8 bit text, >software that attempts to convert 8-bit text to RFC 2047 form, and >software that tries to perform character set conversions on such >text without knowing the original character set. Most problematic are software which send ISO 8859-1 untagged in various places. I get about 10% of my messages in that form (2-5/day out of about 20-50 which are in Swedish). Only visible if you run a mail client which doesn't use ISO 8859-1 as native charset of course. paf From owner-idn@ops.ietf.org Thu Jan 11 21:24:53 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17607 for ; Thu, 11 Jan 2001 21:24:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GtV9-000PP0-00 for idn-data@psg.com; Thu, 11 Jan 2001 17:59:35 -0800 Received: from [203.126.116.228] (helo=mail.i-dns.net) by psg.com with esmtp (Exim 3.16 #1) id 14GtV9-000POt-00 for idn@ops.ietf.org; Thu, 11 Jan 2001 17:59:35 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 53FBEFFC06; Fri, 12 Jan 2001 09:59:33 +0800 (SGT) Message-ID: <011801c07c3b$1ab2e420$8e00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "D. J. Bernstein" , References: <20010111075938.3619.qmail@cr.yp.to> <200101111446.JAA04417@astro.cs.utk.edu> <20010111190929.13082.qmail@cr.yp.to> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Date: Fri, 12 Jan 2001 09:58:05 +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 Without going to the details, it is possible to design an ACE which has almost the resultant length as UTF-8 if "10-byte limit" is your concern. -James Seng > > But (assuming careful choice of the ACE) few ACE IDNs are likely to be > > significantly longer than UTF-8 IDNs, > > That simply isn't true. A 10-byte limit causes much more trouble for the > ACE proposals than for UTF-8. Try some examples! > > ---Dan > From owner-idn@ops.ietf.org Fri Jan 12 03:50:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06321 for ; Fri, 12 Jan 2001 03:50:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14GzKT-000Bg4-00 for idn-data@psg.com; Fri, 12 Jan 2001 00:12:57 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14GzKS-000Bfw-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 00:12:56 -0800 Received: (qmail 6070 invoked by uid 1001); 12 Jan 2001 08:11:56 -0000 Date: 12 Jan 2001 08:11:56 -0000 Message-ID: <20010112081156.24792.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt References: <20010111075938.3619.qmail@cr.yp.to> <200101111446.JAA04417@astro.cs.utk.edu> <20010111190929.13082.qmail@cr.yp.to> <011801c07c3b$1ab2e420$8e00a8c0@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng/Personal writes: > Without going to the details, it is possible to design an ACE which > has almost the resultant length as UTF-8 Without gigantic tables of common character sequences? Without using punctuation or control characters that people can't type? Without a noticeable risk of misinterpreting existing ASCII names? If it's possible to do this, go ahead! In the meantime, I'm going to focus on the proposals that have actually been worked out. > if "10-byte limit" is your concern. There's nothing special about 10. My examples show that every extra byte poses a risk; we don't have the 63-byte safe harbor that some people have imagined. A user's 5-byte or 10-byte or 15-byte domain name can indirectly trip his software's 64-byte local-part length limit. ---Dan From owner-idn@ops.ietf.org Fri Jan 12 04:38:08 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06504 for ; Fri, 12 Jan 2001 04:38:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H0Ox-000Dl2-00 for idn-data@psg.com; Fri, 12 Jan 2001 01:21:39 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14H0Ou-000Dkw-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 01:21:38 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 32223FFC03; Fri, 12 Jan 2001 17:21:35 +0800 (SGT) Message-ID: <025b01c07c78$da8d31a0$8e00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "D. J. Bernstein" , References: <20010111075938.3619.qmail@cr.yp.to> <200101111446.JAA04417@astro.cs.utk.edu> <20010111190929.13082.qmail@cr.yp.to> <011801c07c3b$1ab2e420$8e00a8c0@jamessonyvaio> <20010112081156.24792.qmail@cr.yp.to> Subject: Re: [idn] I-D ACTION:draft-ietf-idn-uri-00.txt Date: Fri, 12 Jan 2001 17:20: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 You said there is a length problem of ACE. I am saying that ACE could be design with the almost the same length as UTF-8 so it is not a concern. > James Seng/Personal writes: > > Without going to the details, it is possible to design an ACE which > > has almost the resultant length as UTF-8 > > Without gigantic tables of common character sequences? Without using > punctuation or control characters that people can't type? Why would ACE have these problems? > Without a > noticeable risk of misinterpreting existing ASCII names? With a prefix as most ACE proposed, I say it is a "small risk". > If it's possible to do this, go ahead! In the meantime, I'm going to > focus on the proposals that have actually been worked out. A lot of proposals have been proven to work to certain extend under certain constraint. This includes ACE and UTF-8 and other even more horrible ones like legacy encodings which is better not discussed etc. I have done all of them and I still there is a better solution out there (e.g. John Klesin's I-D). So the issue here is not "which works?", but "which works best?" and "what constraint?". > > if "10-byte limit" is your concern. > > There's nothing special about 10. My examples show that every extra byte > poses a risk; we don't have the 63-byte safe harbor that some people > have imagined. A user's 5-byte or 10-byte or 15-byte domain name can > indirectly trip his software's 64-byte local-part length limit. You are missing the point. See my first sentence. -James Seng From owner-idn@ops.ietf.org Fri Jan 12 13: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 NAA14738 for ; Fri, 12 Jan 2001 13:36:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H8i6-0005W9-00 for idn-data@psg.com; Fri, 12 Jan 2001 10:13:58 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14H8i5-0005W3-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 10:13:57 -0800 Received: (qmail 24315 invoked by uid 1001); 12 Jan 2001 18:13:06 -0000 Date: 12 Jan 2001 18:13:06 -0000 Message-ID: <20010112181306.4673.qmail@cr.yp.to> Mail-Followup-To: eric@sendmail.org, idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: eric@sendmail.org Subject: [idn] Planning ahead for good IDNs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk There seems to be widespread agreement, even among ACE proponents, that we will _eventually_ move to UTF-8 domain names. This means that some programs will have to be upgraded. Obviously we should be warning people _now_. Let's publish an RFC pointing out that these programs will have to be fixed. We can also prevent any long-term length problems by recommending that programs allow 255-byte local parts and 255-byte domain names. ---Dan P.S. I'm not trying to suggest ACE-now-UTF-8-later as an IDN compromise. A direct move to UTF-8, with nameprep isolated in the user interface as I described, will give us a smoothly functioning IDN system within a few years. ACE will cost much more, because many more programs will have to be replaced; even after the subsequent move to UTF-8, it will take years to eradicate all the annoying ACE displays. From owner-idn@ops.ietf.org Fri Jan 12 15:38:42 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21270 for ; Fri, 12 Jan 2001 15:38:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HAJe-0009Ef-00 for idn-data@psg.com; Fri, 12 Jan 2001 11:56:50 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14HAJd-0009Dm-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 11:56:49 -0800 Received: from admin1.corp.walid.com (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with ESMTP id TAA24649; Fri, 12 Jan 2001 19:52:10 GMT Date: Fri, 12 Jan 2001 19:52:10 +0000 (GMT) From: "Brian W. Spolarich" X-Sender: briansp@admin1.corp.walid.com To: "D. J. Bernstein" cc: idn@ops.ietf.org, eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs In-Reply-To: <20010112181306.4673.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 12 Jan 2001, D. J. Bernstein wrote: | There seems to be widespread agreement, even among ACE proponents, | that we will _eventually_ move to UTF-8 domain names. There is? I can't say I myself detect a rough consensus based on the recent conversation in the WG, or in private conversation. There still seem to be at least three credible camps: ACE only, ACE transition, and UTF-8 only. -bws From owner-idn@ops.ietf.org Fri Jan 12 15:56:58 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23863 for ; Fri, 12 Jan 2001 15:56:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HAwx-000App-00 for idn-data@psg.com; Fri, 12 Jan 2001 12:37:27 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14HAww-000ApY-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 12:37:26 -0800 Received: from admin1.corp.walid.com (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with ESMTP id UAA25566; Fri, 12 Jan 2001 20:33:46 GMT Date: Fri, 12 Jan 2001 20:33:46 +0000 (GMT) From: "Brian W. Spolarich" X-Sender: briansp@admin1.corp.walid.com To: Marc Blanchet cc: idn@ops.ietf.org Subject: Re: [idn] Planning ahead for good IDNs In-Reply-To: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, 12 Jan 2001, Marc Blanchet wrote: | and the more "exotic" ( a friendly joke targetted to John K.): | directory, new class, etc... which, because of their property can use | or not encodings at all, more work to be done on that side tho. My working model has been that the IDN WG is going to come up with something to address current i18n needs, and that the 'exotic' stuff will be punted to a new WG. Am I close? :-) -bws From owner-idn@ops.ietf.org Fri Jan 12 15:59:09 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23898 for ; Fri, 12 Jan 2001 15:59:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HAs6-000Afs-00 for idn-data@psg.com; Fri, 12 Jan 2001 12:32:26 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14HAs5-000Afl-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 12:32:25 -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 f0CKdxd47966; Fri, 12 Jan 2001 15:39:59 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 12 Jan 2001 15:11:54 -0500 To: "Brian W. Spolarich" From: Marc Blanchet Subject: Re: [idn] Planning ahead for good IDNs Cc: idn@ops.ietf.org In-Reply-To: References: <20010112181306.4673.qmail@cr.yp.to> 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/À 19:52 2001-01-12 +0000, Brian W. Spolarich you wrote/vous écriviez: >On 12 Jan 2001, D. J. Bernstein wrote: > >| There seems to be widespread agreement, even among ACE proponents, >| that we will _eventually_ move to UTF-8 domain names. > > There is? I can't say I myself detect a rough consensus based on the >recent conversation in the WG, or in private conversation. There still >seem to be at least three credible camps: ACE only, ACE transition, and >UTF-8 only. and the more "exotic" ( a friendly joke targetted to John K.): directory, new class, etc... which, because of their property can use or not encodings at all, more work to be done on that side tho. ;-))) Marc. > -bws Marc Blanchet Viagénie 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 Fri Jan 12 18:39:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26936 for ; Fri, 12 Jan 2001 18:39:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HDQX-000HbF-00 for idn-data@psg.com; Fri, 12 Jan 2001 15:16: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 14HDQW-000Hai-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 15:16:08 -0800 Received: from P2 ("port 1220"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G7200CDHOMUIT@a4.jck.com> for idn@ops.ietf.org; Fri, 12 Jan 2001 18:16:07 -0500 (EST) Date: Fri, 12 Jan 2001 18:16:05 -0500 From: John C Klensin Subject: Re: [idn] Planning ahead for good IDNs In-reply-to: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> To: Marc Blanchet , "Brian W. Spolarich" Cc: idn@ops.ietf.org Message-id: <70821872.979323365@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 SAA26936 --On Friday, 12 January, 2001 15:11 -0500 Marc Blanchet wrote: > At/À 19:52 2001-01-12 +0000, Brian W. Spolarich you wrote/vous > écriviez: >> On 12 Jan 2001, D. J. Bernstein wrote: >> >> | There seems to be widespread agreement, even among ACE >> proponents, | that we will _eventually_ move to UTF-8 domain >> names. >> >> There is? I can't say I myself detect a rough consensus >> based on the recent conversation in the WG, or in private >> conversation. There still seem to be at least three credible >> camps: ACE only, ACE transition, and UTF-8 only. > > and the more "exotic" ( a friendly joke targetted to John K.): > directory, new class, etc... which, because of their property > can use or not encodings at all, more work to be done on that > side tho. I would add to Marc's list an observation made on this list several times before (but apparently as frequently forgotten). Since it was first introduced, there has been feeling in some parts of the community that UTF-8 is discriminatory toward, or relatively disadvantageous to, languages in the "upper" part of the UCS-2 (and beyond) code point sets. Whether or not that is true depends on the metrics used. However, for those who are concerned about that issue, and dislike UTF-8 as a consequence, most or all of the ACE schemes (and other schemes, including UCS-4 itself, that produce codes that are length-independent of code points) are going to be more acceptable. Consequently, claims about "widespread" belief that UTF-8 is the correct long-term solution require at least some qualification. I think we have drawn closer together, but, at one time, the level of enthusiasm for UTF-8 in the non-ASCII community could be predicted by taking the inverse of the numerical position of the last character in the script used by that community in the Unicode/10646 code tables. john From owner-idn@ops.ietf.org Fri Jan 12 18:52:38 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27011 for ; Fri, 12 Jan 2001 18:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HDo7-000IbH-00 for idn-data@psg.com; Fri, 12 Jan 2001 15:40:31 -0800 Received: from armada.ndl.net.nu ([208.36.200.16] helo=BILL) by psg.com with esmtp (Exim 3.16 #1) id 14HDo6-000Ib9-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 15:40:30 -0800 Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Fri, 12 Jan 2001 18:40:19 -0500 Message-Id: <3.0.5.32.20010112184019.03e7b950@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Jan 2001 18:40:19 -0500 To: idn@ops.ietf.org From: "J. William Semich" Subject: [idn] RFC2026 - Section 10 Statement In-Reply-To: <70821872.979323365@P2> References: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk Please see: http://www.ietf.org/ietf/IPR/NU-MLDNS ".NU Domain's Statement pertaining to MLDNS(tm) multilingual DNS" The following was received January 10, 2001 From: "J. William Semich" In accordance with section 10 of RFC 2026, and although it has yet to submit a contribution to the Internet Standards Process, .NU Domain hereby states that it has filed for patent protection in connection with the MLDNS(tm) multilingual DNS technology described at: http://www.worldnames.net/mldns/ J. William Semich .NU Domain 266 Main St., Suite 31 Medfield, MA 02052 From owner-idn@ops.ietf.org Fri Jan 12 20:04:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27454 for ; Fri, 12 Jan 2001 20:04:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HEjO-000Kj2-00 for idn-data@psg.com; Fri, 12 Jan 2001 16:39:42 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14HEjN-000Kis-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 16:39:41 -0800 Received: (qmail 19163 invoked by uid 1001); 13 Jan 2001 00:38:53 -0000 Date: 13 Jan 2001 00:38:53 -0000 Message-ID: <20010113003853.20562.qmail@cr.yp.to> Mail-Followup-To: eric@sendmail.org, idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs References: <20010112181306.4673.qmail@cr.yp.to> <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <20010112181306.4673.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk > | There seems to be widespread agreement, even among ACE proponents, > | that we will _eventually_ move to UTF-8 domain names. > There is? Apparently so. I see a few people saying that big-endian UCS-4 would be better, but none of them claim that Internet protocols are actually going to move in that direction. > There still seem to be at least three credible camps: ACE only, ACE > transition, and UTF-8 only. I don't see any serious support for the ACE-now-and-forever position. The rest of us, the UTF-8 people and the ACE-now-UTF-8-later people, all agree that some programs are going to have to be fixed. Sendmail's address handling should be made 8-bit-clean, for example, and cc:Mail should allow 255-byte local parts and 255-byte domain names. The IDN WG can and should issue an immediate warning for implementors. ---Dan From owner-idn@ops.ietf.org Fri Jan 12 20: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 UAA27479 for ; Fri, 12 Jan 2001 20:06:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HEx8-000LMU-00 for idn-data@psg.com; Fri, 12 Jan 2001 16:53:54 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14HEx7-000LMO-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 16:53:53 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02442; Fri, 12 Jan 2001 16:48:35 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3.0.5.32.20010112184019.03e7b950@mail.nic.nu> References: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <3.0.5.32.20010112184019.03e7b950@mail.nic.nu> Date: Fri, 12 Jan 2001 16:52:28 -0800 To: "J. William Semich" , idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] RFC2026 - Section 10 Statement Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Since much of what you describe on that page is unpatentable (given that it embodies things that were published as Internet Drafts), could you be more specific about what your patent application covers? Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Jan 12 20:18:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27564 for ; Fri, 12 Jan 2001 20:18:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HF93-000LqS-00 for idn-data@psg.com; Fri, 12 Jan 2001 17:06:13 -0800 Received: from nfs1.jvnc.net ([130.94.1.1] ident=nobody) by psg.com with esmtp (Exim 3.16 #1) id 14HF92-000LqL-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 17:06:12 -0800 Received: from verio.net ([198.138.183.18]) by nfs1.jvnc.net (8.9.3/8.9.3) with ESMTP id UAA06210; Fri, 12 Jan 2001 20:06:09 -0500 (EST) Message-ID: <3A5FAA31.D5845350@verio.net> Date: Fri, 12 Jan 2001 20:06:57 -0500 From: Jorge Amodio Organization: VERIO, Inc. X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "J. William Semich" CC: idn@ops.ietf.org Subject: Re: [idn] RFC2026 - Section 10 Statement References: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <3.0.5.32.20010112184019.03e7b950@mail.nic.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > http://www.worldnames.net/mldns/ returns: Error Occurred While Processing Request Jorge. From owner-idn@ops.ietf.org Fri Jan 12 21:26:58 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28172 for ; Fri, 12 Jan 2001 21:26:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HG6N-000O33-00 for idn-data@psg.com; Fri, 12 Jan 2001 18:07:31 -0800 From: Randy Bush Subject: [idn] Reminder - use correct "From:". Date: Fri, 12 Jan 2001 06:56:22 -0800 Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: To: idn-data@psg.com [[[James Seng: The only diff is this list bounce to me and I have to forward the list manually (like this one) :PPPPP]]] please remember to use the correct "From:" addres when you send messages to this list. 'correct' means that the address in your "From:" mail header field should be the same as the address with which you sub scribed to the list. failing to use the correct address will bounce your message to the list admin (me) for manual approval. this can lead to significant delay, and you turn your trust to _my_ memory to remember to forward the message to the list - which is something I would be very careful with myself ... ;-) randy From owner-idn@ops.ietf.org Fri Jan 12 21: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 VAA29183 for ; Fri, 12 Jan 2001 21:37:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HGPL-000Opc-00 for idn-data@psg.com; Fri, 12 Jan 2001 18:27:07 -0800 To: idn@ops.ietf.org From: "David R. Conrad" Subject: [idn] who uses BIND as a base for their internationalized DNS package? Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 12 Jan 2001 18:27:07 -0800 I know the following do: i-DNS Worldnames Who else? Tnx, -drc From owner-idn@ops.ietf.org Fri Jan 12 21:58:41 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29476 for ; Fri, 12 Jan 2001 21:58:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HGkU-000Pib-00 for idn-data@psg.com; Fri, 12 Jan 2001 18:48:58 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14HGkT-000PiU-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 18:48:57 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 10FE2FFC03; Sat, 13 Jan 2001 10:48:55 +0800 (SGT) Message-ID: <043001c07d0b$290d8cc0$8e00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "J. William Semich" , , "Paul Hoffman / IMC" References: <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <3.0.5.32.20010112184019.03e7b950@mail.nic.nu> Subject: Re: [idn] RFC2026 - Section 10 Statement Date: Sat, 13 Jan 2001 10:47: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 I realised that even tho there are "unpatentable" stuff (like published I-D, open ideas on mailing list etc), it does not prevent some from trying to file a patent for it in the hope that a) a slim chance the patent examiners let it thru b) a patent-pending is useful for business reasons in fact, it makes sense just to keep it at this 'patent-pending' stage as long as possible especially if it is really "unpatentable". I have been asked to review at least 4 patent filed on the topic of IDN and most, if not all are almost unpatentable IMHO. ps: No, I am not commenting on Worldnames' here because I have yet to see it. -James Seng ----- Original Message ----- From: "Paul Hoffman / IMC" To: "J. William Semich" ; Sent: Saturday, January 13, 2001 8:52 AM Subject: Re: [idn] RFC2026 - Section 10 Statement > Since much of what you describe on that page is unpatentable (given > that it embodies things that were published as Internet Drafts), > could you be more specific about what your patent application covers? > Thanks! > > --Paul Hoffman, Director > --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Jan 12 22:07:23 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29654 for ; Fri, 12 Jan 2001 22:07:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HGtx-00009c-00 for idn-data@psg.com; Fri, 12 Jan 2001 18:58:45 -0800 Received: from glucose.pas.idealab.com ([64.208.8.249] helo=idealab.com) by psg.com with smtp (Exim 3.16 #1) id 14HGtx-00009U-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 18:58:45 -0800 Received: (qmail 13115 invoked by uid 526); 13 Jan 2001 02:58:44 -0000 To: idn@ops.ietf.org Subject: Re: [idn] Planning ahead for good IDNs References: <20010112181306.4673.qmail@cr.yp.to> <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <20010112181306.4673.qmail@cr.yp.to> <20010113003853.20562.qmail@cr.yp.to> From: Marc Tamsky Date: 12 Jan 2001 18:58:44 -0800 In-Reply-To: "D. J. Bernstein"'s message of "13 Jan 2001 00:38:53 -0000" Message-ID: Lines: 46 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-idn@ops.ietf.org Precedence: bulk >>>>> On 13 Jan 2001 00:38:53 -0000, "D. J. Bernstein" said: >> There still seem to be at least three credible camps: ACE only, ACE >> transition, and UTF-8 only. > I don't see any serious support for the ACE-now-and-forever position. Agreed. As a final product, it would be the ugliest hack next to IMAP to come out of the IETF lately. > The rest of us, the UTF-8 people and the ACE-now-UTF-8-later people, all > agree that some programs are going to have to be fixed. Sendmail's > address handling should be made 8-bit-clean, for example, and cc:Mail > should allow 255-byte local parts and 255-byte domain names. > The IDN WG can and should issue an immediate warning for implementors. Agreed. From RFC-2277: But it is the responsibility of the WGs to ensure that whenever responsibility for internationalization is left to "another layer", those responsible for that layer are in fact aware that they HAVE that responsibility. I think this applies to the local parts issue that was recently brushed off as "another layer problem" -- those responsible for local parts need notice as well. In no way should readers of either warning be led to believe that by implementing the necessary changes to support ACE, that they are done upgrading their programs to support internationalized DNS. Without a clear set of transition elements, guidelines for implementation, and test suites, ACE-now-UTF-8-later will create a credible demand for UTF-8 in other systems. All those who face changes to their systems, also face the questions: "Do I update my programs twice to work with ACE-now-UTF-8-later, or just do the work once for UTF-8?" -- Marc Tamsky From owner-idn@ops.ietf.org Sat Jan 13 00:21:17 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01994 for ; Sat, 13 Jan 2001 00:21:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HInS-00058D-00 for idn-data@psg.com; Fri, 12 Jan 2001 21:00:10 -0800 Received: from h00508b5474ca.ne.mediaone.net ([24.91.78.68] helo=BILL) by psg.com with esmtp (Exim 3.16 #1) id 14HInR-00057t-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 21:00:10 -0800 Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Fri, 12 Jan 2001 23:59:58 -0500 Message-Id: <3.0.5.32.20010112235957.03df9c30@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Jan 2001 23:59:57 -0500 To: idn@ops.ietf.org, Marc Tamsky From: "J. William Semich" Subject: Re: [idn] Planning ahead for good IDNs In-Reply-To: References: <"D. J. Bernstein"'s message of "13 Jan 2001 00:38:53 -0000"> <20010112181306.4673.qmail@cr.yp.to> <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <5.0.2.1.1.20010112150953.03e0dfd0@mail.viagenie.qc.ca> <20010112181306.4673.qmail@cr.yp.to> <20010113003853.20562.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idn@ops.ietf.org Precedence: bulk Interesting observations. Worldnames/NU domain faced the same question - should we plan to upgrade twice? We decided it didn't make sense. Instead, we decided to base the whole .NU ML system in UTF-8, but provide for transparent ACE support/compatibility. Kind of like "HDTV-ready." Others might consider the same, or perhaps are already doing so. Bill Semich At 06:58 PM 1/12/01 -0800, you wrote: > >In no way should readers of either warning be led to believe that by >implementing the necessary changes to support ACE, that they are done >upgrading their programs to support internationalized DNS. > >Without a clear set of transition elements, guidelines for >implementation, and test suites, ACE-now-UTF-8-later will create a >credible demand for UTF-8 in other systems. > >All those who face changes to their systems, also face the questions: >"Do I update my programs twice to work with ACE-now-UTF-8-later, or >just do the work once for UTF-8?" > >-- >Marc Tamsky > > Bill Semich President and Founder WorldNames, Inc. http://www.worldnames.net bsemich@worldnames.net From owner-idn@ops.ietf.org Sat Jan 13 02:03:25 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13220 for ; Sat, 13 Jan 2001 02:03:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HKUk-0009X9-00 for idn-data@psg.com; Fri, 12 Jan 2001 22:48:58 -0800 Received: from epa.secret.org ([206.220.140.150] ident=0) by psg.com with esmtp (Exim 3.16 #1) id 14HKUj-0009W0-00 for idn@ops.ietf.org; Fri, 12 Jan 2001 22:48:57 -0800 Received: from localhost (lucid@localhost) by epa.secret.org (8.9.3/8.9.1) with ESMTP id BAA33732; Sat, 13 Jan 2001 01:48:47 -0500 (EST) Date: Sat, 13 Jan 2001 01:48:47 -0500 (EST) From: William Morris X-Sender: lucid@epa.secret.org To: "D. J. Bernstein" cc: idn@ops.ietf.org, eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs In-Reply-To: <20010113003853.20562.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 13 Jan 2001, D. J. Bernstein wrote: > The IDN WG can and should issue an immediate warning for implementors. A warning along the lines of RFC2277 aka BCP18 would be good, perhaps a bit more strongly worded. -Bill From owner-idn@ops.ietf.org Sat Jan 13 09:32:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17695 for ; Sat, 13 Jan 2001 09:32:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HRMV-0000kr-00 for idn-data@psg.com; Sat, 13 Jan 2001 06:08:55 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14HRMU-0000jv-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 06:08:54 -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 f0DE8ll29533 for ; Sat, 13 Jan 2001 15:08:47 +0100 (MET) Message-Id: <200101131408.f0DE8ll29533@malmo.trab.se> Date: Sat, 13 Jan 2001 15:07:59 +0100 (MET) From: Dan Reply-To: Dan Subject: [idn] Some comments To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4BgDL0KfcHnyu+EkgL7jdg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Having no time to daily comment on the flow of comments on the list I here give some comments on things I have read this week: - There was some comments on 8-bit text i Subject and how it quite often was mangled beyond recognition. This does show some of the problems that an ACE can result in. To get non-ASCII into the Subject-line you today need a quite complex handling where some parts are encoded and some are not, length constraints on the encoded form and a mixture of character sets. It is even worse with the From:-line. Here only some parts may be encoded. I have written software to handle the MIME-encoding of header lines. If all header lines had been in UTF-8 (or UCS-2) it would have been much, much simpler and much less error prone. - There have been several references to a "Latin alphabet". As there are many alphabets that can be called a "Latin alphabet" (for example the classical Latin alphabet (no G,J or W), the English alphabet or the Swedish alphabet). While I can guess it is mostly a reference to the 26 letters of the English alphabet, the English alphabet is not the only Latin alphabet. Please be more clear. - There have been talk about URIs and how they will use non-ASCII and if Unix users are willing to edit ACE or use a new tool. As a person needing more than ASCII (currently using ISO 8859-1) typing in URLs using %-escapes or editing domain names in ACE is unacceptable. If I edit domain names in a zone file to be loaded by my DNS server, I will edit them using my local character set. I will expect my DNS server to convert them into whatever format is used in the DNS protocol. If I can get an editor which can support ISO 8859-1 and UTF-8 is a friendly way, I might accept to edit my zone files using UTF-8. And when I enter URLs I enter them using ISO 8859-1. I am not going to %-encode them. And I cannot really see any reason to have them %-encoded when being transmitted using HTTP. HTTP is fully capable to send 8-bit characters. It is OK for them to be converted into UTF-8 for transmission, but any displyed to me must not be in UTF-8 or %-encoding, if the letters can be displyed using my local character set. In short: during user interaction all data should use the local character set. As a local character set cannot always display all characters in a text, there should be ONE standard way to encode and display the characters not supported by the local character set. I do not want many like today with: %-encoding, ACE, quoted-printable or base64. For every new encodning for it gets more and more complex to handle text. Just look at an URL: Is the host part in ACE-encoding or %-encoding? Or UTF-8? If a URL is embedded in text, what format is it in then? The same character set as the text? Or is it in ACE? How is the tool that is displaying the text to know that an URL is embedded and decode just that part so that also the URL can be displayed in a user friendly manner? Dan From owner-idn@ops.ietf.org Sat Jan 13 12:07:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18781 for ; Sat, 13 Jan 2001 12:07:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HTo0-0006tQ-00 for idn-data@psg.com; Sat, 13 Jan 2001 08:45:28 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14HTnz-0006tJ-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 08:45:27 -0800 Message-ID: <001e01c07d80$ed66d840$1001a8c0@neteka.com> From: "Edmon" To: , "David R. Conrad" References: Subject: Re: [idn] who uses BIND as a base for their internationalized DNS package? Date: Sat, 13 Jan 2001 11:50:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 David, If you go to www.OpenIDN.org, you will see that the Neteka NeDNS version on the site is also BIND based, though we also have other versions that are not. ;-) Edmon ----- Original Message ----- From: "David R. Conrad" To: Sent: Friday, January 12, 2001 9:27 PM Subject: [idn] who uses BIND as a base for their internationalized DNS package? > I know the following do: > > i-DNS > Worldnames > > Who else? > > Tnx, > -drc > > > From owner-idn@ops.ietf.org Sat Jan 13 12:34:33 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19019 for ; Sat, 13 Jan 2001 12:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HUOT-0002uy-00 for idn-data@psg.com; Sat, 13 Jan 2001 09:23:09 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14HUOS-0002uW-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 09:23:08 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA22850; Sat, 13 Jan 2001 12:23:06 -0500 (EST) Message-Id: <200101131723.MAA22850@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org, eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs In-reply-to: Your message of "12 Jan 2001 18:13:06 GMT." <20010112181306.4673.qmail@cr.yp.to> Date: Sat, 13 Jan 2001 12:23:06 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > There seems to be widespread agreement, even among ACE proponents, that > we will _eventually_ move to UTF-8 domain names. This is complete fantasy on your part. From owner-idn@ops.ietf.org Sat Jan 13 12:38:22 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19044 for ; Sat, 13 Jan 2001 12:38:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HUO9-0002pf-00 for idn-data@psg.com; Sat, 13 Jan 2001 09:22:49 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14HUO8-0002p9-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 09:22:48 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA22833; Sat, 13 Jan 2001 12:22:44 -0500 (EST) Message-Id: <200101131722.MAA22833@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org, eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs In-reply-to: Your message of "13 Jan 2001 00:38:53 GMT." <20010113003853.20562.qmail@cr.yp.to> Date: Sat, 13 Jan 2001 12:22:44 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I don't see any serious support for the ACE-now-and-forever position. that's because you see what you want to see, not because you have a realistic assessment of people's positions. the way in which IDNs are used in the context of applications that currently support only ASCII DNS names, is not for this group to decide. some protocols might want to move to UTF-8, others not. Keith From owner-idn@ops.ietf.org Sat Jan 13 13:51:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19386 for ; Sat, 13 Jan 2001 13:51:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HVS8-000Ku0-00 for idn-data@psg.com; Sat, 13 Jan 2001 10:31:00 -0800 Received: from c193.150.248.34.cm-upc.chello.se ([193.150.248.34] helo=ledig.paf.se) by psg.com with esmtp (Exim 3.16 #1) id 14HVS6-000Ktt-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 10:30:59 -0800 Received: from [10.0.1.9] (802-11.paf.se [192.168.1.4]) by ledig.paf.se (8.9.3/8.9.3) with ESMTP id TAA59715; Sat, 13 Jan 2001 19:29:38 +0100 (CET) (envelope-from paf@cisco.com) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200101131408.f0DE8ll29533@malmo.trab.se> References: <200101131408.f0DE8ll29533@malmo.trab.se> Date: Sat, 13 Jan 2001 19:20:34 +0100 To: Dan , idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Some comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 15.07 +0100 01-01-13, Dan wrote: >- There was some comments on 8-bit text i Subject and how it quite >often was mangled beyond recognition. >This does show some of the problems that an ACE can result in. The errors for 8bit in email can be classified in three groups: - Information loss - Charset weirdness - Ascii encoding is not decoded The main problem is the information loss or charset weirdness (unknown charset for 8bit data) that happens when people send mail wrongly tagged/encoded. This is the major problem just because the receiver can not know reconstruct the mangled data regardless of what his software is doing. Non-decoded data is not as problematic, because then information has not been lost during encoding and transport. An ACE encoding is in the category of "non-decoded" data, and not "information loss", while UTF-8 on the wire is in the category of information loss -- if it is mangled. >To get non-ASCII into the Subject-line you today need a quite >complex handling where some parts are encoded and some are not, >length constraints on the encoded form and a mixture of character sets. There are length constraints on what you send over the wire. What I see above is a layering violation. You have to keep things apart, and remember that with the introduction of MIME, SMTP is used as a transport mechanism, and whatever you want to send with the help of SMTP have to be encoded correctly. >It is even worse with the From:-line. Here only some parts may be >encoded. I have written software to handle the MIME-encoding of header >lines. If all header lines had been in UTF-8 (or UCS-2) it would have been >much, much simpler and much less error prone. It all depends on what you mean by "simpler". Of course an n:m mapping is harder than n:1 mapping (i.e. if every email had to be in Unicode, people only had to know how to map between the local characters and Unicode). That is a different thing though than the question whether ACE or UTF-8 should be used. Keep the layers separated please! >- There have been talk about URIs and how they will use non-ASCII and >if Unix users are willing to edit ACE or use a new tool. >As a person needing more than ASCII (currently using ISO 8859-1) typing >in URLs using %-escapes or editing domain names in ACE is unacceptable. >If I edit domain names in a zone file to be loaded by my DNS server, >I will edit them using my local character set. I will expect my DNS server >to convert them into whatever format is used in the DNS protocol. >If I can get an editor which can support ISO 8859-1 and UTF-8 is a >friendly way, I might accept to edit my zone files using UTF-8. >And when I enter URLs I enter them using ISO 8859-1. I am not going to >%-encode them. And I cannot really see any reason to have them >%-encoded when being transmitted using HTTP. HTTP is fully capable to >send 8-bit characters. It is OK for them to be converted into UTF-8 for >transmission, but any displyed to me must not be in UTF-8 or %-encoding, >if the letters can be displyed using my local character set. Just too many things are mixed up here to have this paragraph make sense: - You edit the zone file using your local charset - The content of the zonefile have to be converted to Unicode - The content of the zonefile have to be nameprepped - The content of the zonefile have to be encoded - You enter URL's in your local charset in your browser - The browser convert into Unicode - The browser do nameprep - The nameprepped data might be %-encoded for HTTP - The domain part have to be encoded Note that only where we have "have to be encoded" above, we have the problem of UTF-8 versus ACE. Now, you Dan, also think that nameprep/equivalence can be done in the DNS server, so the DNS query packets can include whatever octets one want. My position is that that is just out of scope, and just not acceptable solution as the domainname have to be "reused" in the actual protocol aswell, in the example above HTTP. So, NOT doing the full nameprep/encoding in the client is just wrong, and a mistake architecturally. Also, for the n:time, for UTF-8 to work we need to change a large number of protocols, intermediaries/middleware boxes, firewalls etc because the change to the protocols is quite large. Not as bad as a change to USC-2 or some other "more" binary encoding, but still a large change. With an ACE encoding, we don't have to change the protocols at all. Do people understand this? Also, I saw someone saying "the rest of us like UTF-8" (or something like that). I would say that there is definitly not consensus for use of UTF-8 instead of an ACE. The contrary. >In short: during user interaction all data should use the local character set. Yes. >As a local character set cannot always display all characters in a text, >there should be ONE standard way to encode and display the characters not >supported by the local character set. I do not want many like today >with: %-encoding, ACE, quoted-printable or base64. >For every new encodning for it gets more and more complex to handle text. >Just look at an URL: Is the host part in ACE-encoding or %-encoding? >Or UTF-8? If a URL is embedded in text, what format is it in then? >The same character set as the text? Or is it in ACE? How is the tool >that is displaying the text to know that an URL is embedded and >decode just that part so that also the URL can be displayed >in a user friendly manner? All good questions, and information on why the IDN problem is not only a problem with DNS, but also a problem with the various applications which uses domains. paf From owner-idn@ops.ietf.org Sat Jan 13 15:04:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19898 for ; Sat, 13 Jan 2001 15:04:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HWbO-0000Tw-00 for idn-data@psg.com; Sat, 13 Jan 2001 11:44:38 -0800 Received: from ibd.ar.com ([63.194.205.75]) by psg.com with esmtp (Exim 3.16 #1) id 14HWbN-0000Tq-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 11:44:37 -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 LAA03474; Sat, 13 Jan 2001 11:44:09 -0800 (PST) Date: Sat, 13 Jan 2001 11:42:39 -0800 (PST) From: Rick H Wesson To: Edmon cc: , "David R. Conrad" Subject: Re: [idn] who uses BIND as a base for their internationalized DNS package? In-Reply-To: <001e01c07d80$ed66d840$1001a8c0@neteka.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon, Why does your OPENidn stuff require a password, seems oxymornic for authenticated access for something billed as "open." If you truly want to bill this stuff as open source then you shouldn't require a registration, unless you are searching for a business model... -rick On Sat, 13 Jan 2001, Edmon wrote: > Hi David, > > If you go to www.OpenIDN.org, you will see that the Neteka NeDNS version on > the site is also BIND based, though we also have other versions that are > not. ;-) > > Edmon > > > ----- Original Message ----- > From: "David R. Conrad" > To: > Sent: Friday, January 12, 2001 9:27 PM > Subject: [idn] who uses BIND as a base for their internationalized DNS > package? > > > > I know the following do: > > > > i-DNS > > Worldnames > > > > Who else? > > > > Tnx, > > -drc > > > > > > > > From owner-idn@ops.ietf.org Sat Jan 13 16:15:40 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20170 for ; Sat, 13 Jan 2001 16:15:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HXnx-0003is-00 for idn-data@psg.com; Sat, 13 Jan 2001 13:01:41 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14HXnv-0003iT-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 13:01:39 -0800 Received: (qmail 9531 invoked by uid 1001); 13 Jan 2001 21:00:48 -0000 Date: 13 Jan 2001 21:00:48 -0000 Message-ID: <20010113210048.9685.qmail@cr.yp.to> Mail-Followup-To: eric@sendmail.org, idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Cc: eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs References: <20010113003853.20562.qmail@cr.yp.to> <200101131722.MAA22833@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk As I said, I don't see any serious support for the ACE-now-and-forever position. Keith Moore writes: > that's because you see what you want to see, not because you have > a realistic assessment of people's positions. Let me see if I have this straight. You support ACE-now-and-forever? You don't think Sendmail will ever have to be made 8-bit-clean? You object to the IDN WG publishing a warning for implementors? And you think your position is widely shared? Or do you not, in fact, support ACE-now-and-forever, but you think that there's serious support for it anyway? Who else has expressed support? > the way in which IDNs are used in the context of applications that > currently support only ASCII DNS names, is not for this group to > decide. some protocols might want to move to UTF-8, others not. I disagree. The IDN WG is a complete waste of time if it can't look beyond the DNS protocol. ---Dan From owner-idn@ops.ietf.org Sat Jan 13 16:54:40 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20384 for ; Sat, 13 Jan 2001 16:54:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HYNN-0005NE-00 for idn-data@psg.com; Sat, 13 Jan 2001 13:38:17 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14HYNM-0005N7-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 13:38:16 -0800 Received: (qmail 14612 invoked by uid 1001); 13 Jan 2001 21:37:27 -0000 Date: 13 Jan 2001 21:37:27 -0000 Message-ID: <20010113213727.27292.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Some comments References: <200101131408.f0DE8ll29533@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk Patrik writes: > Also, I saw someone saying "the rest of us like UTF-8" (or something > like that). I would say that there is definitly not consensus for use > of UTF-8 instead of an ACE. The contrary. What I actually said was ``The rest of us, the UTF-8 people and the ACE-now-UTF-8-later people, all agree that some programs are going to have to be fixed.'' What's your position, Patrik? Do you want to look around in a future UTF-8 world and see that the Internet is using some clumsy ACE? Do you think that Sendmail will never have to be fixed? Do you object to the IDN WG warning implementors that programs should be 8-bit-clean? > Non-decoded data is not as problematic, because then information has > not been lost during encoding and transport. That's what Keith said for years about Quoted-Printable. He ignored the screams of the users who, in fact, DID NOT HAVE THE INFORMATION. (Keith's favorite airline: ``Yes, sir, we know we shredded your luggage, but it's all here! Take some time and sew it back together. By the way, we don't shred English luggage.'') The goal is not merely to ensure that, in theory, all the information has been preserved. The goal is to actually _provide_ the information to the user. > Also, for the n:time, for UTF-8 to work we need to change a large > number of protocols, intermediaries/middleware boxes, firewalls etc > because the change to the protocols is quite large. What matters is the software. The protocols can change for free if the software already supports the new protocols. UTF-8, with nameprep handled close to the user as I described, works with many existing 8-bit-clean pieces of software. ACE-now-and-forever and ACE-now-UTF-8-later would impose much larger software upgrade costs. ---Dan From owner-idn@ops.ietf.org Sat Jan 13 17:33:00 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20545 for ; Sat, 13 Jan 2001 17:32:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HZ22-00079y-00 for idn-data@psg.com; Sat, 13 Jan 2001 14:20:18 -0800 Received: from c193.150.248.34.cm-upc.chello.se ([193.150.248.34] helo=ledig.paf.se) by psg.com with esmtp (Exim 3.16 #1) id 14HZ20-00079s-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 14:20:17 -0800 Received: from [10.0.1.11] (802-11.paf.se [192.168.1.4]) by ledig.paf.se (8.9.3/8.9.3) with ESMTP id XAA66736 for ; Sat, 13 Jan 2001 23:20:14 +0100 (CET) (envelope-from paf@cisco.com) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010113213727.27292.qmail@cr.yp.to> References: <200101131408.f0DE8ll29533@malmo.trab.se> <20010113213727.27292.qmail@cr.yp.to> Date: Sat, 13 Jan 2001 23:19:58 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Some comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 21.37 +0000 01-01-13, D. J. Bernstein wrote: >What's your position, Patrik? Do you want to look around in a future >UTF-8 world and see that the Internet is using some clumsy ACE? Do you >think that Sendmail will never have to be fixed? Do you object to the >IDN WG warning implementors that programs should be 8-bit-clean? My position is that: - A solution to the IDN problem have to be solved _now_, and we don't have time to update all protocols to use anything else than US-ASCII before that point in time - This means that the immediate solution must be ACE based In the longer term if course a more efficient encoding of Unicode can be used, but that is much further ahead. I would say that the warning message should not be to be 8-bit-clean, but that protocols (and therefore applications) should be prepared that not only the version of Unicode will change, but also the prefered encoding mechanism. I don't want 8-bit clean protocols, and UTF-8. I want protocols which can handle UCS-2, UCS-4 or UTF-16 (or whatever non-encoded version of Unicode). Why have an encoding at all if we are taking the step of changing the protocols? What I don't like in your arguments is the focus on "applications" instead of looking at what is specified in the protocols. > > Non-decoded data is not as problematic, because then information has >> not been lost during encoding and transport. > >That's what Keith said for years about Quoted-Printable. He ignored the >screams of the users who, in fact, DID NOT HAVE THE INFORMATION. I don't understand what you say. Note that I had several different problems, and that the problem "non-decoded-data" was when the recipient did get all the information in the form of a charset argument to the text/plain content type, while the other problems where when you didn't have this information. My point was that when we have non-encoded data, the recipient could by changing the application see all the information without any loss, but he could not if there were some loss somewhere (8th bit removed or charset argument missing to 8bit clean data). What you seem to talk about was how bad it was when the user had an application which could not decode the quoted-printable given the encoding was correct and charset parameter was correct? If that is the case, then you don't understand what I talk about. >(Keith's favorite airline: ``Yes, sir, we know we shredded your luggage, >but it's all here! Take some time and sew it back together. By the way, >we don't shred English luggage.'') You talk about quoted-printable encoding and charset parameter as it was something which destroys the content as shredding of luggage would do. Sorry, that doesn't work. Shredding the luggage is when the user can not reassemble the luggage by using the correct tools. Such things like getting 8bit data without charset parameter, or getting 8bit data where the 8th bit is set to zero. >The goal is not merely to ensure that, in theory, all the information >has been preserved. The goal is to actually _provide_ the information to >the user. My argument was that IF the whole encoded message, as with quoted printable and a correct charset parameter is coming to the recipient of the email, then he can himself by changing application get the information without noticing that the data have been encoded at all. > > Also, for the n:time, for UTF-8 to work we need to change a large >> number of protocols, intermediaries/middleware boxes, firewalls etc >> because the change to the protocols is quite large. > >What matters is the software. The protocols can change for free if the >software already supports the new protocols. > >UTF-8, with nameprep handled close to the user as I described, works >with many existing 8-bit-clean pieces of software. ACE-now-and-forever >and ACE-now-UTF-8-later would impose much larger software upgrade costs. But, software doesn't handle 8 bit stuff correctly today even though we have in the IETF been talking about it for a very long time. Even worse, software doesn't handle the charset parameter correctly either (mapping between transport charset and local charset) even though MIME has now existed for quite some number of years. Software is not at all as good as you seem to belive. A couple of questions: - Do you use an operating system which doesn't use ISO 8859-1 as native charset for input and output? What charset? - What is the minimal set of characters you need in your native language, and what is that language? - What percent of email you receive and send each day is not english, i.e. need characters which doesn't exist in the A-Z set? Note that I am talking about your own personal experience and not what your customers/users of your software report. paf From owner-idn@ops.ietf.org Sat Jan 13 19:18:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21148 for ; Sat, 13 Jan 2001 19:18:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HaYN-000B7c-00 for idn-data@psg.com; Sat, 13 Jan 2001 15:57:47 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14HaYM-000B7U-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 15:57:46 -0800 Received: (qmail 5575 invoked by uid 1001); 13 Jan 2001 23:57:01 -0000 Date: 13 Jan 2001 23:57:01 -0000 Message-ID: <20010113235701.11623.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Some comments References: <200101131408.f0DE8ll29533@malmo.trab.se> <20010113213727.27292.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk Patrik writes: > I don't want 8-bit clean protocols, and UTF-8. I want protocols which > can handle UCS-2, UCS-4 or UTF-16 UTF-8 is compatible with ASCII. UCS-4 is not. Switching a protocol to UTF-8 preserves compatibility; ASCII data is unaffected. Switching a protocol to UCS-4 destroys compatibility; ASCII bytes turn into 4-byte sequences. Do you seriously believe that the Internet is going to move to UCS-4 rather than UTF-8? Exactly what benefits is anyone supposed to see in this? Occasionally I hear people claiming that a string of Unicode numbers is convenient because the displayed width of the string is proportional to the number of bytes; but they're wrong, thanks to combining characters and double-width characters. > What I don't like in your arguments is the focus on "applications" > instead of looking at what is specified in the protocols. What I don't like in your arguments is the focus on protocol specs as religious objects, rather than as tools to help implementors provide working software to system administrators and users. > You talk about quoted-printable encoding and charset parameter as it > was something which destroys the content as shredding of luggage > would do. ``The luggage isn't destroyed, sir. It's just shredded. As I said, you can take some time and sew it back together. You haven't lost anything; it's all here! By the way, would you like to buy a sewing machine?'' > But, software doesn't handle 8 bit stuff correctly today even though > we have in the IETF been talking about it for a very long time. The IETF should have required 8-bit-clean mail software in 1982. Allman would have fixed his software eventually, certainly before version 6.57 in 1993. UTF-8 header fields should have been allowed in 1996. Everyone would have been happily using UTF-8 mail in 2001. Instead, the IETF mail standards _still_ allow MTAs to drop 8-bit bytes, even in message bodies. See http://cr.yp.to/docs/8bit/06.txt. ---Dan From owner-idn@ops.ietf.org Sat Jan 13 19:21:28 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21181 for ; Sat, 13 Jan 2001 19:21:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HaZ6-000B9d-00 for idn-data@psg.com; Sat, 13 Jan 2001 15:58:32 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14HaZ5-000B7m-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 15:58: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 SAA26099; Sat, 13 Jan 2001 18:58:23 -0500 (EST) Message-Id: <200101132358.SAA26099@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: idn@ops.ietf.org, eric@sendmail.org Subject: Re: [idn] Planning ahead for good IDNs In-reply-to: Your message of "13 Jan 2001 21:00:48 GMT." <20010113210048.9685.qmail@cr.yp.to> Date: Sat, 13 Jan 2001 18:58:23 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > As I said, I don't see any serious support for the ACE-now-and-forever > position. That's because you are establishing a false dichotomy between "ACE now and forever" on one hand and "UTF-8 eventually" on the other. There's a lot of middle ground between those two, which I might characterize as "ACE in the near-term, and as for eventually, wait-and-see what makes sense" And "what makes sense" might be different from one protocol to another. Keith From owner-idn@ops.ietf.org Sat Jan 13 20:59:47 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21556 for ; Sat, 13 Jan 2001 20:59:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HcBG-000FCm-00 for idn-data@psg.com; Sat, 13 Jan 2001 17:42:02 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14HcBF-000FCf-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 17:42:01 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA26945; Sat, 13 Jan 2001 20:41:55 -0500 (EST) Message-Id: <200101140141.UAA26945@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] Some comments In-reply-to: Your message of "13 Jan 2001 23:57:01 GMT." <20010113235701.11623.qmail@cr.yp.to> Date: Sat, 13 Jan 2001 20:41:55 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > What I don't like in your arguments is the focus on protocol specs as > religious objects, rather than as tools to help implementors provide > working software to system administrators and users. and apparently your personal definition of "working" is one that requires nearly everyone on the network to upgrade their software (and perhaps even hardware), at your whim, and on your schedule - or risk breaking critical functionality not only for themselves but for others as well. it's a rather strange use of the word. Keith From owner-idn@ops.ietf.org Sun Jan 14 01:18:17 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26196 for ; Sun, 14 Jan 2001 01:18:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Hg6Z-000PPG-00 for idn-data@psg.com; Sat, 13 Jan 2001 21:53:27 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14Hg6W-000PPA-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 21:53:24 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id D9B08FFC01; Sun, 14 Jan 2001 13:53:20 +0800 (SGT) Message-ID: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> From: "James Seng/Personal" To: Cc: "Marc Blanchet" Subject: [idn] San Diego Meeting Notes Date: Sun, 14 Jan 2001 13:51:55 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0095_01C07E31.27BAE170" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C07E31.27BAE170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear all, Here is the minutes of the IDN WG Meeting at San Diego IETF. Thanks to David (again) scribing 43Kb of text notes :P Some important highlight: (feel free to object if you think I am wrong). 1. Requirements I-D is almost ready for last call with some minor changes. It is likely we will do one more version. Any last comments, please do so ASAP. 2. General feeling that Nameprep sub-team is working in the right direction. 3. Strawpoll agrees with the Protocol sub-team recommendation that we will focus on "ACE on Application" now but do not reject the possibiity to do something else longer term. What is the longer term solution is left for future discussion. -James Seng ------=_NextPart_000_0095_01C07E31.27BAE170 Content-Type: text/plain; name="San Diego Meeting.txt" Content-Disposition: attachment; filename="San Diego Meeting.txt" Content-Transfer-Encoding: quoted-printable IDN WG Meeting San Diego * Working group update, Marc Blanchet 20 new documents since Pittsburg most are going to be presented this week not: UDNS, BRACE, SACE, CJK (last presented in Pittsburgh). Status of documents - requirements: last rev and go WG last call after San Diego WG ACE Prefix registry if needed by the WG can be done on a temporary = basis * More radical solutions: directories and basic DNS changes, John = Klensin Internationalized access to Domain Names: Some Radical Solutions Worried for some months about too narrow a focus. We're looking for = quick=20 solutions. Problem with quick solutions is that they are usually not as=20 quick as they're supposed to be, especially in deployment. As a result, = we=20 have to get rid of them. This issue is very important since its effects = are very extensive -- affecting current past and future. Started exploring a different question -- what should we have done if we = started in the beginning? This is a different question than how to we=20 start from where we are today. Short term question: how to get i18n domain names now, i.e., quick=20 deployment. Steps taken for short term are with us forever. Design for long term: problem figures out how to get there, preserve=20 installed base Designing for i18n: - not fitting i18n into the network - not just a DNS problem -- applications need to work and make sense -- need to support presentation of non-ASCII characters everywhere users = would expect -- extreme user case is on whose keyboard doesn't have ASCII - rethinking several assumptions IDN may require a presentation layer - IETF tradition usually -- keeps users close to protocol interface -- often done because we are lazy and it is easy -- or to keep things simple (may be the same thing) - internationalization may not permit this - difference between -- unique strings stored in Internet-wide databases -- appearance of names to users -- selection and choice mechanisms two hypotheses / strawmen - not a DNS problem -- we are looking in the wrong place -- very restricted protocol element, not ASCII -- still the right choice -- solve UI problems at another level - DNS should be fully international -- content is names, not protocol elements -- names should reflect international usage DNS is being pushed in a direction where it doesn't belong - symptoms showing up in many places, not just i18n - DNS doesn't do -- search -- ambiguity -- nearest server directories - not a technology or protocol but a class of them -- typically good at handling problems for which the DNS is weak --- multiple forms of lookup --- attributes with values --- tolerance for ambiguity - IETF has never succeeded in widespread deployment of a directory = protocol -- but maybe this issue is important enough Directory protocol modules - applications don't call DNS with user supplied names -- call directory with names or keywords -- involve user in evaluation if needed -- get results ad call DNS -- DNS labels remain "protocol elements" For many applications, replace gethostbyname() Directory advantages - well adapted to user selection of target from a list - use with keywords and descriptors not just rigid names - attributes can identify - types of use and business location (may help with trademarks) - multiple server Disadvantages - the Internet has never deployed one - reaching an agreement on protocol and schema - too many options Legacy application code: - don't call directory, hence don't see internationalized names - can use only a subset of Internet until upgraded - transition similar to host table to DNS Other hypothesis - assume it should have contained non-ASCII (names not protocol = elements)=20 from the beginning - would look like IS 10646 everywhere - Mixing old and new conventions cause problems - A new class? Obsolete "class=3DIN" Everything going forward goes into the new class Changing classes - in principle, obsoletes everything -- no requirement to share server tree, delegations, etc. with = class=3DIN - Some advantages of preserving models Transition issues - copy existing records or search - pointers from the new to old class - political nightmares - opportunity to not carry rubbish forward Legacy applications and Code - Don't know about new class so "see" only Class=3DIN - non-ASCII names are invisible until they are upgraded Shared problems - DNS ASCII is convenient -- case independence and matching rules are easy -- very small number of characters - Almost any international character set will require canonicalization = and=20 matching rules -- and may require localization - ISO 10646 requires non-obvious coding decisions UTF-8 may not be the=20 right choice Documents - Directory -- draft-klensin-dns-role-00.txt - New Class -- draft-klensin-i18n-class-00.txt Eliot Lear: the problems I face: we don't have a successful = hierarchical=20 directory. I don't think we have the luxury of time and we don't have = the=20 technology. I don't see anything that can scale as well as the DNS. JK: let me lay part of that question aside. I can argue either side. = The=20 question of time is an interesting one. Our hope a solution would be=20 converged upon fast enough that junk wouldn't be deployed. We lost. = But=20 problems with the trash are becoming obvious. Our only opportunity is = to=20 do it right. Half-right and quick won't do it. Taking the extra time = to=20 do it right is the right thing to do as it will help get rid of the=20 trash. Some better than trash, some worse, average is trash. Michael Mealing: you said there were components to directory service. = Have=20 you given any thought to what the components might be and whether we=20 already have some of the components JK: If I say "yes" and duck, would that be an appropriate=20 answer? Directories are complicated. Talk about that as a design=20 principle instead of getting bogged down into whois++/ldap is better=20 arguments. After posting my draft I received two groups of=20 comments. First group: first attempt to view it at an architectural=20 issue. Second group: my schema better than yours. LDAP better than = .... =20 If WG comes to a decision that a directory approach is the best way=20 forward, then we sit down and focus. Keith Mitchell: in response to the new class proposal, it seems that = what=20 you're doing is partitioning the applications in the Internet to those = who=20 can deal with I18n and those that can't. The on the wire protocol = doesn't=20 matter, it is what the applications do with the protocol. The other = thing=20 is if we use this to de-cruft the DNS, trying to clean up things gets = out=20 of hand. JK: No intent to change protocols. The rest is a bar discussion Hideyo Imazu: Directory based solution is mostly for WWW. ACE based IDN = solution can be applied to email. Among countries like Japan, China,=20 Korea, internationalization of entire email address should be considered JK: Directory works as well for email as for the web. Doesn't work for=20 non-interactive, non-online applications. Architecturally, it feels = like=20 the right solution. David Chadwick: Support the directory notion, users need the search=20 facility. Once we have multiple characters sets, we must have a way to = search. James Seng: John's proposal is a very theoretical proposal. Fairly = close=20 to NGDNS. Internationalization of NGDNS is probably one of the problems = that can be fixed. Some of the comments are very true. Good starting=20 point for NGDNS. Not talking about long term deployment of NGDNS, = looking=20 at RACE for quick deployment. I'm afraid the chaos during transition to = NGDNS would be disastrous. JK: I believe it will take 10 years to deploy anything this WG comes = out with. JS: Yes and no. To do a directory would require a comprehensive=20 re-architecture. Removing stuff from current DNS has not really been=20 discussed. Ted Hardie: Eliot was wrong, you aren't being radical enough. We have=20 never had a presentation layer. Putting a directory layer between=20 application and DNS is a presentation layer. Perhaps coming up with a=20 presentation layer. Bob Hinden: Both of these choices have plusses and minuses. There are=20 harder issues and dealing with them scares me. Solve the important=20 problems first. JK: I think this is the most interesting and hardest problems since=20 deploying IPv4. We need to take this very seriously. * IDNA, Patrik Faltstrom ACE from the Applications Not so nervous about changing applications. Really nervous about = backwards=20 compatibility. This proposal is to change the presentation layer in applications. Not=20 change the application layer protocols, the DNS protocols, or the DNS=20 servers. We only change the presentation and input mechanisms. When a user inputs a domain name into the application, the information = will=20 be stored in whatever local script the application is using. The=20 application must do a transformation anyway. Many applications must be=20 better regardless of what we choose. All applications must transform = from=20 the local character set into something that is entirely backwards = compatible. Changes to applications: - host names must be nameprep'd - an ACE is applied - sends encode name to resolver Display of host names +++ Known side effects - un-updated applications will display obscure ACE format (leakage) - moving names from update programs to un-updated programs might cause = more=20 leakage - Non-IDN names that use the ACE prefix or suffix will either be = considered=20 illegal or will appear as nonsense characters - The IDN WG must choose an ACe - Doesn't internationalize text records in the DNS zone files Updating name servers - administrative interface for DNS servers must all ch3ck IDN names - probably done with automated scripts converting from and to preferred=20 native format (which will be different for different users)p - Will probably be important to check all names with nameprep No major comments (Yet!) to -00 draft No planned revision Pete Resnick: work in a protocol that has lots of layer violations. = email=20 embeds DNS names. Do we need sendmail to change headers to ace encoded = things? PF: one of the good things about this proposal is that it is an = application=20 layer issue. Paul Hoffman: No. What we're talking about presentation layer change. = If=20 you've changed your application to handle IDNA, then all applications=20 should handle IDNA. We don't want to touch things that IDNA will be=20 looking at layer. You must change your paste function. PR: I update Eudora to do IDNA, I encode for presentation, decode for=20 transmission. PF: Yes. Yoneya: It should apply to any application protocol PH: Applies to any protocol that has a presentation layer. Rick Wesson: encoding and decoding leakage was experienced in the VGRS=20 testbed. Broke lots of things. Leaks happen. PF: leakage is a bad thing. If leakage occurs and if you know the ACE=20 version, you can still figure out where things should go. Hideo Imazu: Considering the fact that there are very few fonts that = have=20 all Unicode characters in it, even if a platform has full support for = ACE=20 encoding, in some cases, it can't encode/decode an ACE sequence for some = characters. Even on a good implementation, leakage can happen. PF: Yes. It might be possible for user to look at ACE encoded name. PH: Decoding will be possible, but display may not be possible. JS: another leakage not considered: user assuming application is=20 internationalized and its not. PF: Yes. * Virtually internationalized domain names, Shim Allows the use of i18n domain names, but without creating i18n names. ** Description Most domain names in regions where English is not widely spoken, are=20 created as the characters of the local language are transliterated into=20 those of English language. VIDN formalizes and uses this knowledge of transliteration At one end, we have local characters, at the other end, we have regular = DNS=20 characters 1. local characters changed to phonemes 2. each phoneme is matched with English phoneme 3. English phonemes are united to form the transliterated name provides one to many mappings For one-to-one reversible mapping a) each server is pre-assigned a unique code (e.g., Unicode) b) the code is also generated by VIDN on the client whenever the=20 corresponding virtual domain name is typed. c) the code is compared to the code retrieved from the server d) VIDN matches the code ** Implementation and Administration Development of VIDN software for each local language may be done by a = local=20 standard body - the codes for one-to-one mapping may be administered by international=20 standard body such as IANA or the codes may be administered by a local standards body ** Key features VIDN does not require creating and registering additional domain names = in=20 local scripts VIDN does not make any change to the current DNS infrastructure VIDN does not need separate name server/resolver ** Testing results Keywords and ACE require conversion, VIDN already there. Web browser add-on: - Korean-English conversion - 800 KB Comments/ Suggestions - Comments and responses on the IETF IDN discussion mail archive - Contact me Itashiro: different ideographic script can have same pronunciation, how = do=20 you convert? Shim: include one-to-one mapping scheme Paul Hoffman: this can be used today, but only when a code isn't=20 needed. If a code is needed, they'd be non-obvious to users, so your=20 assertion that this is easier/faster to deploy isn't true. MIght be = true=20 for Korean or maybe Japanese, so same as ACE or IDNA. Shim: 30%-40% will need the codes. ACE/IDNA will be 100% Maynard Kang: if you add the addition of the code, then it is the same = as ACE. Internationalized PTR RR, Hong Bo Shi Why not PTR: - Current PTR and its mapping method can't support IDNS as well as=20 traditional ASCII domain names - It is impossible to let client to choose which it wants from those PTR = records without any additional selection - It makes no sense to return an unreadable domain name - But no PTR record is worse. Why IPTR: - IPTR can give a language selection to client/end-user - accordin to the language tag, the cli3ent/end-user can get what they = want=20 from a list of corresponding values IPTR Format 4.3.1.1.in-addr.arpa. IPTR "LANGUGAGE" "name-in-utf8" - the LANGUAGE field should be treated in a case insensitive manner and=20 must follow the conventions defined in 1866 EDNS0 is require to implement IPTR IPTR format Langauge: 2 octets, an argument for IPTR to define kind of language used = in=20 the following IDN label IPTR query/response If qytpe=3DIPTR then all of the corresponding IPTR RRs should be = returned in=20 one response Transport: use UDP first if TC bit set, then use TCP in future, EDNS0 is required. PTR extension FOR IDNS ONLY case it is very difficult to avoid IDN ONLY IDN ONLY means a host only has its IDN but not any traditional ASCII = domain=20 name - in above case PTR RR must not be null in a response message - PTR RR must contain a domain name in ACE to co-op with IDN unaware = systems -- else a syntax error message should be sent back with an administrator = configures zone Open issues: - do you think we should return all corresponding IPTR records to a = resolver - nameserver should only send back one IDN in each language - this kind of function has already been implemented, for example in = BIND-9.x.x To be or not to be - it is said that the proposal that returns all the corresponding IPTR=20 records increase the complexity to implement a resolver - according to the suggestion it is better to let a server just feed = back The above suggestion is in the belief that the IPTR design is to = introduce=20 a language tag. it should be used in queries from client. Demchenko: it is not enough just language, need character set + language Jiang: intention was just language, not character set. the character = set=20 is supposed to be UTF-8 Hideo Imazu: specifying language is not enough in some cases. Jiang: mixture of languages? HI: some languages have two scripts J: right. we're just trying to capture language, not script. * Protocol Design Team Report, David Lawrence: Primary task: categorize protocol proposals and make recommendation to = WG Members: DL, Olafur Guomundsson, Dan Oscarsson, Paul Hoffman Observers/commentators: Marc Blanchet, Harald Alvestrand, John Klensin, = Rob=20 Austein, James Seng Output of the design team - report to the mailing list (didn't make it before this meeting, will = have=20 it soon afterwards - comparison of protocols - possibly other reports or recommendations -- updating 2425 to take a much deeper look -- looking at different ACEs Categories of protocols, based on expected implementation - Do a long term architecturally clean fix that requires upgrading to = the=20 whole naming infrastructure - Change only the applications in the sort term and possibly the=20 application protocols, but change none of the DNS infrastructure - change the applications for short-term gain, but transition in the = long=20 term to a clearer solution that requires upgrades to the whole naming=20 infrastructure (two-phase approach) IDNA- application IDNE- infrastructure Big picture - we cannot simply put binary characters into the current DNS without=20 breaking many applications and some DNS servers - none of the solutions at this point is a comprehensive solution that=20 considers all the effects of the changes proposed - the design team has not looked at all impacts on applications Where the solutions fit - long term solutions mostly involve changes to the current DNS=20 infrastructure, although there is also a proposal for using a directory=20 layer with internationalized input to find resources - short term solutions are based on using ASCII compatible encoding in=20 applications - Two phase solutions are a mixture of the two Infratructure solutions - long term proposal require that all DNS servers in a request path be=20 updated before the user can get a correct answer to a query for an=20 internationalized host name - different proposals and different legacy DNS servers will cause = different=20 error messages to get back to the user if their query traverse a server=20 that was not upgraded - a user can get different results for the same query - maximum breakage of applications ACE solutions, positive - they are easier to implement than the long term solutions, but they = are=20 not without problems - the obvious advantage is that update just applications will go faster=20 than updating applications and the entire naming infrastructure - they work on the presentation layer which means that they don't even=20 require changes to any application protocols. ACE solutions, negative - ASCIIi-type ugly name leakage in non-updated applications - non-IDN names that use the ACE prefix or suffix will either be = considered=20 illegal or will appear as nonsense characters - the ACE solutions only internationalize host names, not textual = material=20 that appears in some types of DNS records - IDN must choose an ACE - versioning is harder in ACEs than in other proposals - there are probably other ACE-specific implications that we haven't=20 thought about yet Two phase solution - request that the applications be updated to handle an ACE encoding in = the=20 case the query using the long-term solution fails - every application must work correctly with the short term solution and = the long term part of the solution has all of the problems listed = earlier - it is likely that only the short term solution would be implemented=20 unless the long term solution had other notable advantages ACE considerations - ACE must be designed to have one-to-one mapping and versioning - they must continue to use 63 octet max for name parts, while other=20 proposals cold extend the length of the name parts Changes to applications - all scenarios will require that all applications that use the new = names=20 be updated 2825 lists many protocols for which i18n may be very = difficult. Go with DNS infrastructure Change - the decision about which of the solutions is chosen should be made by=20 people in the DNS community and Application area with = internationalization=20 community Directory infrastructure - WG needs to work closely with the directory community for both = protocol=20 and schema interoperability - no successful operational experience in an Internet wide directory = service Suggestion: go with application-only solution, - focusing on the negative attributes of each solution, the design team=20 considers the short--term "use ACE from the application" Looking at costs: - we note that the more arch. desirable infrastructure solutions are = very=20 costly in terms of new protocol work needed and upgrading deployed name = servers - predicting when any of the solutions might actually be useful is=20 impossible, making them very difficult to sell to the Internet community An ACE solution does not prevent an infrastructure solution - fortunately choosing the ACE solution now does not preclude the EITF What's next: - design team finishes its report and send it to the WG - design team finishes the comparison document - somebody should study the impacts of the chose solution more in-depth - WG decides J Kim: forgot one negative -- two sided business card problem. = Amazon.com=20 in English, Amazon.com in ACE is a tour site. That is a serious problem = to=20 solve. DL: which aspect of the two-side business card are you talking about. = this=20 is a registry issue. JK: but the problems arise from a technical basis OG: the ace encoded name will be long and ugly RW: Verisign has posted their resolution proposal: UTF-8 on the wire, = how=20 did the design team feel about it. OG: no comment. PH: UTF-8 on the wire was a non-starter DL: we're avoiding recommending a two phase solution EL: operational infrastructure change is not mutually exclusive from=20 presentation change. Refers back to John proposal. Two problems:=20 representing domain names and transliteration. there is value add. RB: DNS protocol supports 8 bit binary. Does not break DNS but might = break=20 other protocols. Design Team: agree MM: directory approach not feasible due to schema is a red herring as = DNS=20 RRs define schema. If you constrain your space, makes the problem more=20 easily solved. DL: Yup. Proposal for a determining process of ACE identifier, Naomasa Murayama Requirements of IDN technology: - unified root - interoperability - compatibility to BIND RACE: row based ACE - prefix bq-- Brace: bimode row based ACE Why ACE? 1. permitting 8-bit domain names and modify name server software to 8 = bit=20 clean 2. partitioning the current domain name space to accommodate MDNs using=20 some kind of ACE problems for approach 1 - difficulty in inter-operability - needs a change of DNS protocol problem for 2 - needs a consensus among all domain name registries in partitioning the = DN=20 space How can we negotiate for a partitioning of the DN space - how we can select ace identifiers ACE identifiers :=3D- ACE prefixes | ace Suffixes What is happening in the testbed of MDN in .com,.net,.org registration started from Nov. 10 but .com is encoded and taken = by=20 ns.bulkregister.com on Nov. 2 ACE identifier candidates - prefixes: AA--, AB--, ..., 99-- - suffixes: --AA, --AB, ..., --99 Relevant domain names: aa--a.com, aa-b.org, ..99--zzzz.net, aa--x.co.jp, etc. a-aa.com, b--aa.org, ..., zzzzz--99.or.kr, etc. Proposal step 1: tentative suspension of registering relevant domain names for = ACE=20 identifier candidates step 2: conduct a survey of relevant domain names already registered step 3: select about 10 to 20 identifiers one of which is for test and=20 others for real use, based on the survey step 4: permanent blocking of registrations of domain names relevant to = the=20 selected identifiers (except for registrations compliant to MDN = semantics). when writing an ACE proposal author should either - describe the ACE identifier as "to be decided" which must be decided by the IDN WG or other organ when it is p[ublished = as=20 an Internet draft) or use an ACE identifier When a proposal becomes an Internet standard - when a specific ACE proposal is accepted as an Internet standard, the=20 experimental ACE identifier should be replace by one for real use=20 (hopefully decided by IANA) Important change from -00 to -01 excluded suffixes of one hyphen followed by the alpha numerics from the=20 candidates Among 227, 852 registrations of .JP domain names, 23921 were relevant to = these suffixes Need cooperation of IETF, ICANN, and domain name registries. * Handling revisions of IDN, Marc Blanchet Problem statement: Unicode is going to have revisions because of=20 characters, languages, scripts that change Nameprep is going to have revisions. Nameprep should not necessarily be = sync'd with Unicode revisions. We might fix bugs in nameprep, etc. Protocol will have revisions. We should include versioning in the=20 requirement document Patrik Faltstrom: I think the requirement should be able to handle = changes=20 in Unicode. I'm not sure we need versioning. I have some ideas on how = to=20 handle this in ACE which would not affect nameprep. Not fully=20 baked. Might not need versioning. Don't want to have versioning as the = requirement. Unicode and nameprep will change. MB: will work together on how to specify the wording for the = requirements Versioning with ACEs and IDNA-like approach: there is no protocol. One=20 way: have a different prefix for each version. But: no negotiation is=20 handled. Needs the same domain registered with different prefixes. Versioning with DNS extensions Version numbers: simple, increment by 1. More complex major.minor. = minor=20 changes table lookup, major being changes in lookup algorithm. Table format simplified Unicode table. Conclusion: we need versioning in IDN. We can do it in different ways = and=20 need to think about it. Harald Alvestrand: versioning in the ACE means you'll either see every=20 i18n domain name disappear each time you upgrade client or you'll need = to=20 do queries for each version. Having different labels is too broken for = words. Mark Welter: what would drive the versioning is characters forbidden at = the=20 application layer. Can push this to the registration layer. MB: I'd prefer it if we don't need it at all. But we should think about = it=20 before doing the protocol. Randy Prezen: You only care what happens after the ACE transform is = applied. MB: Just think about it. If we don't need it, good. * Japanese characters in multilingual domain name label, Yoneya Definition of characters to be used as JP characters in MDN label Definition of JP characters to be normalized. Def. of JP characters: - idntabjp10.txt -- does not include NAMEPREP prohibited characters - usual characters for JP names - selection of chars is based on JIS - table consists of code points in Unicode and corresponding JIS code -- does not mean specifying chars 6531 characters in table Kanji: 6355 Hiragana: 83 Katackana: 86 Graphic:7 Definiton of normalization: table of compatible characters to be canonicalized idntabjpcanon10.txt - one character must be added, will correct in next version compatible characters prohibited in NAMEPREP but widely used in PCs, = PDA, etc. - half width katakana - full width alphabets, numerics, hyphen - table consists from code points in Unicode to be canonicalized -- half width katakana and full width katakana must be canonicalized to = the=20 same thing Def. of normalization (cont) Table of characters to be composed idntabjpcomp10.txt composition of kana and voiced sound mark varieties - the table consists of code point sequences in Unicode to be composed -- ka-tenten -> ga Definiton of normalization rules: 1. canonicalize compatible characters -- adopt idntabjpcanon conversion 2. compose voiced sound marks -- adopt idmtabjpcomp conversion Example: 1 canonicalization idntabjpcanon 2. canonicalization idntabjpcomp 3. NAMEPREP Why: - convenience for users and implementors -- explicit definition of usable characters and normalization -- Unicode KC is insufficient --- differences exist between VGRS and JPNIC Mark Davis: the changes you are talking about are combining certain=20 forms. I don't see the requirement for additional steps. YY: difference is between JIS and Unicode KC. MD: if you map these together in the folding step than KC takes care of=20 this for you in the normalization step. * Nameprep design team report, Paul Hoffman This is a summary of what we posted to the mailing list last week. Overview: - make it easy for user to enter names. -- we don't want to make it hard. - prohibit as little as possible -- not all domain names are entered by typing. - keep names sensible -- there are plenty of chars (such as backspace) that are bad/dangerous. - linguistic juggling. -- don't over-restrict. not a protocol discussion. "yes, good=20 character. no, bad character" Proposed changes from -00: - fewer prohibitions on input -- may limit on output -- make it so that input programs do not need to follow the output rules - make it easier to implement -- every application has to do nameprep regardless of protocol approach = taken -- give tables for 2 of 3 steps prohibit less: - it is difficult and probably not useful to try to limit confusion -- e.g., should 'O' been prohibited because it looks like '0'. - get out of the business of disallowing because they look alike - -01 will have much smaller list of prohibited characters - -00 prohibited compatibility characters. -01 says that if you can=20 algorithmically change, then accept on input -- many examples in Arabic and Asian scripts Change order of steps: - ordering was prohibit -> fold (case mapping) -> normalize - ordering is now map -> normalize -> prohibit -- prohibit on output Many edge cases in ISO-10646, so doing mapping first can be very clean. Currently we just do case mapping. New version will do additional = mapping=20 such as mapping all hyphen characters to normal hyphen. There are some=20 special cases for case-mapping that need to be added so that all = characters=20 case-map as expected. Won't change semantic meaning of characters (in = JP,=20 hyphen and lengthener characters would be treated differently). At the = end=20 of the process, we won't have surprised characters. Have option of mapping into nothing instead of prohibiting. Haven't=20 specified which we would do this to, but Arabic and Hebrew vowels could = be=20 mapped to nothing (as per discussion on mailing list). Use a couple of hundred line list of mappings to be done with the first=20 step of nameprep. We think this would simplify things New case folding: - mapping to lowercase will be derived from Unicode case mapping file Non-character code points: - non-character codepoints will be listed as prohibited characters - already Unicode code points assigned as non-characters Make everyone look outside plane 0. Remove location of nameprep - this is a protocol issue. the protocol must say where nameprep is = done. - different protocol proposals need nameprep in different places Change canonicalize to normalize Next steps: - WG reviews design team recommendations - Marc and Paul produce -01 based on WG consensus - Design team keeps working on remaining issues -- what is still prohibited on output vs. what is mapped to nothing on = input -- a few specific characters need attention PF: sent a proposal about taking unmapped characters and calling them=20 prohibited or pass through depending on usage (registration or lookup). = If=20 you want to talk, I'll forward to nameprep design team. PH: we'd love to see a specification Mark Walter: did you find a solution to the dotted capital i problem PH: yes, we picked one. MW: Greek capital gamma looks like a capital Russian character, so there = is=20 room to masquerade one name as another. One way to fix this is to have = the=20 user look very hard. Greek user most likely not use Russian chars. PH: the design group saw this as the '0'/'O' problem. We didn't want to = go=20 there. THis will go into the security Rick Wilson: are some of these font characters? PH: yes. RW: Can you characterize where you lightened up? E.g., can you now put = in=20 Zapf Dingbats? PH: yes. We also allow the compatibility characters Eric Brunner(?): does the change of ordering allow us to fix problems=20 introduced by authors of 10646? PH: yes. If you have a list of errors, send them to the nameprep design = team. Chris Neuman: on the versioning issue, having a recommendation that=20 deployed software be able to load mapping table without a new version of = the software, would be reasonable and sufficient. PH: please send the suggestion to the design team. DNSII transitional reflexive ASCII compatible encoding, Edmund Chang Trace is not another ACE. It is a deployment/implementation strategy. Trace format is a zone file management system. We've put a control=20 character into the ACE so people won't be able to register before things = have been finalized. Transition: - ASCII to multilingual - local encoding to ISO 10646 - ace to long term solution - ace to ace reflexive: - deployed at the server end and activated only when certain criteria = are met - utilizes existing RR types as ad hoc records: CNAME, DNAME -- using DNAME is probably better Long term solution: - ACE -- strength: easy to deploy -- weakness: version control - Protocol approach -- expandability -- weakness: more difficult to deploy - Phased hybrid approach -- ACE approach as immediate and fallback, protocol approach as next=20 generation (eliminating ACE versioning requirement) Bit-flag based: - DNSII-TRace format - \127\127ILET-Hex Possible implementation: - \12701--UTF8inhex - \12701--acestring Quasi-directory based - DNS directory hybrid -- utilizing the DNS wildcard: * - *.domain in zonefile - employ separate server for lookup and sub-delegation OpenIDN - open-sourced NeDNS - Current implementations: - RACE, simple hex dump DNSII & TRACE - Contemplated Additoins: -- IDNE, DNS CLASS (john Klensin) - Invite all I-D authors and interested parties to contribute to the IDN = server experiments - http://www.openidn.org Paul Hoffman: have you done a draft on this? EC: Yes, TRACE. PH: Have you released the IPR for your patents? EC: I send the info to the secretariat when we put the site up. JK: For those whose proposals or plans require changing or doing tricky=20 things with the DNS, please remember that it is a complex=20 protocol. Wildcards will get you. DNS is UDP, it has timeout=20 properties. Not many tries possible. Please understand the protocol=20 before you go EC: that's exactly why we want to create a working prototype and see = what=20 happens. JK: the interesting thing about the IETF is that we have exactly one=20 problem: scaling. A prototype can often tell us exactly nothing. * LACE: Length based ACE for IDN, Mark Davis Goal: simple design with good compression. Uses run length encoding. = Uses=20 base 32 encoding Input is UTF-16 after nameprep. Take each sequence of common top bytes. If total length happens to be longer than the original, then you just = quote=20 the UTF-16 and base32 encode Same compression as RACE for incompressible characters. Simple. All code points are equal. No quoting necessary, except when = no=20 compression possible. RW: I like this. You should update your draft JS: Can you explain why LACE would have better compression than RACE? MD: If you have two different scripts, LACE will be better than RACE. MW: Any comments on how it handles names outside plane 0? MD: It handles it as UTF-16 YY: LACE is simple and efficient for Japanese * Designing an ACE for IDN, Mark Welter Had a bunch of ACEs proposed, explores design base well. Using Unicode as a base is good. Simplicity and efficiency are where=20 difference lie. Enoding algorithm should be straight forward. If possible, making it pencil and paper algorithm would be nice. My two schemes are nibble based. Efficiency: - should have uniform treatment for the various scripts - CJK are pre-compressed, can't expect too much better than hex Handling surrogates - in our UTF-6 proposal, we treated surrogates to 16 bit quantities and=20 closed to our eyes to the issue - we should be dealing with surrogates expanded DUDE: - encoding based on radix 16, representation of initial code point = followed=20 by encoded hex diffs of subsequent codepoints What about surrogates: - if you don't expand surrogates, the worst case limits are half to two=20 thirds of claimed name lengths - DUDE handles expanded surrogates gracefully Ways to separate IDNs from ordinary DNs - add a per segment redirector - add a once per name redirector - combination of above MD: Characters above FFFF will be extremely rare, so trying to compress = is=20 a waste of effort. MW: focus is handling full Unicode. Matter of taste. * Update on RACE, Paul Hoffman Major changes in -03 draft - added the need to check for all -STD13 names before encoding and after = decoding - added many error conditions in both the ACE and the Base32 encoding = and=20 decoding -- didn't change anything on the wire - Changed all the examples to use lowercase characters on input -- nameprep is going to change everything to lowercase What I didn't change: - left the prefix the same because the bits on the wire are the same Verisign is using RACE in their testbed. They provided the first 1500=20 rejections. Some were base on Verisign's prohibited character. Most = were=20 errors in RACE encoding. Speaks poorly of RACE's ease of implementation RW: for those that are implementing RACE, there is a mailing list for=20 developers. Send mail to Rick . * Judging ACEs, Paul Hoffman Going to have to pick an ACE. What we should look at. Features of a good ACE: - it has compression -- least restriction for total name length -- shorter transmissions - simplicity -- easy to code -- easy to find bugs in code -- few special cases Compression: - prohibiting sensible long names is bad - all ACEs allow different length for different scripts - shorter transmissions is useful but not nearly as important as not=20 restricting long names -- if we have a trademark, go with longer names Simplicity: - RACE has show that implementors can easily get it wrong - Even if compression step is easy, if decompressing is hard, display = and=20 security errors will be made Complexity: - special cases get missed or are misunderstood - bit stuffing achieves better compression but is very difficult for = many=20 programmers -- even base32 seems hard for some Mandatory Features for all ACEs: - encoding a string of characters can have only one result - decoding an ACE string can have only one result - There must be a way to indicate a version number Summary - compression - simplicity - mandatory features - what else? MW: in terms of decoding, it is complex enough that the only way you can = guarantee is to take the resulting decoded Unicode, encode it and decode = it=20 again to see it is the same. PH: I agree. * Discussion and WG Next Steps, Marc Blanchet We think we have a lot of solutions. We should narrow the solution=20 space. We've had two design teams, one on nameprep one on protocol. Is the nameprep work the right thing to do as a major WG orientation? RW: yes, I agree with what you are going and should continue to do it. MB: Namprep right direction? MB: on the protocol, we have a recommendation to use an ACE (not=20 disallowing something different in the future). Do we have enough = information? RW: I think some of the things John Klensin proposed should be looked = into=20 further. I don't think we should pick RACE. Dongman Lee: I'd like more information about 8-bit approach problems. = A=20 web page or report would be helpful. MB: 8-bit on the wire or 8-bit tagged. Dongman Lee: more interested in the problems RW: there will be a report kicked to the DNSO on operational=20 considerations for the registrar constituency Erik Nordmark: Are you asking to choose an ACE today? MB: The question was are we going forward with the design team = recommendation. Rob Austein: I believe continuing to figure out which ACE to choose is=20 good. Both of JK's drafts came in late. I don't think we've had time = to=20 consider them properly. My major concern is that we may never move on = from=20 an ACE if we deploy it. Olafur Gudmundsson: it was very hard to recommend an ACE while on the=20 protocol design time. I'm not sure it will work, but I can't find a = place=20 in applications where it will fail. We're looking for 7-10 year = deployment=20 period. All current proposals fail in one way or another. Paul Hoffman: if we go with a short-term (application only ACE), we are = not=20 preventing longer term solutions. I want a long term directory = solution. David Lawrence: as a member of the protocol design team, I don't want = the=20 IETF/IDN to be marginalized if we don't respond in a timeframe that = matches=20 the market demand. Ted Hardie: getting something out of the Internet infrastructure is=20 hard. Effort should be focused on the more general solution. There = might=20 be other areas of the presentation side of things that need to be looked = at. Patrik Faltstrom: as an area director, seeing what works and not works=20 doesn't depend on the applications, we need to look at other=20 protocols. Regarding the ACE encodings, I think the path we are going = is a=20 much more layered design than we normally do. This doesn't preclude=20 inserting a directory layer John Klensin: this working group has two choices regarding market = forces=20 and competitive ideas. Do it hastily or do it right. Too late to do it = hastily. If the good solution solves the problem better than the = market,=20 the right solution wins. Harald Alvestrand: before we leave this room today we should have an = idea=20 of whether we should go with ACE or not. Mark Davis: I agree with the last speaker. People have been talking = about=20 domain names as if what you see is what you get, but the stuff over the=20 wire is just bits. Using one of the ACEs gives a different set of bits. <>: Comfortable with what the protocol design team did. I don't think = we=20 should have a final sign off unless we have a transition strategy for = the=20 long term solution. MB: Many said we should choose ACE. Many said we should think more. JS: Do we have enough information to say the protocol design team is=20 working the right direction? PH: We thought we were done. MB: Is there enough information to make a decision? JK: Of the people who think they have enough information, do you feel = you=20 know enough about the DNS? DL: is the consensus of the working group to be focusing on an = application=20 area approach. Should we stop looking at infrastructure approaches. HA: this does not mean the infrastructure need replacing. just that = this=20 WG is not the one to do it. MB: Next step is choosing an ACE. ------=_NextPart_000_0095_01C07E31.27BAE170-- From owner-idn@ops.ietf.org Sun Jan 14 02:51:42 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08100 for ; Sun, 14 Jan 2001 02:51:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Hhdg-0003Hx-00 for idn-data@psg.com; Sat, 13 Jan 2001 23:31:44 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14Hhdf-0003HY-00 for idn@ops.ietf.org; Sat, 13 Jan 2001 23:31:43 -0800 Message-ID: <001101c07dfd$61df5cc0$82022b18@yec1.on.wave.home.com> From: "Edmon Chung" To: "Rick H Wesson" Cc: , "David R. Conrad" References: Subject: Re: [idn] who uses BIND as a base for their internationalized DNSpackage? Date: Sun, 14 Jan 2001 02:41:16 -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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rick, The reason we are using a password system is that we would love to later (hopefully very soon) be able to entertain multiple branches of the OpenIDN NeDNS based on the different proposals at the IETF and that their proponents would be able to post updates and patches relevant to their branch directly. The whole idea for OpenIDN is to provide a forum for which I-Ds on the IDN topic could be tested out. It is intended that application side products would be available soon too for people to tryout Application-only-ACE proposals. The registration process is simple and we hope it wont be too much of a hassle. Edmon ----- Original Message ----- From: "Rick H Wesson" To: "Edmon" Cc: ; "David R. Conrad" Sent: Saturday, January 13, 2001 2:42 PM Subject: Re: [idn] who uses BIND as a base for their internationalized DNSpackage? > > Edmon, > > Why does your OPENidn stuff require a password, seems oxymornic for > authenticated access for something billed as "open." If you truly want to > bill this stuff as open source then you shouldn't require a registration, > unless you are searching for a business model... > > -rick > > On Sat, 13 Jan 2001, Edmon wrote: > > > Hi David, > > > > If you go to www.OpenIDN.org, you will see that the Neteka NeDNS version on > > the site is also BIND based, though we also have other versions that are > > not. ;-) > > > > Edmon > > > > > > ----- Original Message ----- > > From: "David R. Conrad" > > To: > > Sent: Friday, January 12, 2001 9:27 PM > > Subject: [idn] who uses BIND as a base for their internationalized DNS > > package? > > > > > > > I know the following do: > > > > > > i-DNS > > > Worldnames > > > > > > Who else? > > > > > > Tnx, > > > -drc > > > > > > > > > > > > > From owner-idn@ops.ietf.org Sun Jan 14 03: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 DAA06867 for ; Sun, 14 Jan 2001 03:52:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HijL-0006CK-00 for idn-data@psg.com; Sun, 14 Jan 2001 00:41:39 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14HijK-0006C6-00 for idn@ops.ietf.org; Sun, 14 Jan 2001 00:41:38 -0800 Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id AAA29418 for ; Sun, 14 Jan 2001 00:41:09 -0800 (PST) Received: from [10.0.1.11] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA18094 for ; Sun, 14 Jan 2001 00:41:02 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010113235701.11623.qmail@cr.yp.to> References: <200101131408.f0DE8ll29533@malmo.trab.se> <20010113213727.27292.qmail@cr.yp.to> <20010113235701.11623.qmail@cr.yp.to> Date: Sun, 14 Jan 2001 09:23:51 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Some comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 23.57 +0000 01-01-13, D. J. Bernstein wrote: >Patrik writes: >> I don't want 8-bit clean protocols, and UTF-8. I want protocols which >> can handle UCS-2, UCS-4 or UTF-16 > >UTF-8 is compatible with ASCII. UCS-4 is not. Depends all on how you define "compatible", and no, you don't have to explain because I know what you are thinking of. We don't agree here. It's as simple as that. >Switching a protocol to UTF-8 preserves compatibility; ASCII data is >unaffected. Switching a protocol to UCS-4 destroys compatibility; ASCII >bytes turn into 4-byte sequences. And? Was it not a long-term, "correct", solution you wanted? >Do you seriously believe that the Internet is going to move to UCS-4 >rather than UTF-8? Exactly what benefits is anyone supposed to see in >this? Occasionally I hear people claiming that a string of Unicode >numbers is convenient because the displayed width of the string is >proportional to the number of bytes; but they're wrong, thanks to >combining characters and double-width characters. If nothing else because of political reasons. The grade of opposition to UTF-8 is about the same as the number of bits you need to represend words in the language the person opposing the language speaks. I see a big risk the solution will _NOT_ be Unicode if UTF-8 is pushed, and that just because of the way a character is encoded. Only for political reasons. > > What I don't like in your arguments is the focus on "applications" >> instead of looking at what is specified in the protocols. > >What I don't like in your arguments is the focus on protocol specs as >religious objects, rather than as tools to help implementors provide >working software to system administrators and users. Ok. > > You talk about quoted-printable encoding and charset parameter as it >> was something which destroys the content as shredding of luggage >> would do. > >``The luggage isn't destroyed, sir. It's just shredded. As I said, you >can take some time and sew it back together. You haven't lost anything; >it's all here! By the way, would you like to buy a sewing machine?'' Sigh... > > But, software doesn't handle 8 bit stuff correctly today even though >> we have in the IETF been talking about it for a very long time. > >The IETF should have required 8-bit-clean mail software in 1982. Allman >would have fixed his software eventually, certainly before version 6.57 >in 1993. UTF-8 header fields should have been allowed in 1996. Everyone >would have been happily using UTF-8 mail in 2001. People would not have been happy at all. See above. >Instead, the IETF mail standards _still_ allow MTAs to drop 8-bit bytes, >even in message bodies. See http://cr.yp.to/docs/8bit/06.txt. But, you say that the standards is only an aid for implementors. How come still I get broken email even though I have a sewing machine? You didn't respond to my questions regarding what language etc you use, Dan. paf From owner-idn@ops.ietf.org Sun Jan 14 04:19:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07413 for ; Sun, 14 Jan 2001 04:19:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HjAn-0007Ol-00 for idn-data@psg.com; Sun, 14 Jan 2001 01:10:01 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14HjAm-0007OZ-00 for idn@ops.ietf.org; Sun, 14 Jan 2001 01:10:00 -0800 Received: (qmail 3671 invoked by uid 1001); 14 Jan 2001 09:09:11 -0000 Date: 14 Jan 2001 09:09:11 -0000 Message-ID: <20010114090911.893.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] San Diego Meeting Notes References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk Don't confuse protocols with software. The ACE _protocol_ extensions are isolated in user-interface protocols, while the UTF-8 _protocol_ extensions are not. But it is a serious mistake to conclude that the ACE _software_ changes are more isolated than the UTF-8 _software_ changes. > ACE solutions, positive > - they are easier to implement than the long term solutions, That's simply not true. The most easily implemented and deployed solution is straight UTF-8. Nameprep can be handled in the way I've described. This solution allows many existing 8-bit-clean programs, such as hundreds of thousands of qmail installations, to handle IDNs properly. (Yes, many UNIX users have to get the Unicode fonts and the UTF-8 xterm, but ACE won't avoid that. These tools are included in current systems.) The ACE solutions require more extensive code changes in more programs. They then require more deployment effort. They will, for example, require that qmail perform ACE conversions when * reading domain names from command lines, * reading domain names from environment variables, * reading domain names from configuration files, * printing domain names in logs, and * printing domain names in mail-queue summaries, because all of these are part of qmail's user interface. After these changes, qmail will have to be redeployed. UTF-8 needs changes in most MUAs, some browsers, and certain servers, notably Sendmail; deployment will not be easy. But ACE needs changes in every MUA, every browser, every MTA, every web server, and many other programs; deployment will be vastly more difficult. In short, the costs of making ACE work are much higher than the costs of making UTF-8 work. And that's not counting the future costs of switching from ACE to UTF-8 later or inflicting ACE on future implementors. > - the obvious advantage is that update just applications will go faster > than updating applications and the entire naming infrastructure This concept of ``applications'' is bogus. The OSI model does not match the reality of low-level programs talking directly to users. ---Dan From owner-idn@ops.ietf.org Mon Jan 15 02:05:25 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29187 for ; Mon, 15 Jan 2001 02:05:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14I3CM-0002RW-00 for idn-data@psg.com; Sun, 14 Jan 2001 22:32:58 -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 14I3CM-0002RQ-00 for idn@ops.ietf.org; Sun, 14 Jan 2001 22:32:58 -0800 Received: from DCROCKER.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 WAA25755 for ; Sun, 14 Jan 2001 22:32:57 -0800 Message-Id: <5.1.0.4.2.20010114222808.01ec87b0@dcrocker.songbird.com> X-Sender: dhc@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.4 (Beta) Date: Sun, 14 Jan 2001 22:32:44 -0800 To: idn@ops.ietf.org From: Dave Crocker Subject: Re: [idn] Some comments In-Reply-To: References: <20010113235701.11623.qmail@cr.yp.to> <200101131408.f0DE8ll29533@malmo.trab.se> <20010113213727.27292.qmail@cr.yp.to> <20010113235701.11623.qmail@cr.yp.to> 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 Folks, We went been through this paradigm debate almost 10 years ago. It was MIME vs. "just do 8-bit SMTP". MIME was the right answer. "just do 8-bit SMTP" was not. The ACE approach is the same paradigm as MIME. It is the right way to lay an encoding enhancement on an installed base, with the smallest amount of disruption. It permits incremental adoption, with immediate benefit to participants in the enhancement, and no critical-path changes required of the infrastructure. Changes to the infrastructure can then happen later and more liesurely. d/ At 09:23 AM 1/14/2001 +0100, Patrik Fältström wrote: >At 23.57 +0000 01-01-13, D. J. Bernstein wrote: >>Patrik writes: >>> I don't want 8-bit clean protocols, and UTF-8. I want protocols which >>> can handle UCS-2, UCS-4 or UTF-16 >>UTF-8 is compatible with ASCII. UCS-4 is not. > >Depends all on how you define "compatible", and no, you don't have to >explain because I know what you are thinking of. We don't agree here. It's >as simple as that. > >>Switching a protocol to UTF-8 preserves compatibility; ASCII data is >>unaffected. Switching a protocol to UCS-4 destroys compatibility; ASCII >>bytes turn into 4-byte sequences. >And? >Was it not a long-term, "correct", solution you wanted? =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-idn@ops.ietf.org Mon Jan 15 02:38:11 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29313 for ; Mon, 15 Jan 2001 02:38:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14I404-0002tN-00 for idn-data@psg.com; Sun, 14 Jan 2001 23:24:20 -0800 Received: from epa.secret.org ([206.220.140.150] ident=0) by psg.com with esmtp (Exim 3.16 #1) id 14I403-0002tH-00 for idn@ops.ietf.org; Sun, 14 Jan 2001 23:24:19 -0800 Received: from localhost (lucid@localhost) by epa.secret.org (8.9.3/8.9.1) with ESMTP id CAA66860; Mon, 15 Jan 2001 02:24:00 -0500 (EST) Date: Mon, 15 Jan 2001 02:23:59 -0500 (EST) From: William Morris X-Sender: lucid@epa.secret.org To: Dave Crocker cc: idn@ops.ietf.org Subject: Re: [idn] Some comments In-Reply-To: <5.1.0.4.2.20010114222808.01ec87b0@dcrocker.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Sun, 14 Jan 2001, Dave Crocker wrote: > Folks, > > We went been through this paradigm debate almost 10 years ago. > It was MIME vs. "just do 8-bit SMTP". > MIME was the right answer. "just do 8-bit SMTP" was not. > The ACE approach is the same paradigm as MIME. 10 years ago, 7-bit with 1 bit parity network connections were more common. I dont think that is the case any longer. MIME was not just a solution for 8-bit data, it also solved the issue of multipart data. > It is the right way to lay an encoding enhancement on an installed base, > with the smallest amount of disruption. It permits incremental adoption, > with immediate benefit to participants in the enhancement, and no > critical-path changes required of the infrastructure. Changes to the > infrastructure can then happen later and more liesurely. I think the end solution should be unicode (utf/ucs/whatever) ACE is not part of a migration, it is an alternative. If ACE laid the groundwork for moving to unicode I would be much more inclined to accept it for the short term. Infrastructure changes will only happen if there is a need for them. ACE will meet the developers and consumers needs, so changes will not happen if it is implemented. -Bill From owner-idn@ops.ietf.org Mon Jan 15 02:38:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29324 for ; Mon, 15 Jan 2001 02:38:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14I3yl-0002sl-00 for idn-data@psg.com; Sun, 14 Jan 2001 23:22:59 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14I3yj-0002sf-00 for idn@ops.ietf.org; Sun, 14 Jan 2001 23:22:58 -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 f0F7V3d77941 for ; Mon, 15 Jan 2001 02:31:03 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010115021238.03d99d20@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 15 Jan 2001 02:26:08 -0500 To: idn@ops.ietf.org From: Marc Blanchet Subject: [idn] The report from the design team 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, this is the report of the protocol design team, that was presented at the last ietf. Regards, Marc. ========================== IETF IDN Protocol Design Team Report January 12th 2001 Members of the IDN protocol design team looked at the wide variety of protocol proposals that have been make to the group. Of them many proposed, we found that the solutions envisioned by the documents would cause different scenarios for how internationalized domain names would get implemented in the Internet. However, we cannot simply put binary characters into the current DNS without breaking many protocols and many DNS servers. The design team has not looked at all impacts on applications, deployment, and users for all proposals. Three scenarios appear likely: - Do a long-term, architecturally clean fix that requires upgrades to the whole DNS infrastructure - Change only the applications in the short term, but change none of the DNS infrastructure - Change the applications for short-term gain, but transition in the long term to a cleaner solution that requires upgrades to the whole DNS infrastructure (two-phase approach) The long-term solutions proposed so far mostly involve changes to the current DNS infrastructure, although there is also a proposal for using a directory layer with internationalized input to find resources. The proposed short-term solutions are based on using ACE in applications. The two-phase solutions are a mixture of the two. The design team will later produce an analysis comparing the solutions, while this report to the WG gives our current view of how the working group might proceed. None of the solutions at this point is a comprehensive solution that considers all the effects off the changes proposed. Looking at the past decade of DNS deployment, it is very clear that getting the entire DNS infrastructure upgraded will take many years (where "many" could be more than ten). The DNS infrastructure proposals require that all DNS servers in a request path be updated before the user can get a correct answer to a query for an internationalized host name. Different proposals, and different legacy DNS servers, will cause different error messages to get back to the user if their query traverses a server that was not upgraded. Another problem of such a shift is that a user will get different results for the same query if the user's initial caching name server changes, such as if the user is roaming. The two-phase solutions require that the applications be updated to handle an ACE encoding in case the query using the DNS infrastructure solution fails. This means that every application must work correctly with the application-only solution, and the infrastructure part of the solution has all of the problems listed above. In such a scenario, it is likely that only the application-only solution would be implemented unless the infrastructure solution had huge advantages not associated with internationalizing host names. The application-only solutions proposed are clearly easier to implement than the infrastructure solutions, but they are not without problems. The obvious advantage is that updating just applications will go faster than updating applications and the entire naming infrastructure. Further, the application-only solutions work on the presentation layer, which means that they don't even require changes to any applications protocols. The negative aspects of the ACE-based solutions include: - ASCII-style ugly name leakage in non-updated applications - Non-IDN names that use the ACE prefix or suffix will either be considered illegal or will appear as nonsense characters. - The ACE solutions only internationalize host names, not textual material that appears in some types of DNS records. - The IDN WG must choose an ACE. - Versioning is harder in ACEs than in other proposals. - They must continue to use 63-octet maximum for name parts, while other proposals could extend the length of the name parts. - There are probably other ACE-specific implications that we haven't thought about yet. Any scenario of going from current names to IDN names will require that all applications that use the new names be updated. RFC 2825 lists many protocols for which internationalization may be very difficult. In all the solutions, applications will need to change the way that they display names to, and input names from, users. With the marked two-phase and infrastructure solutions, the applications will need to call different resolver libraries, and new resolver libraries will be needed on systems hosting those applications. If the IDN WG decides to go with any of the two-phase or the DNS infrastructure solutions, the design team thinks that the decision about which of those solutions is chosen should be made by people in the DNS community, not in the internationalization community. The DNS-based solutions proposed so far have very different effects on the current DNS, and the people who work with the DNS are better able to assess the positive and negative merits of the changes to the DNS. Regardless of the solution chosen by the IDN WG, the DNS community should certainly consider internationalizing the DNS resource records that contain free text. If the IDN WG decides to go with a directory-based solution, the WG clearly needs to work closely with the directory community to choose both a directory protocol and a schema for interoperability. There is no successful operational experience in an Internet-wide directory service. Years of experience with DNS names has shown that they are used for two very different things: in some places they are protocol elements, in others they are human readable names better suited to a separate directory service than to being co-mingled and confused with protocol elements. The people in the directory communities have much more experience than those in the IDN WG with designing directories to be helpful to end users who are searching for particular information. Focusing on the negative attributes of each solution, the design team considers the "use ACE from the application" solution to have the least serious problems and the quickest to achieve a reasonable amount of implementation. The design team is not thrilled with the solution, particularly due to its inelegance, and understands that doing anything other than simply using internationalized domain names in the current DNS is somewhat of a kludge. We also note that the more architecturally desirable infrastructure solutions are extremely costly in terms of new protocol work needed and upgraded name servers deployed, and predicting when any of the solutions might actually be useful is impossible, making them very difficult sell to the Internet community. Fortunately, choosing the application-only solution now does not preclude the IETF from later choosing any of the infrastructure solutions, and it does give Internet users the internationalized host names that they desire fairly quickly. Because the proposed IDN solution is for the presentation-layer of applications, the protocol design team proposes that the IDN WG allow the Applications Area to finish the work on the specific protocol proposal. The people in the Applications Area are most familiar with the problems associated with changing the presentation layer. The IDN Working Group still has work to do, of course. The nameprep work needs to be finished, based on at least one more round of proposals from the nameprep design team. Also, the IDN Working Group needs to choose an ACE. The protocol design team proposes that a new design team be formed to help the Working Group choose an ACE. After that process, any ACE-related issues can be addressed in the main ACE document or a companion document. The protocol design team proposes that the IDN Working Group shuts down after the completion of the above work. Many people have expressed interest in pursuing a directory-based infrastructure solution that would also encompass giving internationalized access to host names, but that work involves much more than just internationalization. It should be done in a new working group that includes directory people, internationalization people, and applications people, and should be chartered after it is clear what the parameters of the proposals entail. The team was: Dan.Oscarsson@trab.se ogud@tislabs.com phoffman@imc.org tale@nominum.com sra@hactrn.net with observers/advisors: Marc.Blanchet@viagenie.qc.ca james@seng.cc klensin@jck.com alvestrand@cisco.com Marc Blanchet Viagénie 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 Mon Jan 15 03:17:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29544 for ; Mon, 15 Jan 2001 03:17:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14I4YG-0003El-00 for idn-data@psg.com; Sun, 14 Jan 2001 23:59:40 -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 14I4YF-0003Ef-00 for idn@ops.ietf.org; Sun, 14 Jan 2001 23:59:39 -0800 Received: from DCROCKER.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 XAA26697; Sun, 14 Jan 2001 23:59:25 -0800 Message-Id: <5.1.0.4.2.20010114235241.01efaeb0@dcrocker.songbird.com> X-Sender: dhc@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.4 (Beta) Date: Sun, 14 Jan 2001 23:55:48 -0800 To: William Morris From: Dave Crocker Subject: Re: [idn] Some comments Cc: idn@ops.ietf.org In-Reply-To: References: <5.1.0.4.2.20010114222808.01ec87b0@dcrocker.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:23 AM 1/15/2001 -0500, William Morris wrote: >On Sun, 14 Jan 2001, Dave Crocker wrote: > > MIME was the right answer. "just do 8-bit SMTP" was not. > > The ACE approach is the same paradigm as MIME. > >10 years ago, 7-bit with 1 bit parity network connections were >more common. I dont think that is the case any longer. You missed my point. The paradigm pertains to making changes with an installed base. >MIME was not just a solution for 8-bit data, it also solved the >issue of multipart data. Again, that is not relevant to the question of transition paradigm for an installed base. > > It is the right way to lay an encoding enhancement on an installed base, > > with the smallest amount of disruption. It permits incremental adoption, > > with immediate benefit to participants in the enhancement, and no > > critical-path changes required of the infrastructure. Changes to the > > infrastructure can then happen later and more liesurely. > >I think the end solution should be unicode (utf/ucs/whatever) >ACE is not part of a migration, it is an alternative. no, it is not. it is a transfer encoding of unicode. >Infrastructure changes will only happen if there is a need for them. >ACE will meet the developers and consumers needs, so changes will >not happen if it is implemented. The "pure" mode will take longer, yes. That is different from never. Transition of a large installed base requires attention to maintenance of current operation. That's a necessary expense. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-idn@ops.ietf.org Mon Jan 15 03:56:59 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29765 for ; Mon, 15 Jan 2001 03:56:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14I5FR-0003qO-00 for idn-data@psg.com; Mon, 15 Jan 2001 00:44:17 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14I5FQ-0003qI-00 for idn@ops.ietf.org; Mon, 15 Jan 2001 00:44:16 -0800 Received: (qmail 4857 invoked by uid 1001); 15 Jan 2001 08:42:30 -0000 Date: 15 Jan 2001 08:42:30 -0000 Message-ID: <20010115084230.18034.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Some comments References: <20010113235701.11623.qmail@cr.yp.to> <200101131408.f0DE8ll29533@malmo.trab.se> <20010113213727.27292.qmail@cr.yp.to> <20010113235701.11623.qmail@cr.yp.to> <5.1.0.4.2.20010114222808.01ec87b0@dcrocker.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk Sorry to bother you with facts, Dave, but Sendmail has done just-send-8 by default for 8-bit non-MIME messages since version 6.57 in 1993. This blatantly violates RFC 1652 and the 7-bit restriction in RFC 821. As for MIME messages, current versions of Sendmail can convert 8-bit to Quoted-Printable, but there's a popular ``8 flag'' that turns this off, again in violation of RFC 1652 and RFC 821. Of course, qmail has always done just-send-8 for all messages. It also deliberately announces 8BITMIME to subvert Sendmail's Quoted-Printable conversion. Yes, this violates RFC 1652, but it's exactly the same as the behavior of many Sendmail installations. (It's what the users want!) Similarly, Exim does just-send-8 for all messages. It announces 8BITMIME if you set the accept_8bitmime option. ---Dan From owner-idn@ops.ietf.org Mon Jan 15 07:32:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02267 for ; Mon, 15 Jan 2001 07:32:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14I8Fy-0005g3-00 for idn-data@psg.com; Mon, 15 Jan 2001 03:57:02 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14I8Fx-0005fx-00 for idn@ops.ietf.org; Mon, 15 Jan 2001 03:57:02 -0800 Received: (qmail 32121 invoked by uid 1001); 15 Jan 2001 11:56:15 -0000 Date: 15 Jan 2001 11:56:15 -0000 Message-ID: <20010115115615.6526.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idn@ops.ietf.org Precedence: bulk > 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? ---Dan From owner-idn@ops.ietf.org Mon Jan 15 11:18:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08813 for ; Mon, 15 Jan 2001 11:18:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IC2q-0008Yo-00 for idn-data@psg.com; Mon, 15 Jan 2001 07:59:44 -0800 Received: from mauve.mrochek.com ([209.55.107.55]) by psg.com with esmtp (Exim 3.16 #1) id 14IC2p-0008Yi-00 for idn@ops.ietf.org; Mon, 15 Jan 2001 07:59:43 -0800 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JYVJG2PF5S0002SJ@mauve.mrochek.com> for idn@ops.ietf.org; Mon, 15 Jan 2001 07:59:36 -0700 (PDT) Date: Mon, 15 Jan 2001 07:38:03 -0700 (PDT) From: ned.freed@innosoft.com Subject: Re: [idn] Some comments In-reply-to: "Your message dated Mon, 15 Jan 2001 02:23:59 -0500 (EST)" To: William Morris Cc: Dave Crocker , idn@ops.ietf.org Message-id: <01JYXGDWR2MQ0002SJ@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.4.2.20010114222808.01ec87b0@dcrocker.songbird.com> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > > MIME was the right answer. "just do 8-bit SMTP" was not. > > The ACE approach is the same paradigm as MIME. > 10 years ago, 7-bit with 1 bit parity network connections were > more common. I dont think that is the case any longer. Actually, while this is perhaps true it is largely irrelevant. The issue 10 years ago wasn't what network connections supported, since IP running over such things did what was necessary to implement an 8-bit path even back then. What was relevant is that a significant amount of deployed messaging software reacted badly to 8-bit data in messages. And although many of the problems with 8-bit data handling were fixed in many software packages around that time, it took many years for the updated versions of that software to actually deploy. And when it did deploy, it was largely for other reasons, such as to address security issues. It seems like a bad idea to assume that another wave of software vulnerabilities will once again spur deployment of revised sofware when we need it... > MIME was not just a solution for 8-bit data, it also solved the > issue of multipart data. And labelling of data and labelling of charsets. Although it sure would have been nice if we'd had a universal charset to specify back then -- most of the problems I see these days have to do with missing or improper labelling, not encoding, and quite a bit of this could have been avoided by having a universal charset. And now that we do have such a thing, we're again having considerable trouble getting meaningful support for it deployed in a timely fashion. This does not bode well for IDN done initially as infrastructure enhancements. > > It is the right way to lay an encoding enhancement on an installed base, > > with the smallest amount of disruption. It permits incremental adoption, > > with immediate benefit to participants in the enhancement, and no > > critical-path changes required of the infrastructure. Changes to the > > infrastructure can then happen later and more liesurely. > I think the end solution should be unicode (utf/ucs/whatever) > ACE is not part of a migration, it is an alternative. Not necessarily. ACE is a first step, and I believe it is a necessary first step. The question of whether or not it is the last step isn't settled at all. But one of the advantages of ACE is that we don't have to make this choice in the short term. > If ACE laid the groundwork for moving to unicode I would > be much more inclined to accept it for the short term. Um, careful with your terms here. I think you meant UTF-8 or UTF-16 or some other charset, not Unicode. ACE does encode the Unicode CCS. > Infrastructure changes will only happen if there is a need for them. Actually, they often don't happen even if there's a need for them. What's hnecessary is for there to be a pressing need that cannot be ignored. And it isn't clear that IDN represents such a need in many quarters, the demand for it in others notwithstanding. > ACE will meet the developers and consumers needs, so changes will > not happen if it is implemented. A very telling statement, if I may say so... and one that argues for ACE being the last step! Ned From owner-idn@ops.ietf.org Mon Jan 15 12:42:48 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11936 for ; Mon, 15 Jan 2001 12:42:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IDEQ-0009ZQ-00 for idn-data@psg.com; Mon, 15 Jan 2001 09:15:46 -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 14IDEQ-0009ZJ-00 for idn@ops.ietf.org; Mon, 15 Jan 2001 09:15:46 -0800 Received: from DCROCKER.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 JAA00868; Mon, 15 Jan 2001 09:15:33 -0800 Message-Id: <5.1.0.4.2.20010115090736.02002bd0@dcrocker.songbird.com> X-Sender: dhc@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.4 (Beta) Date: Mon, 15 Jan 2001 09:11:17 -0800 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: [idn] Some comments Cc: idn@ops.ietf.org In-Reply-To: <20010115084230.18034.qmail@cr.yp.to> References: <20010113235701.11623.qmail@cr.yp.to> <200101131408.f0DE8ll29533@malmo.trab.se> <20010113213727.27292.qmail@cr.yp.to> <20010113235701.11623.qmail@cr.yp.to> <5.1.0.4.2.20010114222808.01ec87b0@dcrocker.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 08:42 AM 1/15/2001 +0000, D. J. Bernstein wrote: >Sorry to bother you with facts, Dave, but Sendmail has done just-send-8 >by default for 8-bit non-MIME messages since version 6.57 in 1993. This >blatantly violates RFC 1652 and the 7-bit restriction in RFC 821. "Just do 8-bit" doesn't and didn't work. Those who forced 8-bit onto the operational framework for all their recipients caused quite a bit of trouble. That was why an ESMTP option was created, so the receiving SMTP server could tell the sending server that 8-bit was supported. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 From owner-idn@ops.ietf.org Mon Jan 15 17:39:28 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16958 for ; Mon, 15 Jan 2001 17:39:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IHyF-000EFF-00 for idn-data@psg.com; Mon, 15 Jan 2001 14:19:23 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14IHyE-000EF9-00 for idn@ops.ietf.org; Mon, 15 Jan 2001 14:19:22 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29359 for ; Mon, 15 Jan 2001 14:13:50 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Mon, 15 Jan 2001 14:17:55 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Nameprep-01 released Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. The new version of the nameprep document can be found at and should appear in the official Internet Drafts directory shortly. This draft represents a consensus opinion of the nameprep design team. We are not necessarily finished, however: we have some possible open issues that we felt were not serious enough to delay releasing the new draft. This draft is reasonably mature and follows the guidelines that we talked about in San Diego. It is significantly different from the -00 draft. Thus, it would be great if, when you comment on it on the mailing list, you put the section number you are discussing in the subject line so that people can follow along more easily. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jan 16 02:38:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06887 for ; Tue, 16 Jan 2001 02:38:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IQA9-000KoV-00 for idn-data@psg.com; Mon, 15 Jan 2001 23:04:13 -0800 Received: from asadal.cs.pusan.ac.kr ([164.125.164.185]) by psg.com with esmtp (Exim 3.16 #1) id 14IQA7-000KoP-00 for idn@ops.ietf.org; Mon, 15 Jan 2001 23:04:11 -0800 Received: from localhost (gimgs@localhost) by asadal.cs.pusan.ac.kr (8.8.8+Sun/8.8.8) with ESMTP id QAA17999; Tue, 16 Jan 2001 16:01:32 +0900 (KST) Date: Tue, 16 Jan 2001 16:01:31 +0900 (KST) From: GIM Gyeongseog-KIM Kyongsok To: John C Klensin cc: idn@ops.ietf.org, GIM Gyeongseog-KIM Kyongsok Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-Reply-To: <3836713798.978794289@P2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk On Sat, 6 Jan 2001, John C Klensin wrote: > But most Han, Kanji, > and Hangul are hopeless for me: there are lots of them, I can't > (in general) tell them apart, and I just don't have the pattern > recognition skills... > Anything I can't recognize well enough to match with a table is > something I can't copy from a business card. ... as i understand it, IDNs in Hangeul, for example, are for people who understand Hangeul, not for non-Hangeul-aware people. if some company's main customers are people using Hangeul, then they can use IDN in Hangeul. if that company also wants to attract people using English, then they should use English domain name too (of course, the contents of web pages must be in English as well). am i missing something here? 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 Tue Jan 16 03:38:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07098 for ; Tue, 16 Jan 2001 03:38:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IRI5-000Lfe-00 for idn-data@psg.com; Tue, 16 Jan 2001 00:16:29 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14IRI4-000LfY-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 00:16:29 -0800 Received: from P2 ("port 1213"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G7800E3BXNE72@a4.jck.com> for idn@ops.ietf.org; Tue, 16 Jan 2001 03:16:27 -0500 (EST) Date: Tue, 16 Jan 2001 03:16:26 -0500 From: John C Klensin Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-reply-to: To: GIM Gyeongseog-KIM Kyongsok Cc: idn@ops.ietf.org Message-id: <362442912.979614986@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Tuesday, 16 January, 2001 16:01 +0900 GIM Gyeongseog-KIM Kyongsok wrote: > On Sat, 6 Jan 2001, John C Klensin wrote: > >> But most Han, Kanji, >> and Hangul are hopeless for me: there are lots of them, I >> can't (in general) tell them apart, and I just don't have the >> pattern recognition skills... > >> Anything I can't recognize well enough to match with a table >> is something I can't copy from a business card. ... > > as i understand it, IDNs in Hangeul, for example, are for > people who understand Hangeul, not for non-Hangeul-aware > people. if some company's main customers are people using > Hangeul, then they can use IDN in Hangeul. if that company > also wants to attract people using English, then they should > use English domain name too (of course, the contents > of web pages must be in English as well). > > am i missing something here? No, except that the DNS supports synchronized changes to coordinated entries very poorly. For both, e.g., web and email addresses, one would normally like http:///... and http:///... to point to the same site. Likewise @ and @ to point to the same mailbox. But, if, e.g., one implements this as (using IPv4 as an example) as . IN A 10.1.2.3 . IN A 10.1.2.3 And then tries to make a change, such as to re-home the host, the two names may, due to differences in usage, take significantly different times to propagagate. And, since there is some history of taking the first matching entry only and ignoring the others, it may make some significant difference whether one lists 3.2.1.10.in-addr.arpa. IN PTR . 3.2.1.10.in-addr.arpa. IN PTR . or 3.2.1.10.in-addr.arpa. IN PTR . 3.2.1.10.in-addr.arpa. IN PTR . trying to do the matching with CNAMEs, e.g., . IN A 10.1.2.3 . IN CNAME . has most of the same synchronization problems, plus all of the usual problems with CNAMEs, including, normally, no appearance of the English name in reverse-mapping records at all. And the other variations (Hangeul-> English -> address and both Hangeul and English names labeling CNAMEs that point to some contrived intermediary which then labels a single A RR) help with some problems and introduce others. And note that several of these (as well as use of two PTR records for the target address in the first, "both use A RRs" model) are, for me, the main argument for ACE-like solutions (or something more radical than embedding this information in Class=IN), which I otherwise dislike intensely. They will certainly "leak" strings representative of the Hangeul into legacy applications. If those strings are in anything but the protocol-element restricted ASCII those applications traditionally expect, we will have trouble, whether the problem is a leading hyphen or an octet with the high-order bit turned on, or an octet whose bit value is zero. Note that this gets worse if there is some coordinated collection of servers with related domain names (fairly common for some arrangements today), if the servers are multihomed (and hence have multiple A RRs for a single FQDN), or if you are supporting not only English and Hangul names, but names that use several other languages (and hence scripts) as well. In looking at "multilingual" names, solutions that work 80% of the time, or cover 80% of the cases, are actually fairly easy. Any of the example scenarios above would "pretty much" work, and synchronized changes may not be very important. I suppose that is why we've had so many organizations spring up with claims of easy and unique solutions to the requirements as they see them. But the DNS is fairly basic infrastructure for users of the Internet, and 80% solutions, or even 99% solutions, or solutions that assume concurrent upgrading everywhere, are almost certainly not good enough. john From owner-idn@ops.ietf.org Tue Jan 16 03:59:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07265 for ; Tue, 16 Jan 2001 03:59:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IRid-000Lw6-00 for idn-data@psg.com; Tue, 16 Jan 2001 00:43:55 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14IRid-000Lw0-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 00:43:55 -0800 Received: from P2 ("port 1255"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTP id <0G7800E3PYX572@a4.jck.com> for idn@ops.ietf.org; Tue, 16 Jan 2001 03:43:54 -0500 (EST) Date: Tue, 16 Jan 2001 03:43:53 -0500 From: John C Klensin Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-reply-to: To: GIM Gyeongseog-KIM Kyongsok Cc: idn@ops.ietf.org Message-id: <364089852.979616633@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Sorry, I left one important case out that deserves comment (probably not the only one, but I'll leave others I've missed to others)... --On Tuesday, 16 January, 2001 16:01 +0900 GIM Gyeongseog-KIM Kyongsok wrote: >... > if some company's main customers are people using Hangeul, > then they can use IDN in Hangeul. if that company also > wants to attract people using English, then they should use > English domain name too (of course, the contents > of web pages must be in English as well). Please also keep in mind that you may, for many years to come, have Hanguel-using customers within sites or environments which have not upgraded their software. Even if the ability to view and enter Hangeul DNS names is an application issue only, it may not be possible for them to upgrade their applications without, e.g., action on the part of a slow-moving ISP or IT department. That may argue strongly that you need an "English" set of domain names for your Hangeul-based web pages (and email servers, etc) as well as for your English-language ones. john From owner-idn@ops.ietf.org Tue Jan 16 04:01:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07322 for ; Tue, 16 Jan 2001 04:01:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IRoE-000Lzr-00 for idn-data@psg.com; Tue, 16 Jan 2001 00:49:42 -0800 Received: from asadal.cs.pusan.ac.kr ([164.125.164.185]) by psg.com with esmtp (Exim 3.16 #1) id 14IRoC-000Lzj-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 00:49:41 -0800 Received: from localhost (gimgs@localhost) by asadal.cs.pusan.ac.kr (8.8.8+Sun/8.8.8) with ESMTP id RAA18359; Tue, 16 Jan 2001 17:47:08 +0900 (KST) Date: Tue, 16 Jan 2001 17:47:08 +0900 (KST) From: GIM Gyeongseog-KIM Kyongsok To: John C Klensin cc: idn@ops.ietf.org Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-Reply-To: <362442912.979614986@P2> 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 Tue, 16 Jan 2001, John C Klensin wrote: > --On Tuesday, 16 January, 2001 16:01 +0900 GIM Gyeongseog-KIM > Kyongsok wrote: > > > On Sat, 6 Jan 2001, John C Klensin wrote: > > thanks for your exmpales. > No, except that the DNS supports synchronized changes to > coordinated entries very poorly. ... > But, if, e.g., one implements this as (using IPv4 as an example) > as > > . IN A 10.1.2.3 > . IN A 10.1.2.3 > > And then tries to make a change, such as to re-home the host, > the two names may, due to differences in usage, take > significantly different times to propagagate. i am somewhat confused here. this situation can happen with ordinary (i.e., non-IDN) domain names. i would like to know whether you claim the above problem is the DNS problem in general or a problem specific with IDNs? > john ±è °æ¼®, ºÎ»ê´ë Á¤º¸ ÄÄÇ»ÅÍ °øÇкÎ; 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 Tue Jan 16 07:42:45 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09177 for ; Tue, 16 Jan 2001 07:42:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IUqQ-0002kk-00 for idn-data@psg.com; Tue, 16 Jan 2001 04:04:10 -0800 Received: from asadal.cs.pusan.ac.kr ([164.125.164.185]) by psg.com with esmtp (Exim 3.16 #1) id 14IUqP-0002ke-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 04:04:09 -0800 Received: from localhost (gimgs@localhost) by asadal.cs.pusan.ac.kr (8.8.8+Sun/8.8.8) with ESMTP id VAA19321 for ; Tue, 16 Jan 2001 21:01:25 +0900 (KST) Date: Tue, 16 Jan 2001 21:01:25 +0900 (KST) From: GIM Gyeongseog-KIM Kyongsok To: idn@ops.ietf.org Subject: [idn] ACE, ACE-UTF-8, UTF-8 In-Reply-To: <20010113213727.27292.qmail@cr.yp.to> 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 > ACE-now-and-forever > ACE-now-UTF-8-later > UTF-8-now-and-forever since there seems to be no consensus as to the popularity of these, can we vote? of course, the populairty should not necessarily be the basis for adoption of one of these within IDN WG. ±è °æ¼®, ºÎ»ê´ë Á¤º¸ ÄÄÇ»ÅÍ °øÇкÎ; 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 Tue Jan 16 07:55:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09543 for ; Tue, 16 Jan 2001 07:55:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IVS5-0007Zt-00 for idn-data@psg.com; Tue, 16 Jan 2001 04:43:05 -0800 Received: from asadal.cs.pusan.ac.kr ([164.125.164.185]) by psg.com with esmtp (Exim 3.16 #1) id 14IVS4-0007YB-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 04:43:04 -0800 Received: from localhost (gimgs@localhost) by asadal.cs.pusan.ac.kr (8.8.8+Sun/8.8.8) with ESMTP id VAA19724; Tue, 16 Jan 2001 21:39:24 +0900 (KST) Date: Tue, 16 Jan 2001 21:39:24 +0900 (KST) From: GIM Gyeongseog-KIM Kyongsok To: John C Klensin cc: idn@ops.ietf.org Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-Reply-To: <364089852.979616633@P2> 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 Tue, 16 Jan 2001, John C Klensin wrote: > Please also keep in mind that you may, for many years to come, > have Hanguel-using customers within sites or environments which > have not upgraded their software. ... > That may argue strongly that you need an "English" set of domain > names for your Hangeul-based web pages (and email servers, etc) > as well as for your English-language ones. > > john agreed. ±è °æ¼®, ºÎ»ê´ë Á¤º¸ ÄÄÇ»ÅÍ °øÇкÎ; 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 Tue Jan 16 07:56:16 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09580 for ; Tue, 16 Jan 2001 07:56:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IVKn-0006Tw-00 for idn-data@psg.com; Tue, 16 Jan 2001 04:35:33 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14IVKm-0006Ti-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 04:35:33 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 9DAF3FFC05; Tue, 16 Jan 2001 20:35:26 +0800 (SGT) Message-ID: <054401c07fb8$992bfa00$8e00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "GIM Gyeongseog-KIM Kyongsok" , References: Subject: Re: [idn] ACE, ACE-UTF-8, UTF-8 Date: Tue, 16 Jan 2001 20:33:58 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 This is a good idea but not in this sense. At the last San Diego meeting, there is a strawpoll on the Protocol Recommendation on "ACE on Application now but do not reject the possibility of longer term solution in future". It is important to note that "longer-term solution" does not imply it is "UTF-8" or any solution in particular. It is only a strawpoll so a consensus on the WG (ie. this mailing list) is still needed. Comments please. -James Seng ----- Original Message ----- From: "GIM Gyeongseog-KIM Kyongsok" To: Sent: Tuesday, January 16, 2001 8:01 PM Subject: [idn] ACE, ACE-UTF-8, UTF-8 > > > ACE-now-and-forever > > ACE-now-UTF-8-later > > UTF-8-now-and-forever > > since there seems to be no consensus as to the popularity of these, > can we vote? > of course, the populairty should not necessarily be the basis > for adoption of one of these within IDN WG. > > > ±è °æ¼®, ºÎ»ê´ë Á¤º¸ ÄÄÇ»ÅÍ °øÇкÎ; > 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 Tue Jan 16 08: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 IAA10387 for ; Tue, 16 Jan 2001 08:22:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IVpT-000AsQ-00 for idn-data@psg.com; Tue, 16 Jan 2001 05:07:15 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14IVpS-000AsK-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 05:07:14 -0800 Received: from tat.jck.com ("port 1061"@[209.187.148.218]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G7900E6EB3V72@a4.jck.com> for idn@ops.ietf.org; Tue, 16 Jan 2001 08:07:12 -0500 (EST) Date: Tue, 16 Jan 2001 08:07:07 -0500 From: John C Klensin Subject: Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) In-reply-to: To: GIM Gyeongseog-KIM Kyongsok Cc: idn@ops.ietf.org Message-id: <379883732.979632427@tat.jck.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Tuesday, January 16, 2001 5:47 PM +0900 GIM Gyeongseog-KIM Kyongsok wrote: >> And then tries to make a change, such as to re-home the host, >> the two names may, due to differences in usage, take >> significantly different times to propagagate. > > i am somewhat confused here. this situation can happen > with ordinary (i.e., non-IDN) domain names. > i would like to know whether you claim the above problem is > the DNS problem in general or a problem specific with IDNs? The widespread introduction of IDNs is likely to put considerable multipliers on these problems. We have learned to avoid or work around them at relatively small scale, but they may not be acceptable at larger scale. As a single, trivial, example, most web sites today that utilize many names pointing to the site typically list only one name in the reverse-mapping. In an IDN context, there would be considerable (consideraby more) incentive to try to reverse-map to both "English" and "national" names. Note, for example, that, for routers and similar resources, IA4 names are required by an ITU recommendation that many ISPs feel obligated to honor and that integrity of reverse mappings for these devices is often considered quite important. john From owner-idn@ops.ietf.org Tue Jan 16 10:46:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14535 for ; Tue, 16 Jan 2001 10:46:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IXzl-0001TG-00 for idn-data@psg.com; Tue, 16 Jan 2001 07:26:01 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14IXys-0001De-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 07:25:06 -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 PAA28428; Tue, 16 Jan 2001 15:20:35 GMT From: "Brian W. Spolarich" To: "John C Klensin" , "GIM Gyeongseog-KIM Kyongsok" Cc: Subject: RE: [idn] The Business Card problem (was: Re: An experiment with UTF-8 domain names) Date: Tue, 16 Jan 2001 10:24:09 -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: <379883732.979632427@tat.jck.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 | In an IDN context, there would be considerable (consideraby more) | incentive to try to reverse-map to both "English" and "national" | names. Note, for example, that, for routers and similar resources, | IA4 names are required by an ITU recommendation that many ISPs feel | obligated to honor and that integrity of reverse mappings for | these devices is often considered quite important. This is a good point, and perhaps a justification for something like IPTR (which I've initially thought of as perhaps something that was more of an interest to CJK speakers). ISPs definitely rely on the IPV4 address to name mappings to determine information about the network, including device identity and function and administrative domain. Usually there's a geographical and functional heirarchy expressed by the name components (I know this was the case on the ANS and UUNET backbones). This is probably another example of functional 'overloading' in the DNS, and perhaps a better way to do this is via SNMP. This would imply that as a consequence of IDN-related activities the device management-oriented WGs may need to consider defining MIB extensions to assist network operators in discovering needed information about the network. Easier said than done, I'm sure. -bws From owner-idn@ops.ietf.org Tue Jan 16 11:52:50 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16211 for ; Tue, 16 Jan 2001 11:52:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IZ5f-0001eG-00 for idn-data@psg.com; Tue, 16 Jan 2001 08:36:11 -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 14IZ5e-0001bY-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 08:36:10 -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 f0GGU0D78142 for ; Tue, 16 Jan 2001 17:30:00 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Jan 2001 17:35:13 +0100 Message-ID: From: Karlsson Kent - keka To: "'Paul Hoffman / IMC'" , "'Marc Blanchet'" Cc: idn@ops.ietf.org Subject: RE: [idn] Nameprep-01 released Date: Tue, 16 Jan 2001 17:32:53 +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 > -----Original Message----- > From: Paul Hoffman / IMC [mailto:phoffman@imc.org] ... > Greetings again. The new version of the nameprep document can be > found at The mapping list at the end is nearly unreviewable, since it does not contain the character names (as comments), just the codes. Compare Unicode tables, which have character names as comments (at least). I don't think it is each revewer's responsability to produce name comments (or whatever) to be able to review the document. The "prohibited character[s] list", list code points, many of which are *not* characters, but are specifically "not-a-character"s, or are reserved for UTF-16 ("surrogates"; which are not characters either). The "unassigned character[s] list" is quite obviously an "(as yet) unassigned code points list" (which is hard to review since no character names can be made available). It also uses 6 hexadecimal digits for the BMP range, which is (will not) be an approved notation according to Unicode and 10646. Kind regards /kent k From owner-idn@ops.ietf.org Tue Jan 16 12:22:27 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16937 for ; Tue, 16 Jan 2001 12:22:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IZTR-000AcY-00 for idn-data@psg.com; Tue, 16 Jan 2001 09:00:45 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14IZTQ-000Abn-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 09:00:45 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12860 for ; Tue, 16 Jan 2001 08:55:10 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Tue, 16 Jan 2001 08:59:18 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: RE: [idn] Nameprep-01 released Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 5:32 PM +0100 1/16/01, Karlsson Kent - keka wrote: >The mapping list at the end is nearly unreviewable, since it does >not contain the character names (as comments), just the codes. >Compare Unicode tables, which have character names as comments >(at least). You are quite correct. In fact, for the mappings from section 3.1 and 3.2, I had to take out the character names. We chose to do this because, with character names, many lines ran over 80 columns and caused wrapping problems for some readers. > I don't think it is each revewer's responsability >to produce name comments (or whatever) to be able to review the >document. This is a fair criticism. I'll generate the tables with the names in the columns separately from the draft itself, and ask Marc put them on the WG's web site. Look for them later today or tomorrow. >The "prohibited character[s] list", list code points, many of >which are *not* characters, but are specifically "not-a-character"s, >or are reserved for UTF-16 ("surrogates"; which are not characters >either). Yes: that is what sections 5.4, 5.5, and 5.6 describe. Are you saying that we should rename the appendix to "prohibited codepoints", or is there some other issue you are pointing towards? >The "unassigned character[s] list" is quite obviously an >"(as yet) unassigned code points list" (which is hard to review >since no character names can be made available). It also uses >6 hexadecimal digits for the BMP range, which is (will not) be >an approved notation according to Unicode and 10646. Good catch; I'll fix that in the -02 draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jan 16 12:58:19 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17640 for ; Tue, 16 Jan 2001 12:58:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ia4K-000PuX-00 for idn-data@psg.com; Tue, 16 Jan 2001 09:38:52 -0800 Received: from [216.168.233.95] (helo=heron.verisign.com) by psg.com with esmtp (Exim 3.16 #1) id 14Ia4J-000PP1-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 09:38:51 -0800 Received: from REGDOM-EX01.prod.netsol.com (rdex01-node2.prod.netsol.com [10.131.4.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA23715; Tue, 16 Jan 2001 12:27:55 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 12:33:21 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'Paul Hoffman / IMC'" , idn@ops.ietf.org Subject: RE: [idn] Nameprep-01 released Date: Tue, 16 Jan 2001 12:33:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idn@ops.ietf.org Precedence: bulk Paul, > Good catch; I'll fix that in the -02 draft. I found two very small editorial issues: Section 3.2 uses both "Normalize(Fold(x))" and "Normalize(CaseFold(x))". Either "Fold" or "CaseFold" should be used consistently. "Normalization" is misspelled as "Normalizaiton" in the header for section 4. and a question: section 5 says that "If a DNS server receives a request containing a prohibited character, then the DNS server MUST NOT resolve that name". Does that mean that the server should ignore the request or that an error response should be returned? It may be more useful to specify how a server MUST deal with such a request, such as by returning a "not implemented" or "query refused" error response. From owner-idn@ops.ietf.org Tue Jan 16 21:26:48 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25258 for ; Tue, 16 Jan 2001 21:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ihoo-000PSR-00 for idn-data@psg.com; Tue, 16 Jan 2001 17:55:22 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14Ihon-000PQQ-00 for idn@ops.ietf.org; Tue, 16 Jan 2001 17:55:21 -0800 Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 1186FFFC09; Wed, 17 Jan 2001 09:55:16 +0800 (SGT) Message-ID: <077b01c08028$545a38e0$8e00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Hollenbeck, Scott" , "'Paul Hoffman / IMC'" , References: Subject: Re: [idn] Nameprep-01 released Date: Wed, 17 Jan 2001 09:53:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Stupid question: Why is this paragraph, related to Protocol, even in Nameprep-01? -James Seng ----- Original Message ----- From: "Hollenbeck, Scott" To: "'Paul Hoffman / IMC'" ; Sent: Wednesday, January 17, 2001 1:33 AM Subject: RE: [idn] Nameprep-01 released > Paul, > > > Good catch; I'll fix that in the -02 draft. > > I found two very small editorial issues: > > Section 3.2 uses both "Normalize(Fold(x))" and "Normalize(CaseFold(x))". > Either "Fold" or "CaseFold" should be used consistently. > > "Normalization" is misspelled as "Normalizaiton" in the header for section > 4. > > and a question: section 5 says that "If a DNS server receives a request > containing a prohibited character, then the DNS server MUST NOT resolve that > name". Does that mean that the server should ignore the request or that an > error response should be returned? It may be more useful to specify how a > server MUST deal with such a request, such as by returning a "not > implemented" or "query refused" error response. > > > From owner-idn@ops.ietf.org Wed Jan 17 08:21:40 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16900 for ; Wed, 17 Jan 2001 08:21:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IsB9-000CBZ-00 for idn-data@psg.com; Wed, 17 Jan 2001 04:59:07 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14IsB8-000CBS-00 for idn@ops.ietf.org; Wed, 17 Jan 2001 04:59:06 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16279; Wed, 17 Jan 2001 07:59:04 -0500 (EST) Message-Id: <200101171259.HAA16279@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-01.txt Date: Wed, 17 Jan 2001 07:59:03 -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 : Preparation of Internationalized Host Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-01.txt Pages : Date : 16-Jan-01 This document describes how to prepare internationalized host names for for use in the DNS. The steps include: - mapping characters to other characters, such as to change their case - normalizing the characters - excluding characters that are prohibited from appearing in internationalized host names A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-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-nameprep-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-nameprep-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: <20010116125706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-nameprep-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-nameprep-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010116125706.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Wed Jan 17 11:01:41 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20795 for ; Wed, 17 Jan 2001 11:01:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Iufv-000Ep0-00 for idn-data@psg.com; Wed, 17 Jan 2001 07:39:03 -0800 Date: Wed, 17 Jan 2001 05:27:06 -0800 To: "Edmon" , From: "David R. Conrad" Subject: Re: [idn] who uses BIND as a base for their internationalized DNS Message-Id: package? Sender: owner-idn@ops.ietf.org Precedence: bulk Edmon, Thanks. For clarification (sent my original question from the wrong email address), my question about who was using BIND was to find out who ISC should be notifying when a new release is being announced so folks could update their implementations accordingly (trying to get folks to keep their BIND derivatives up to date). So far, I've gotten: i-DNS Worldnames Neteka/OpenIDN Anybody else? Rgds, -drc At 11:50 AM 1/13/2001 -0500, Edmon wrote: >Hi David, > >If you go to www.OpenIDN.org, you will see that the Neteka NeDNS version on >the site is also BIND based, though we also have other versions that are >not. ;-) > >Edmon > > >----- Original Message ----- >From: "David R. Conrad" >To: >Sent: Friday, January 12, 2001 9:27 PM >Subject: [idn] who uses BIND as a base for their internationalized DNS >package? > > > > I know the following do: > > > > i-DNS > > Worldnames > > > > Who else? > > > > Tnx, > > -drc > > > > > > From owner-idn@ops.ietf.org Thu Jan 18 08:37:58 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23343 for ; Thu, 18 Jan 2001 08:37:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14JEnz-000KrH-00 for idn-data@psg.com; Thu, 18 Jan 2001 05:08:43 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14JEny-000KrB-00 for idn@ops.ietf.org; Thu, 18 Jan 2001 05:08:42 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22910; Thu, 18 Jan 2001 08:08:40 -0500 (EST) Message-Id: <200101181308.IAA22910@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-02.txt Date: Thu, 18 Jan 2001 08:08:39 -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 : Preparation of Internationalized Host Names Author(s) : P. Hoffman, M. Blanchet Filename : draft-ietf-idn-nameprep-02.txt Pages : Date : 17-Jan-01 This document describes how to prepare internationalized host names for for use in the DNS. The steps include: - mapping characters to other characters, such as to change their case - normalizing the characters - excluding characters that are prohibited from appearing in internationalized host names A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-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-nameprep-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-nameprep-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: <20010118081117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-nameprep-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-nameprep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010118081117.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu Jan 18 11:33:52 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27935 for ; Thu, 18 Jan 2001 11:33:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14JHjf-000PBY-00 for idn-data@psg.com; Thu, 18 Jan 2001 08:16:27 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14JHjf-000PBS-00 for idn@ops.ietf.org; Thu, 18 Jan 2001 08:16:27 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19700 for ; Thu, 18 Jan 2001 08:10:42 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Thu, 18 Jan 2001 08:14:43 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] nameprep-02 is out; has important fixes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. Thanks for the early comments on nameprep-01; we have incorporated them into nameprep-02, which was just released. For those of you carefully looking at the characters in Appendixes E and F and wanting to see the character names, please see: There was a pretty serious bug in Appendix F in nameprep-01: we accidentally included U+002D (hyphen) in the prohibited list. That has been fixed in -02. If anyone is creating test vectors for nameprep, please get in touch with me. I would like to have publicly available lists of names that should pass nameprep, and names that shouldn't. Both lists should many edge cases. For example, the list of names that should pass should have examples of names that pass unmodified, names that pass modified due to each different type of mapping, names that are modified only by mapping, names that are modified in the mapping step and modifed again in the normalization step, and so on. We also need tests for names that include unassigned characters so that people who are creating client software and authoritative name server software can be sure that they get different results. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jan 23 17:22:59 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25525 for ; Tue, 23 Jan 2001 17:22:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LBAr-0005Mp-00 for idn-data@psg.com; Tue, 23 Jan 2001 13:40:21 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14LBAp-0005MN-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 13:40:20 -0800 Received: from jamessonyvaio (unknown [212.45.39.163]) by mail.i-dns.net (Postfix) with SMTP id 581B7FFC01 for ; Wed, 24 Jan 2001 05:40:09 +0800 (SGT) Message-ID: <032c01c08584$e02803f0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> Subject: Re: [idn] San Diego Meeting Notes Date: Wed, 24 Jan 2001 05:38:48 +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 Dear all, I would like to re-emphasis a few 'consensus' in the meeting in San Diego. a) Requirements I-D to move to Last Call after last minor edition. b) Strawpoll agrees with Protocol Design Team recommendation to focus on "ACE on Application" now but do not rejecting a longer term solution in future. c) Strawpoll agrees that the Nameprep Design Team is working in the right direction. (See Nameprep-02) If you have any objection (I know a few of you do), please raise them now. If there is no major objection, then the next step would include 1. Zita will do the Requirements -04 and we will move to Last Call. 2. Protocol Design Team (or someone) should start working on writing an I-D for the IDN Protocol. As it stands now, IDNA seem the closest we have. 3. An ACE Design Team may be form to investigate what is the correct ACE to use for (2). In additional, I would also like to propose to update the Goals and Milestone section of the WG Charter to reflect our progress more accurately. Your comments would be appreciated. -James Seng From owner-idn@ops.ietf.org Tue Jan 23 17:48:28 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25806 for ; Tue, 23 Jan 2001 17:48:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LBy4-0008CQ-00 for idn-data@psg.com; Tue, 23 Jan 2001 14:31:12 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14LBy3-0008CF-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 14:31:12 -0800 Received: from jamessonyvaio (unknown [212.45.39.163]) by mail.i-dns.net (Postfix) with SMTP id 9E469FFC01; Wed, 24 Jan 2001 06:30:57 +0800 (SGT) Message-ID: <047101c0858b$f951cd50$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Sung Jae Shim" , References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> <001601c0858b$af7b0fc0$2d24ee84@fdu.edu> Subject: Re: [idn] San Diego Meeting Notes Date: Wed, 24 Jan 2001 06:29:36 +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 apologise. Yes, Shim is right. The relevant portion of the minutes as follows. -James Seng --- CUT HERE --- DL: is the consensus of the working group to be focusing on an application area approach. Should we stop looking at infrastructure approaches. HA: this does not mean the infrastructure need replacing. just that this WG is not the one to do it. ----- Original Message ----- From: "Sung Jae Shim" To: "James Seng/Personal" ; Sent: Wednesday, January 24, 2001 6:27 AM Subject: Re: [idn] San Diego Meeting Notes > > > > b) Strawpoll agrees with Protocol Design Team recommendation to focus > > on "ACE on Application" now but do not rejecting a longer term > > solution in future. > > I don't recall that straw poll agrees to focus on "ACE on Application". But > I recall that straw poll agrees to focus on "Application Area Approach." > Please take a look at the minutes. > > Sung Shim > > From owner-idn@ops.ietf.org Tue Jan 23 17:55:00 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25863 for ; Tue, 23 Jan 2001 17:55:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LBuz-000811-00 for idn-data@psg.com; Tue, 23 Jan 2001 14:28:01 -0800 Received: from mailbox.fdu.edu ([132.238.12.1]) by psg.com with esmtp (Exim 3.16 #1) id 14LBuy-00080v-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 14:28:01 -0800 Received: from Spooler by mailbox.fdu.edu (Mercury/32 v3.21c) ID MO007712; 23 Jan 01 17:28:00 -0500 Received: from spooler by mailbox.fdu.edu (Mercury/32 v3.21c); 23 Jan 01 17:27:47 -0500 Received: from FDU (132.238.36.45) by mailbox.fdu.edu (Mercury/32 v3.21c) ID MG007711; 23 Jan 01 17:27:37 -0500 Message-ID: <001601c0858b$af7b0fc0$2d24ee84@fdu.edu> From: "Sung Jae Shim" To: "James Seng/Personal" , References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> Subject: Re: [idn] San Diego Meeting Notes Date: Tue, 23 Jan 2001 17:27:33 -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.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > b) Strawpoll agrees with Protocol Design Team recommendation to focus > on "ACE on Application" now but do not rejecting a longer term > solution in future. I don't recall that straw poll agrees to focus on "ACE on Application". But I recall that straw poll agrees to focus on "Application Area Approach." Please take a look at the minutes. Sung Shim From owner-idn@ops.ietf.org Tue Jan 23 19:01:34 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26649 for ; Tue, 23 Jan 2001 19:01:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LCwP-000C9o-00 for idn-data@psg.com; Tue, 23 Jan 2001 15:33:33 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14LCwO-000C8E-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 15:33:32 -0800 Received: (qmail 32280 invoked by uid 1001); 23 Jan 2001 23:32:43 -0000 Date: 23 Jan 2001 23:32:43 -0000 Message-ID: <20010123233243.17988.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] San Diego Meeting Notes References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk I object to ACE because the initial switch involves massive unnecessary costs. The costs are discussed in http://cr.yp.to/proto/idn.html. See below for a transliterated copy of idn.html. I also object to the idea of specifying a short-term plan without a long-term plan. How can we rationally evaluate the costs of ACE if we don't also evaluate the likely costs of a future ACE-to-UTF-8 switch? I also object to the characterization of ACE as an ``application-only'' solution. Is an MTA an ``application''? How about a DNS server? Unless we can settle on a clear definition of ``application,'' we shouldn't even be using the word, let alone making decisions that involve it. As for nameprep: When are we going to see some working software? I have a bunch of examples that I'd like to try; it's difficult to evaluate nameprep without software. ---Dan D. J. Bernstein Protocols Internationalized domain names We want to let people use domain names like abg.com (``alpha beta gamma dot com''). They should be able to register the name, set up computers under the name, connect to those computers by name, set up web pages under the name, set up links to those web pages, browse those web pages given the name or a link, send email from an address under the name, receive email at that address, etc. The big question is how these domain names will be encoded. This web page describes two proposals, and tallies the costs of each proposal for UNIX. (The costs for Windows are of similar types but generally smaller; Microsoft has supported Unicode for years.) Important note: An uppercase ABG.com (``Alpha Beta Gamma dot com'') is guaranteed to cause confusion: when the uppercase Alpha is printed properly, it looks just like an uppercase A. Some other strings are also guaranteed to cause confusion. There's a complicated definition of good names among all Unicode strings. Good names won't be confused with each other. Registrars won't allow registration of bad names. Base costs Users need to be able to see common Unicode characters. The necessary fonts are available, as is a version of xterm that displays the characters given UTF-8 input. These are all included with the current version of XFree86, so they are being deployed as part of regular OS upgrades. Users will sometimes need to type strange addresses from business cards. Finding an unusual character in a huge font display is difficult, so I expect business cards to provide more information, such as Unicode numbers in small type. Keyboard interfaces will have to improve to accept this information. (The ISO standard method is Shift-Ctrl-222E for character 222E.) Costs of ACE with slow nameprep What it means. Domain names are encoded as 7-bit strings in the following contexts: * DNS registration forms. * DNS queries and responses. * Mail message header fields: From, To, Received, etc. * POP USER commands. (POP usernames typically include domain names.) * Various parts of IMAP. * HTTP fields: Host, etc. * URLs. Domain names are encoded as UTF-8 strings in the following contexts: * The argument to gethostbyname. * h_name and h_aliases. * /etc/hosts and many other network configuration files. * /etc/named.boot and zone files. * Command lines for ndc, nsupdate, etc. * BIND log files. * /service/dnscache/root/servers. * dnscache log files. * /service/tinydns/root/data. * Command lines for add-host, add-ns, etc. * tinydns log files. * /etc/resolv.conf, $LOCALDOMAIN, etc. * Command lines for dig, host, etc. * Output of dig, host, etc. * Command lines for telnet, ssh, etc. * /etc/hosts.allow, .ssh/known_hosts, etc. * httpd.conf. * /public/file. * More HTTP server configuration files. * lynx.cfg. * Command line for lynx. * .fetchmailrc. * Pine interface: message displays, command line, etc. * Mutt interface: message displays, command line, etc. * More mail clients. A domain name encoded as a UTF-8 string is permitted to be a bad name if it looks just like a good name. It is interpreted as that good name. Making it work. BIND, tinydns, and other DNS servers need to be upgraded. Domain names in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. 7-bit domain names in queries need to be converted to UTF-8 for logs. The gethostbyname DNS client library needs to be upgraded. The input domain name needs to be converted from possibly bad to good, and from UTF-8 to 7-bit, before it is sent as a DNS query. The output domain names in h_name and h_aliases need to be converted from 7-bit to UTF-8. The tcpclient networking tool needs to be upgraded. The input domain name needs to be converted from possibly bad to good, and from UTF-8 to 7-bit, before it is sent as a DNS query. telnetd, sshd, tcpserver, etc. need to be upgraded. Domain names in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. 7-bit domain names need to be converted to UTF-8 for logs. Many low-level networking tools need to be upgraded. Domain names in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. 7-bit domain names need to be converted to UTF-8 for logs. Pine, Mutt, and other text-mode mail clients need to be upgraded. 7-bit domain names need to be converted to UTF-8 when messages are displayed. UTF-8 needs to be spaced properly. Addresses in configuration files (for example, ``flag messages to djb@cr.yp.to'') need to be converted from possibly bad to good, and from UTF-8 to 7-bit. fetchmail and other POP clients need to be upgraded. Domain names embedded in POP usernames need to be converted from possibly bad to good, and from UTF-8 to 7-bit. Netscape Mail and other graphical mail clients need to be upgraded. 7-bit domain names need to be displayed as Unicode glyphs. Addresses in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. Apache, publicfile, and other HTTP servers need to be upgraded. Domain names in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. 7-bit domain names need to be converted to UTF-8 for logs. Lynx and other text-mode browsers need to be upgraded. Domain names in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. 7-bit domain names need to be converted to UTF-8 for internationalized URL displays. Netscape and other graphical browsers need to be upgraded. 7-bit domain names need to be displayed as Unicode glyphs. Domain names in configuration files need to be converted from possibly bad to good, and from UTF-8 to 7-bit. Costs of UTF-8 with fast nameprep What it means. Domain names are encoded as UTF-8 strings in all of the above contexts. Bad names are not allowed to appear. (Exception: Users can send bad names in DNS registration forms; the registrar will send back a rejection notice showing the closest good name.) Making it work. Sendmail needs to be upgraded. Current versions discard bytes \200 through \237 in mail message headers. The gethostbyname DNS client library needs to be upgraded. Many current installations, in violation of RFC 2181, reject DNS answers that contain unusual characters. (However, some versions will work correctly with options allow_special all or options no-check-names in /etc/resolv.conf.) Pine, Mutt, and other text-mode mail clients need to be upgraded. UTF-8 needs to be spaced properly. There's one report that an obsolete version of the Netscape mailer crashes under Solaris when it reads UTF-8 messages. I need verifiable details. Are there more programs that need to be upgraded? Let me know. From owner-idn@ops.ietf.org Tue Jan 23 20:53:14 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27958 for ; Tue, 23 Jan 2001 20:53:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LEu8-000JWB-00 for idn-data@psg.com; Tue, 23 Jan 2001 17:39:20 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14LEu7-000JVo-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 17:39:19 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17800; Tue, 23 Jan 2001 17:33:07 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <032c01c08584$e02803f0$06272dd4@jamessonyvaio> References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> Date: Tue, 23 Jan 2001 17:19:42 -0800 To: "James Seng/Personal" , From: Paul Hoffman / IMC Subject: Re: [idn] San Diego Meeting Notes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 5:38 AM +0800 1/24/01, James Seng/Personal wrote: >2. Protocol Design Team (or someone) should start working on writing > an I-D for the IDN Protocol. As it stands now, IDNA seem the closest > we have. The protocol design team report that was sent to the mailing list by your co-chair last week said: "Because the proposed IDN solution is for the presentation-layer of applications, the protocol design team proposes that the IDN WG allow the Applications Area to finish the work on the specific protocol proposal. The people in the Applications Area are most familiar with the problems associated with changing the presentation layer." The protocol design team did not volunteer to do the work. The Applications Area Directors have said they are willing to take the work on in the Apps area. Obviously, anyone from this WG would be invited to help. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jan 23 20:56:10 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27982 for ; Tue, 23 Jan 2001 20:56:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LEuE-000JYE-00 for idn-data@psg.com; Tue, 23 Jan 2001 17:39:26 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14LEu7-000JVg-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 17:39:19 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17803 for ; Tue, 23 Jan 2001 17:33:08 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010123233243.17988.qmail@cr.yp.to> References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> <20010123233243.17988.qmail@cr.yp.to> Date: Tue, 23 Jan 2001 17:39:04 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] San Diego Meeting Notes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:32 PM +0000 1/23/01, D. J. Bernstein wrote: >I object to ACE because the initial switch involves massive unnecessary >costs. The costs are discussed in http://cr.yp.to/proto/idn.html. See >below for a transliterated copy of idn.html. That document appears to detail the costs (but does not quantify "massive") for upgrading applications to any form of IDN. It does not differentiate the costs between upgrading to an ACE or to UTF8. It does not say why going to an ACE is "unnecessary". The fact that some programs can today display UTF-8 but cannot check nameprepped UTF8 shows that all programs are going to need to be updated for input of DNS names. If you believe that the cost of going to ACE is massive but going to UTF8 is not, that implies that the UTF8-to-ACE conversion cost is massively larger than the cost of doing nameprep. It is likely that the opposite is true: writing the normalization step in nameprep is probably much, much harder than coding an ACE, particularly LACE. >I also object to the idea of specifying a short-term plan without a >long-term plan. How can we rationally evaluate the costs of ACE if we >don't also evaluate the likely costs of a future ACE-to-UTF-8 switch? Wouldn't those costs be constant regardless of what the long-term plan is? Put another way, which two of the long-term plans proposed have different ACE-to-long-term costs? >I also object to the characterization of ACE as an ``application-only'' >solution. Good point. It might have more carefully worded as the design team did: it is for the presentation layer of applications. > Is an MTA an ``application''? How about a DNS server? If it has a presentation layer, it will be affected by IDNA; if not, no. >As for nameprep: When are we going to see some working software? Many months ago. > I have >a bunch of examples that I'd like to try; it's difficult to evaluate >nameprep without software. Some testbeds have already been announced on this list. Mine (which is written in Perl and the source code is available) is at . Please feel free to use the web form or, better yet, grab the source and run it locally. By all means report any bugs you find to me (you don't need to send them to the whole mailing list). Open source implemenatations in C or C++ would probably be more appreciated by the folks on this list than my non-optimized Perl hack^H^H^H^Hscript. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Tue Jan 23 21:58:43 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29538 for ; Tue, 23 Jan 2001 21:58:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LFey-000MJk-00 for idn-data@psg.com; Tue, 23 Jan 2001 18:27:44 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14LFew-000MJe-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 18:27: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 VAA03438; Tue, 23 Jan 2001 21:27:36 -0500 (EST) Message-Id: <200101240227.VAA03438@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] San Diego Meeting Notes In-reply-to: Your message of "23 Jan 2001 23:32:43 GMT." <20010123233243.17988.qmail@cr.yp.to> Date: Tue, 23 Jan 2001 21:27:36 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk Dan, your analysis assumes that most sites are or will be using UTF-8 locally. this seems like quite a stretch as it is very different from current reality. IMHO it would be much more realistic to assume that folks who are currently using some other non-ASCII charset in their locale will continue to do so for quite some time - each will convert to UTF-8 in his/her own timeframe (if ever). if you make that assumption, the costs of upgrading those applications to convert between local representation and either ACE or UTF-8 are quite similar. ACE wins not because it costs significantly less for conversion but because it allows each site to upgrade in its own timeframe, thus lowering the barrier to adoption of IDNs. of course, nobody can predict the future with 100% accuracy, and reasonable people will disagree on how things will unfold. but for this very reason it makes sense to choose a IDN deployment strategy that seems likely to work in a variety of future scenarios - i.e. whether or not people convert to UTF-8. ACE seems to have a lower risk of failure. Keith From owner-idn@ops.ietf.org Tue Jan 23 21:59:00 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29557 for ; Tue, 23 Jan 2001 21:59:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LFhw-000MX6-00 for idn-data@psg.com; Tue, 23 Jan 2001 18:30:48 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14LFhv-000MWt-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 18:30:47 -0800 Received: (qmail 16998 invoked by uid 1001); 24 Jan 2001 02:29:59 -0000 Date: 24 Jan 2001 02:29:59 -0000 Message-ID: <20010124022959.14817.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] San Diego Meeting Notes References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> <20010123233243.17988.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 Paul Hoffman / IMC writes: > That document appears to detail the costs (but does not quantify > "massive") for upgrading applications to any form of IDN. It does not > differentiate the costs between upgrading to an ACE or to UTF8. False. The web page describes in detail one ACE proposal and its costs, and then one UTF-8 proposal and its costs. Many programs need updates and redeployment only for ACE. > all programs are going to need to be updated False. The UTF-8 proposal analyzed on my web page involves redeployment of only a few programs. > If it has a presentation layer Please give a clear definition of ``presentation layer,'' and explain which of the following programs have ``presentation layers'': named; dents; tinydns; tcpclient; telnetd; sshd; tcpd; tcpserver; fetchmail; apache; boa; fhttpd; gn; mathopd; publicfile; roxen; thttpd; webfs; wn. Those are some of the programs that have to be upgraded and redeployed for ACE. > http://www.imc.org/nameprep Is that (1) up to date and (2) normative? ---Dan From owner-idn@ops.ietf.org Tue Jan 23 22:18:18 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29740 for ; Tue, 23 Jan 2001 22:18:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LGBB-000OLV-00 for idn-data@psg.com; Tue, 23 Jan 2001 19:01:01 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14LGBA-000OLP-00 for idn@ops.ietf.org; Tue, 23 Jan 2001 19:01:00 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19833 for ; Tue, 23 Jan 2001 18:54:48 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010124022959.14817.qmail@cr.yp.to> References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> <20010123233243.17988.qmail@cr.yp.to> <20010124022959.14817.qmail@cr.yp.to> Date: Tue, 23 Jan 2001 19:00:56 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] San Diego Meeting Notes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 2:29 AM +0000 1/24/01, D. J. Bernstein wrote: > > http://www.imc.org/nameprep > >Is that (1) up to date and (2) normative? (1) Yes. (2) What do you mean? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Wed Jan 24 03:44:43 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16906 for ; Wed, 24 Jan 2001 03:44:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LL17-000HAu-00 for idn-data@psg.com; Wed, 24 Jan 2001 00:10:57 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14LL16-000HAo-00 for idn@ops.ietf.org; Wed, 24 Jan 2001 00:10:56 -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 f0O8Aj426206; Wed, 24 Jan 2001 09:10:50 +0100 (MET) Received: from valinor by valinor.malmo.trab.se (8.10.1/TRM-1-KLIENT); Wed, 24 Jan 2001 09:10:44 +0100 (MET) (MET) Message-Id: <200101240810.f0O8AiX20319@valinor.malmo.trab.se> Date: Wed, 24 Jan 2001 09:10:44 +0100 (MET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [idn] San Diego Meeting Notes To: idn@ops.ietf.org, James@Seng.cc MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /PEMl5WYSmPCGuviTWBVHw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk >b) Strawpoll agrees with Protocol Design Team recommendation to focus > on "ACE on Application" now but do not rejecting a longer term > solution in future. > From the discussions on this list I do not think we have agreed this is the right way. One major problem with "ACE in application" is that it requires a name to be mangled into the form needed to compare two names, in the application and it requires names to be store in DNS in the same way. With mangling I mean things like forcing upper case to lower case. Though you could fix this by allowing the DNS to return in responses normlaised but unmangled names. This would allow names to be displayed using the preferred form. Another is: what names are "host names". Not all names in DNS are host names! Other names do not have the same forbinnden characters. And ACE in itself will give bad possibilities on the client side. An ACE understanding application will display the name in a user friendly way using the local character set instead of the ACE form. The user uses copy/past to get the name into another application that does not understand ACE. The result: a non-ACE name in local encoding will be used. So ACE will get many of the problems an UTF-8 solution will give. ACE will also result in lots of non-ASCII characters going into applications and protocols. >c) Strawpoll agrees that the Nameprep Design Team is working in the > right direction. (See Nameprep-02) > Nameprep is designed for one purpose: to enable "only ACE in application". There is a lot of good work in nameprep, but the nameprep work should be split into parts: 1) Forbidden characters in "host names". 2) Normalisation of UCS text that can be used for all text (like Unicode normalisation form C or KC). 3) DNS name matching rules. Then it would be a good base for non-ASCII handling in DNS. I also have a question about what character should be treated the same in name matching. In nameprep it says that the names are changed so that letters that look the same are changed to a single representation. Looking at the nameprep document it does not look like this is so. In UCS we have "Latin A", "Greek A" and "Russian A", and "Latin a", "Greek alpha" and "Russian a". As all A look the same all should be merged into "Latin A" and the corresponding for lower case a. Why is this not done? >If you have any objection (I know a few of you do), please raise them >now. > >If there is no major objection, then the next step would include > >2. Protocol Design Team (or someone) should start working on writing > an I-D for the IDN Protocol. As it stands now, IDNA seem the closest > we have. > What is the IDN protocol? All my drafts are for the DNS protocol. Dan From owner-idn@ops.ietf.org Wed Jan 24 03:54:23 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16905 for ; Wed, 24 Jan 2001 03:44:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LLDi-000I1h-00 for idn-data@psg.com; Wed, 24 Jan 2001 00:23:58 -0800 Received: from mail.i-dns.net ([203.126.116.228]) by psg.com with esmtp (Exim 3.16 #1) id 14LLDh-000I1Z-00 for idn@ops.ietf.org; Wed, 24 Jan 2001 00:23:57 -0800 Received: from jamessonyvaio (dhcp104.ripemtg.ripe.net [193.0.4.104]) by mail.i-dns.net (Postfix) with SMTP id C8908FFC0D; Wed, 24 Jan 2001 16:23:47 +0800 (SGT) Message-ID: <070d01c085de$cad49fe0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Dan Oscarsson" , References: <200101240810.f0O8AiX20319@valinor.malmo.trab.se> Subject: Re: [idn] San Diego Meeting Notes Date: Wed, 24 Jan 2001 16:22:23 +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 Dan, Please see my corrected email. It is "Application Area Approach" vs "Infrastructure Approach". Sorry for the confusion. > One major problem with "ACE in application" is that it requires a name > to be mangled into the form needed to compare two names, in the application > and it requires names to be store in DNS in the same way. > With mangling I mean things like forcing upper case to lower case. > Though you could fix this by allowing the DNS to return in responses > normlaised but unmangled names. This would allow names to be displayed > using the preferred form. No, this problem is not specific to ACE. It is a general general due to the normalization process which destory some information (e.g. case). > Another is: what names are "host names". Not all names in DNS are > host names! Other names do not have the same forbinnden characters. Agreed. > And ACE in itself will give bad possibilities on the client side. > An ACE understanding application will display the name in a user > friendly way using the local character set instead of the ACE form. > The user uses copy/past to get the name into another application > that does not understand ACE. The result: a non-ACE name in local > encoding will be used. So ACE will get many of the problems an UTF-8 > solution will give. ACE will also result in lots of non-ASCII characters > going into applications and protocols. This problem is known as 'leaking' which was also mention in the meeting by Rick. It is an issue which any proposal have to deal with, so once again, not unique to ACE. > Nameprep is designed for one purpose: to enable "only ACE in application". No. Nameprep is desgined for the purpose of doing nameprep. It does not matter whether it is ACE or UTF-8 or UTF-16 or UTF-32 or whatever encoding. Nameprep will still be needed for 'matching'. > There is a lot of good work in nameprep, but the nameprep work should be > split into parts: > > 1) Forbidden characters in "host names". > 2) Normalisation of UCS text that can be used for all text (like > Unicode normalisation form C or KC). > 3) DNS name matching rules. I think this make good sense. > >2. Protocol Design Team (or someone) should start working on writing > > an I-D for the IDN Protocol. As it stands now, IDNA seem the closest > > we have. > > What is the IDN protocol? > > All my drafts are for the DNS protocol. If the WG can agree with "Application Area Approach", then we need an IDN protocol for without changes to the "Infrastructure" (in this aspect, we refer without changes to DNS Infrastructure/Protocol"). -James Seng From owner-idn@ops.ietf.org Wed Jan 24 07:53:23 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19335 for ; Wed, 24 Jan 2001 07:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LP2v-0006Wy-00 for idn-data@psg.com; Wed, 24 Jan 2001 04:29:05 -0800 Received: from glucose.pas.idealab.com ([64.208.8.249] helo=idealab.com) by psg.com with smtp (Exim 3.16 #1) id 14LP2u-0006Ws-00 for idn@ops.ietf.org; Wed, 24 Jan 2001 04:29:04 -0800 Received: (qmail 6404 invoked by uid 526); 24 Jan 2001 12:29:03 -0000 To: Keith Moore Cc: idn@ops.ietf.org Subject: Re: [idn] San Diego Meeting Notes References: <200101240227.VAA03438@astro.cs.utk.edu> From: Marc Tamsky Date: 24 Jan 2001 04:29:03 -0800 In-Reply-To: Keith Moore's message of "Tue, 23 Jan 2001 21:27:36 -0500" Message-ID: Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-idn@ops.ietf.org Precedence: bulk >>>>> On Tue, 23 Jan 2001 21:27:36 -0500, Keith Moore said: > Dan, [...] > ACE seems to have a lower risk of failure. I guess we'll now need an examination of whether: (a) There is a need to assess the risk of failure for each proposal. and (b) What the criteria for measuring the "risk of failure" is. The arguments that follow are obvious, if (a) then (b) needs to be answered. If (a) is false, then forget (b) and stop waving that flag. Marc. From owner-idn@ops.ietf.org Wed Jan 24 08:50:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20453 for ; Wed, 24 Jan 2001 08:50:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LQ0L-000A9y-00 for idn-data@psg.com; Wed, 24 Jan 2001 05:30:29 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14LQ0K-000A8P-00 for idn@ops.ietf.org; Wed, 24 Jan 2001 05:30:28 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA05897; Wed, 24 Jan 2001 08:30:23 -0500 (EST) Message-Id: <200101241330.IAA05897@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Marc Tamsky cc: Keith Moore , idn@ops.ietf.org Subject: Re: [idn] San Diego Meeting Notes In-reply-to: Your message of "24 Jan 2001 04:29:03 PST." Date: Wed, 24 Jan 2001 08:30:23 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I guess we'll now need an examination of whether: > > (a) There is a need to assess the risk of failure for each proposal. > > and > > (b) What the criteria for measuring the "risk of failure" is. actually we don't have to do that. we need to reach rough consensus on a proposal. that doesn't mean we have to have consensus on the reasons for supporting that proposal. however it does seem like we'd prefer to support a proposal that seems likely to be adopted, and to be deployable. if adoption of an IDN solution causes people too much more pain than not doing so, they'll be less likely to deploy it. perhaps "risk of failure" isn't the best way to describe this, but I hope my meaning is sufficiently clear anyway. I suppose one could contrast this with the "cost of inelegance" (also insufficiently defined) of having to use ACE on the wire for an arbitrary number of years, and the potential "cost of multiple conversions" associated with having to convert from ASCII to ACE and then to UTF-8 (or something else) later. I don't deny the first cost or the potential for the second cost; I'm just trying to state the nature of the design choice. Keith From owner-idn@ops.ietf.org Thu Jan 25 03:24:27 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22041 for ; Thu, 25 Jan 2001 03:24:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LhGw-0000Cz-00 for idn-data@psg.com; Wed, 24 Jan 2001 23:56:46 -0800 Received: from dokka.maxware.no ([195.139.236.69]) by psg.com with esmtp (Exim 3.16 #1) id 14LhGv-0000Cp-00 for idn@ops.ietf.org; Wed, 24 Jan 2001 23:56:46 -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 IAA02374; Thu, 25 Jan 2001 08:56:31 +0100 Message-Id: <4.3.2.7.2.20010125003230.02ba5828@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 00:38:27 +0100 To: Paul Hoffman / IMC , "James Seng/Personal" , From: Harald Alvestrand Subject: Who does what (Re: [idn] San Diego Meeting Notes) In-Reply-To: References: <032c01c08584$e02803f0$06272dd4@jamessonyvaio> <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idn@ops.ietf.org Precedence: bulk At 17:19 23/01/2001 -0800, Paul Hoffman / IMC wrote: >The protocol design team did not volunteer to do the work. The >Applications Area Directors have said they are willing to take the work on >in the Apps area. Obviously, anyone from this WG would be invited to help. I think this working group should be the one that reviews the proposal for what is loosely termed "the IDN protocol" (IDNA or something very like it) before sending it to IETF-wide Last Call. The work of specifying how (and if) SMTP, NNTP, SNMP and so on and so forth make special efforts to deal with the IDN-ized DNS names is obviously a task for the relevant working groups, most of which are in the Applications area. I would like to encourage the authors of the IDNA document to update that document to be consistent with the design team report and submit it to the working group as a proposal for this WG's final output. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-idn@ops.ietf.org Thu Jan 25 06:56:32 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23675 for ; Thu, 25 Jan 2001 06:56:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LkfQ-000Ddu-00 for idn-data@psg.com; Thu, 25 Jan 2001 03:34:16 -0800 Received: from [210.107.128.31] (helo=mail.icu.ac.kr) by psg.com with esmtp (Exim 3.16 #1) id 14LkfP-000DbZ-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 03:34:15 -0800 Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31]) by mail.icu.ac.kr (8.9.2/8.9.3) with SMTP id UAA13199 for idn@ops.ietf.org; Thu, 25 Jan 2001 20:32:11 +0900 (KST) From: dlee@icu.ac.kr Message-Id: <20010125.AAA980421683@icu.ac.kr> To: idn@ops.ietf.org Reply-To: dlee@icu.ac.kr Subject: [idn] =?euc-kr?B?UmU6IFJlOiBbaWRuXSBTYW4gRGllZ28gTWVldGluZyBOb3Rlcw==?= Date: Thu, 25 Jan 2001 20:32:11 +0900 MIME-Version: 1.0 X-Priority: 3 X-Mailer: @MESSAGE-5.0.0830.1.2300 (SunOS 5.6) Content-Type: multipart/mixed; boundary="----=_NextPart_F7S5ZCPLOXM6XDYCASPLWDS6" Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_F7S5ZCPLOXM6XDYCASPLWDS6 Content-Type: multipart/alternative; boundary="----=_NextPart_KKDV51HTJFD8MXOCFGT6HK2X" ------=_NextPart_KKDV51HTJFD8MXOCFGT6HK2X Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SSBkb24ndCB0aGluayBpdCdzIGEgcmlnaHQgYXBwcm9hY2ggZm9jdXNpbmcgb24gYSBzaG9ydCB0 ZXJtIHNvbHV0aW9uIHdpdGhvdXQNCmNsZWFyIHVuZGVyc3RhbmluZy9ldmFsdWF0aW9uIG9uIHdo YXQgYSBsb25nIHRlcm0gc29sdXRpb24gd291bGQgYmUuIE1vcmVvdmVyLCB0aGUgcHJvcG9zZWQg ZGVjaXNpb24gc2hvdWxkIGJlIG1hZGUgYWZ0ZXIgdGhvcm91Z2ggYW5hbHlzaXMgb2YgcG9zc2li bGUgcHJvYmxlbXMgd2hlbiBub24tQUNFIGlzIHVzZWQgKGUuZy4gVVRGLTgpIHdoaWNoIEkgc3Vn Z2VzdGVkIGF0IHRoZSBTYW4gRGllZ28gbWVldGluZy4NCg0KRG9uZ21hbiBMZWUNCg0KPiANCj4g DQo+IC0tLS0tv/i6u7jevcPB9i0tLS0tDQo+ILq4s72757b3OiAiSmFtZXMgU2VuZy9QZXJzb25h bCIgDQo+ILnetMK757b3OiBpZG5Ab3BzLmlldGYub3JnDQo+ILOvwqU6IDIwMDEvMDEvMjQovPYp MDY6MzgNCj4gwaa48TogUmU6IFtpZG5dIFNhbiBEaWVnbyBNZWV0aW5nIE5vdGVzDQo+IA0KPiBE ZWFyIGFsbCwNCj4gDQo+IEkgd291bGQgbGlrZSB0byByZS1lbXBoYXNpcyBhIGZldyAnY29uc2Vu c3VzJyBpbiB0aGUgbWVldGluZyBpbiBTYW4NCj4gRGllZ28uDQo+IA0KPiBhKSBSZXF1aXJlbWVu dHMgSS1EIHRvIG1vdmUgdG8gTGFzdCBDYWxsIGFmdGVyIGxhc3QgbWlub3IgZWRpdGlvbi4NCj4g DQo+IGIpIFN0cmF3cG9sbCBhZ3JlZXMgd2l0aCBQcm90b2NvbCBEZXNpZ24gVGVhbSByZWNvbW1l bmRhdGlvbiB0byBmb2N1cw0KPiAgICBvbiAiQUNFIG9uIEFwcGxpY2F0aW9uIiBub3cgYnV0IGRv IG5vdCByZWplY3RpbmcgYSBsb25nZXIgdGVybQ0KPiAgICBzb2x1dGlvbiBpbiBmdXR1cmUuDQo+ IA0KPiBjKSBTdHJhd3BvbGwgYWdyZWVzIHRoYXQgdGhlIE5hbWVwcmVwIERlc2lnbiBUZWFtIGlz IHdvcmtpbmcgaW4gdGhlDQo+ICAgIHJpZ2h0IGRpcmVjdGlvbi4gKFNlZSBOYW1lcHJlcC0wMikN Cj4gDQo+IElmIHlvdSBoYXZlIGFueSBvYmplY3Rpb24gKEkga25vdyBhIGZldyBvZiB5b3UgZG8p LCBwbGVhc2UgcmFpc2UgdGhlbQ0KPiBub3cuDQo+IA0KPiBJZiB0aGVyZSBpcyBubyBtYWpvciBv YmplY3Rpb24sIHRoZW4gdGhlIG5leHQgc3RlcCB3b3VsZCBpbmNsdWRlDQo+IA0KPiAxLiBaaXRh IHdpbGwgZG8gdGhlIFJlcXVpcmVtZW50cyAtMDQgYW5kIHdlIHdpbGwgbW92ZSB0byBMYXN0IENh bGwuDQo+IA0KPiAyLiBQcm90b2NvbCBEZXNpZ24gVGVhbSAob3Igc29tZW9uZSkgc2hvdWxkIHN0 YXJ0IHdvcmtpbmcgb24gd3JpdGluZw0KPiAgICBhbiBJLUQgZm9yIHRoZSBJRE4gUHJvdG9jb2wu IEFzIGl0IHN0YW5kcyBub3csIElETkEgc2VlbSB0aGUgY2xvc2VzdA0KPiAgICB3ZSBoYXZlLg0K PiANCj4gMy4gQW4gQUNFIERlc2lnbiBUZWFtIG1heSBiZSBmb3JtIHRvIGludmVzdGlnYXRlIHdo YXQgaXMgdGhlIGNvcnJlY3QNCj4gICAgQUNFIHRvIHVzZSBmb3IgKDIpLg0KPiANCj4gSW4gYWRk aXRpb25hbCwgSSB3b3VsZCBhbHNvIGxpa2UgdG8gcHJvcG9zZSB0byB1cGRhdGUgdGhlIEdvYWxz IGFuZA0KPiBNaWxlc3RvbmUgc2VjdGlvbiBvZiB0aGUgV0cgQ2hhcnRlciB0byByZWZsZWN0IG91 ciBwcm9ncmVzcyBtb3JlDQo+IGFjY3VyYXRlbHkuDQo+IA0KPiBZb3VyIGNvbW1lbnRzIHdvdWxk IGJlIGFwcHJlY2lhdGVkLg0KPiANCj4gLUphbWVzIFNlbmcNCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQoKCgoKCg== ------=_NextPart_KKDV51HTJFD8MXOCFGT6HK2X Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PEhUTUw+CjxIRUFEPjwvSEVBRD4KPEJPRFkgQkdDT0xPUj0id2hpdGUiPgo8Rk9OVCBTSVpFPTI+ CkkgZG9uJ3QgdGhpbmsgaXQncyBhIHJpZ2h0IGFwcHJvYWNoIGZvY3VzaW5nIG9uIGEgc2hvcnQg dGVybSBzb2x1dGlvbiB3aXRob3V0PEJSPgpjbGVhciB1bmRlcnN0YW5pbmcvZXZhbHVhdGlvbiBv biB3aGF0IGEgbG9uZyB0ZXJtIHNvbHV0aW9uIHdvdWxkIGJlLiBNb3Jlb3ZlciwgdGhlIHByb3Bv c2VkIGRlY2lzaW9uIHNob3VsZCBiZSBtYWRlIGFmdGVyIHRob3JvdWdoIGFuYWx5c2lzIG9mIHBv c3NpYmxlIHByb2JsZW1zIHdoZW4gbm9uLUFDRSBpcyB1c2VkIChlLmcuIFVURi04KSB3aGljaCBJ IHN1Z2dlc3RlZCBhdCB0aGUgU2FuIERpZWdvIG1lZXRpbmcuPEJSPgo8QlI+CkRvbmdtYW4gTGVl PEJSPgo8QlI+Cj4gPEJSPgo+IDxCUj4KPiAtLS0tLb/4uru43r3DwfYtLS0tLTxCUj4KPiC6uLO9 u+e29zogIkphbWVzIFNlbmcvUGVyc29uYWwiIDxKYW1lc0BTZW5nLmNjPjxCUj4KPiC53rTCu+e2 9zogaWRuQG9wcy5pZXRmLm9yZzxCUj4KPiCzr8KlOiAyMDAxLzAxLzI0KLz2KTA2OjM4PEJSPgo+ IMGmuPE6IFJlOiBbaWRuXSBTYW4gRGllZ28gTWVldGluZyBOb3RlczxCUj4KPiA8QlI+Cj4gRGVh ciBhbGwsPEJSPgo+IDxCUj4KPiBJIHdvdWxkIGxpa2UgdG8gcmUtZW1waGFzaXMgYSBmZXcgJ2Nv bnNlbnN1cycgaW4gdGhlIG1lZXRpbmcgaW4gU2FuPEJSPgo+IERpZWdvLjxCUj4KPiA8QlI+Cj4g YSkgUmVxdWlyZW1lbnRzIEktRCB0byBtb3ZlIHRvIExhc3QgQ2FsbCBhZnRlciBsYXN0IG1pbm9y IGVkaXRpb24uPEJSPgo+IDxCUj4KPiBiKSBTdHJhd3BvbGwgYWdyZWVzIHdpdGggUHJvdG9jb2wg RGVzaWduIFRlYW0gcmVjb21tZW5kYXRpb24gdG8gZm9jdXM8QlI+Cj4gICAgb24gIkFDRSBvbiBB cHBsaWNhdGlvbiIgbm93IGJ1dCBkbyBub3QgcmVqZWN0aW5nIGEgbG9uZ2VyIHRlcm08QlI+Cj4g ICAgc29sdXRpb24gaW4gZnV0dXJlLjxCUj4KPiA8QlI+Cj4gYykgU3RyYXdwb2xsIGFncmVlcyB0 aGF0IHRoZSBOYW1lcHJlcCBEZXNpZ24gVGVhbSBpcyB3b3JraW5nIGluIHRoZTxCUj4KPiAgICBy aWdodCBkaXJlY3Rpb24uIChTZWUgTmFtZXByZXAtMDIpPEJSPgo+IDxCUj4KPiBJZiB5b3UgaGF2 ZSBhbnkgb2JqZWN0aW9uIChJIGtub3cgYSBmZXcgb2YgeW91IGRvKSwgcGxlYXNlIHJhaXNlIHRo ZW08QlI+Cj4gbm93LjxCUj4KPiA8QlI+Cj4gSWYgdGhlcmUgaXMgbm8gbWFqb3Igb2JqZWN0aW9u LCB0aGVuIHRoZSBuZXh0IHN0ZXAgd291bGQgaW5jbHVkZTxCUj4KPiA8QlI+Cj4gMS4gWml0YSB3 aWxsIGRvIHRoZSBSZXF1aXJlbWVudHMgLTA0IGFuZCB3ZSB3aWxsIG1vdmUgdG8gTGFzdCBDYWxs LjxCUj4KPiA8QlI+Cj4gMi4gUHJvdG9jb2wgRGVzaWduIFRlYW0gKG9yIHNvbWVvbmUpIHNob3Vs ZCBzdGFydCB3b3JraW5nIG9uIHdyaXRpbmc8QlI+Cj4gICAgYW4gSS1EIGZvciB0aGUgSUROIFBy b3RvY29sLiBBcyBpdCBzdGFuZHMgbm93LCBJRE5BIHNlZW0gdGhlIGNsb3Nlc3Q8QlI+Cj4gICAg d2UgaGF2ZS48QlI+Cj4gPEJSPgo+IDMuIEFuIEFDRSBEZXNpZ24gVGVhbSBtYXkgYmUgZm9ybSB0 byBpbnZlc3RpZ2F0ZSB3aGF0IGlzIHRoZSBjb3JyZWN0PEJSPgo+ICAgIEFDRSB0byB1c2UgZm9y ICgyKS48QlI+Cj4gPEJSPgo+IEluIGFkZGl0aW9uYWwsIEkgd291bGQgYWxzbyBsaWtlIHRvIHBy b3Bvc2UgdG8gdXBkYXRlIHRoZSBHb2FscyBhbmQ8QlI+Cj4gTWlsZXN0b25lIHNlY3Rpb24gb2Yg dGhlIFdHIENoYXJ0ZXIgdG8gcmVmbGVjdCBvdXIgcHJvZ3Jlc3MgbW9yZTxCUj4KPiBhY2N1cmF0 ZWx5LjxCUj4KPiA8QlI+Cj4gWW91ciBjb21tZW50cyB3b3VsZCBiZSBhcHByZWNpYXRlZC48QlI+ Cj4gPEJSPgo+IC1KYW1lcyBTZW5nPEJSPgo+IDxCUj4KPiA8QlI+Cj4gPEJSPgo+IDxCUj4KPiA8 QlI+Cj4gPEJSPgo+IDxCUj4KPEJSPgo8QlI+CjxCUj4KPEJSPjxCUj4KPElNRyBTUkM9Imh0dHA6 Ly9tYWlsLmljdS5hYy5rcjo4MC9jZ2ktYXV0aC9tYWlscmNwdC5jZ2k/dXNlcmlkPWRsZWUmbWFp bGRvbWFpbm5hbWU9aWN1LmFjLmtyJm1zZ2lkPTIwMDEwMTI1LkFBQTk4MDQyMTY4M0BpY3UuYWMu a3IiPgo8L0ZPTlQ+CjwvQk9EWT48L0hUTUw+Cgo= ------=_NextPart_KKDV51HTJFD8MXOCFGT6HK2X-- ------=_NextPart_F7S5ZCPLOXM6XDYCASPLWDS6-- From owner-idn@ops.ietf.org Thu Jan 25 10:57:44 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02219 for ; Thu, 25 Jan 2001 10:57:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LoCw-0001Qt-00 for idn-data@psg.com; Thu, 25 Jan 2001 07:21:06 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14LoCv-0001Ql-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 07:21:05 -0800 Message-ID: <001b01c086e2$ce1e5880$1001a8c0@neteka.com> From: "Edmon" To: , References: <20010125.AAA980421683@icu.ac.kr> Subject: [idn] What happens to 8bit DNS requests Date: Thu, 25 Jan 2001 10:23:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C086B8.E19DE620" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C086B8.E19DE620 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable I really agree with Dongman Lee that we should understand the long term = solution before rushing into an intermediate fix/hack. About what happens to 8bit requests as they get sent, I have been urging = that we should do some kind of study, at least to let everyone know what = will happen if these DNS packets are forced through from, say a common = application such as the browser, through the OS kernel. Cause even if = we use ACE, these requests will be sent via non-compliant browsers to = affect the system. To that end, I have finally put together a bunch of hand notes that we = have been collecting about the "known issues" for multilingual domain = names. Please take a look and comment on it and add to it too. = http://www.openidn.org/issues.html Dongman, do you have any studies on the effects of 8bit requests sent = via other applications or OS? Edmon ----- Original Message -----=20 From: dlee@icu.ac.kr=20 To: idn@ops.ietf.org=20 Sent: Thursday, January 25, 2001 6:32 AM Subject: [idn] Re: Re: [idn] San Diego Meeting Notes I don't think it's a right approach focusing on a short term solution = without clear understaning/evaluation on what a long term solution would be. = Moreover, the proposed decision should be made after thorough analysis = of possible problems when non-ACE is used (e.g. UTF-8) which I suggested = at the San Diego meeting. Dongman Lee >=20 >=20 > -----=BF=F8=BA=BB=B8=DE=BD=C3=C1=F6----- > =BA=B8=B3=BD=BB=E7=B6=F7: "James Seng/Personal"=20 > =B9=DE=B4=C2=BB=E7=B6=F7: idn@ops.ietf.org > =B3=AF=C2=A5: 2001/01/24(=BC=F6)06:38 > =C1=A6=B8=F1: Re: [idn] San Diego Meeting Notes >=20 > Dear all, >=20 > I would like to re-emphasis a few 'consensus' in the meeting in San > Diego. >=20 > a) Requirements I-D to move to Last Call after last minor edition. >=20 > b) Strawpoll agrees with Protocol Design Team recommendation to = focus > on "ACE on Application" now but do not rejecting a longer term > solution in future. >=20 > c) Strawpoll agrees that the Nameprep Design Team is working in the > right direction. (See Nameprep-02) >=20 > If you have any objection (I know a few of you do), please raise = them > now. >=20 > If there is no major objection, then the next step would include >=20 > 1. Zita will do the Requirements -04 and we will move to Last Call. >=20 > 2. Protocol Design Team (or someone) should start working on writing > an I-D for the IDN Protocol. As it stands now, IDNA seem the closest > we have. >=20 > 3. An ACE Design Team may be form to investigate what is the correct > ACE to use for (2). >=20 > In additional, I would also like to propose to update the Goals and > Milestone section of the WG Charter to reflect our progress more > accurately. >=20 > Your comments would be appreciated. >=20 > -James Seng >=20 >=20 >=20 >=20 >=20 >=20 >=20 =20 ------=_NextPart_000_0018_01C086B8.E19DE620 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
I really agree with Dongman Lee that we = should=20 understand the long term solution before rushing into an intermediate=20 fix/hack.
 
About what happens to 8bit requests as = they get=20 sent, I have been urging that we should do some kind of study, at least = to let=20 everyone know what will happen if these DNS packets are forced through = from, say=20 a common application such as the browser, through the OS kernel.  = Cause=20 even if we use ACE, these requests will be sent via non-compliant = browsers to=20 affect the system.
 
 
Dongman, do you have any studies on the = effects of=20 8bit requests sent via other applications or OS?
 
Edmon
 
 
----- Original Message -----
From:=20 dlee@icu.ac.kr
Sent: Thursday, January 25, = 2001 6:32=20 AM
Subject: [idn] Re: Re: [idn] = San Diego=20 Meeting Notes

I don't think it's a right approach = focusing on a=20 short term solution without
clear understaning/evaluation on what a = long=20 term solution would be. Moreover, the proposed decision should be made = after=20 thorough analysis of possible problems when non-ACE is used (e.g. = UTF-8) which=20 I suggested at the San Diego meeting.

Dongman Lee

> =
>=20
> -----=BF=F8=BA=BB=B8=DE=BD=C3=C1=F6-----
> = =BA=B8=B3=BD=BB=E7=B6=F7: "James Seng/Personal"=20
> =B9=DE=B4=C2=BB=E7=B6=F7: = idn@ops.ietf.org
> =B3=AF=C2=A5:=20 2001/01/24(=BC=F6)06:38
> =C1=A6=B8=F1: Re: [idn] San Diego = Meeting Notes
>=20
> Dear all,
>
> I would like to re-emphasis a few=20 'consensus' in the meeting in San
> Diego.
>
> a)=20 Requirements I-D to move to Last Call after last minor = edition.
>=20
> b) Strawpoll agrees with Protocol Design Team recommendation = to=20 focus
> on "ACE on Application" now but do not rejecting a = longer=20 term
> solution in future.
>
> c) Strawpoll agrees = that the=20 Nameprep Design Team is working in the
> right direction. (See=20 Nameprep-02)
>
> If you have any objection (I know a few = of you=20 do), please raise them
> now.
>
> If there is no = major=20 objection, then the next step would include
>
> 1. Zita = will do=20 the Requirements -04 and we will move to Last Call.
>
> = 2.=20 Protocol Design Team (or someone) should start working on = writing
> an=20 I-D for the IDN Protocol. As it stands now, IDNA seem the = closest
> we=20 have.
>
> 3. An ACE Design Team may be form to = investigate what=20 is the correct
> ACE to use for (2).
>
> In = additional, I=20 would also like to propose to update the Goals and
> Milestone = section=20 of the WG Charter to reflect our progress more
> = accurately.
>=20
> Your comments would be appreciated.
>
> -James=20 Seng
>
>
>
>
>
>
>=20





=20 ------=_NextPart_000_0018_01C086B8.E19DE620-- From owner-idn@ops.ietf.org Thu Jan 25 12: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 MAA04525 for ; Thu, 25 Jan 2001 12:18:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Lpe4-0007Au-00 for idn-data@psg.com; Thu, 25 Jan 2001 08:53:12 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14Lpe3-0007Ao-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 08:53:11 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09918 for ; Thu, 25 Jan 2001 08:46:51 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010125.AAA980421683@icu.ac.kr> References: <20010125.AAA980421683@icu.ac.kr> Date: Thu, 25 Jan 2001 08:52:46 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Re: Re: [idn] San Diego Meeting Notes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 8:32 PM +0900 1/25/01, dlee@icu.ac.kr wrote: >I don't think it's a right approach focusing on a short term solution without >clear understaning/evaluation on what a long term solution would be. Could you clarify your reason for this? As long as the short term presentation-layer solution doesn't force any design change for the long-term solution, it seems that the two can be unrelated. Further, having a short-term solution in place gives people more time to figure out what the long term solution should be, and will also give some valuable data about the attributes of the names that need to be handled in the long term solution. > Moreover, the proposed decision should be made after thorough >analysis of possible problems when non-ACE is used (e.g. UTF-8) >which I suggested at the San Diego meeting. To be specific, the proposals are all for non-marked UTF-8, and many of the proposals are for non-marked UTF-8 without nameprep. That analysis has already appeared on this mailing list. Today's applications allow you to enter DNS names in many encodings, not just UTF-8. People from companies that take advantage of this sad fact are quite active in this WG. For non-marked UTF-8 (with or without nameprep), non-uniqueness of names due to different names in different encodings having the same octet sequences raises so many security issues that it seems silly to even consider it. Any proposal for marked UTF-8 with nameprep immediately takes on all of the presentation issues that IDNA has, and further forces many changes to other IETF protocols and to many non-protocol services that currently do DNS name validation. The purpose of using an ACE encoding instead of a marked UTF-8 encoding is to allow IDN to be used more quickly by more users. It seems unlikely that this group would choose a marked encoding that forces more changes in protocols and applications before it can be reliably deployed. Does it seem useful for this group do more analysis even in the face of those issues? Put another way, the IETF generally does not create proposals with known massive security holes in them. Is it OK for IDN to be designed with known security problems? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Jan 25 14:58:18 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07579 for ; Thu, 25 Jan 2001 14:58:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LsAq-000HRf-00 for idn-data@psg.com; Thu, 25 Jan 2001 11:35:12 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14LsAp-000HNo-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 11:35:11 -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 TAA27934; Thu, 25 Jan 2001 19:30:03 GMT From: "Brian W. Spolarich" To: "Harald Alvestrand" , "Paul Hoffman / IMC" , "James Seng/Personal" , Subject: RE: Who does what (Re: [idn] San Diego Meeting Notes) Date: Thu, 25 Jan 2001 14:34:02 -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) Importance: Normal In-Reply-To: <4.3.2.7.2.20010125003230.02ba5828@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | I think this working group should be the one that reviews the proposal | for what is loosely termed "the IDN protocol" (IDNA or something very | like it) before sending it to IETF-wide Last Call. What is the opinion of the working group on IDNA vs. IDNRA? Paul and Patrik have proposed two alternative ACE implementation approaches: IDNRA calls for an application and resolver-based approach, putting most of the IDN work in the resolver, while IDNA calls for an application-only approach. One of the premises of the ACE approach is the belief that the infrastructure will take too long to update (I'm purposefully simplifying here) and the IDN handling needs to happen at the edge of the network. As I read IDNA, the authors believe that the bulk of IDN processing cannot happen in the resolver (or perhaps immediately in front of the resolver) and must happen solely in the application. If that is so, is it reasonable to assume that a significant percentage of application will be updated very quickly? Certainly there are market pressures that might make this so, but I'm not convinced. The authors do not state in IDNA why they believe IDNA is a better approach than IDNRA, which would be a helpful clarification of the draft. I briefly discussed this with Paul at IETF49 but we didn't have an opportunity to discuss this in detail (except that we disagreed :-). It seems to me that in most cases, particularly with most of the relatively simple applications, as long as the application "stays out of the way" and passes the IDN intact to the resolver the IDN work can happen completely in the resolver layer. Some applications and protocols will have to be reviewed and updated(and has already been discussed there will need to be a review of the impact by the various WGs in the applications area), but certainly by all means not every application. -bws From owner-idn@ops.ietf.org Thu Jan 25 14:58:18 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07581 for ; Thu, 25 Jan 2001 14:58:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LsBK-000HSE-00 for idn-data@psg.com; Thu, 25 Jan 2001 11:35:42 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14LsBK-000HS6-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 11:35: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 OAA19502; Thu, 25 Jan 2001 14:35:33 -0500 (EST) Message-Id: <200101251935.OAA19502@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Edmon" cc: dlee@icu.ac.kr, idn@ops.ietf.org Subject: Re: [idn] What happens to 8bit DNS requests In-reply-to: Your message of "Thu, 25 Jan 2001 10:23:37 EST." <001b01c086e2$ce1e5880$1001a8c0@neteka.com> Date: Thu, 25 Jan 2001 14:35:33 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I really agree with Dongman Lee that we should understand the long term > solution before rushing into an intermediate fix/hack. Any notion of "the" long term solution is pure fantasy. There are lots of protocols using DNS names as protocol elements. Each one has different issues associated with using UTF-8 (or some other non-ASCII representation) in the context of that protocol. Each one has different degrees of deployment and different difficulties associated with transition to a new protocol version and with upgrading existing implementations. Some protocols will necessarily get upgraded before others; some may never be upgraded at all, or may become obsolete (perhaps replaced by something completely different) before they are upgraded. Keith From owner-idn@ops.ietf.org Thu Jan 25 16:12:35 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08897 for ; Thu, 25 Jan 2001 16:12:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LtDf-000LkY-00 for idn-data@psg.com; Thu, 25 Jan 2001 12:42:11 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14LtDd-000LkS-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 12:42:09 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA20380; Thu, 25 Jan 2001 15:41:07 -0500 (EST) Message-Id: <200101252041.PAA20380@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian W. Spolarich" cc: "Harald Alvestrand" , "Paul Hoffman / IMC" , "James Seng/Personal" , idn@ops.ietf.org Subject: Re: Who does what (Re: [idn] San Diego Meeting Notes) In-reply-to: Your message of "Thu, 25 Jan 2001 14:34:02 EST." Date: Thu, 25 Jan 2001 15:41:07 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > What is the opinion of the working group on IDNA vs. IDNRA? Paul and > Patrik have proposed two alternative ACE implementation approaches: IDNRA > calls for an application and resolver-based approach, putting most of the > IDN work in the resolver, while IDNA calls for an application-only approach. I don't think there's much difference between the two; IDNA is just a cleaner way of expressing what would end up as more-or-less the same architecture as IDNRA. Here's why: - since ACEs are compatible with ASCII domain names, a resolver API that accepts and returns ACEs already exists; it's not going to go away anytime soon even if other resolver APIs accepting and/or returning UTF-8 were to appear. even if the resolver API always accepts and returns ACE, there will inevitably be wrapper routines around the resolver which perform simple kinds of lookups and which accept and/or return UTF-8. so either way, we'll have one interface that deals in terms of ACE and another that deals in terms of UTF-8. the only real question is the degree to which the latter interface will be consistent across different platforms. if not, folks writing portable software will need to supply their own conversion routines. however, the algorithms (and probably code) to do this will be published, so even this isn't a huge barrier. - many applications will need to compare IDNs with one another for equivalence. for reasons of backward compatibility they will see both ACE IDNs and UTF-8 IDNs, and they'll have to know whether they are equivalent. in addition, applications will have to convert from UTF-8 format to ACE when IDNs are used as elements in protocols which do not (yet?) tolerate non-ascii DNS names, and they'll have to convert from ACE to UTF-8 for display. so either way, there will need to be direct access to the nameprep and ACE<->UTF-8 conversion routines. they cannot merely be embedded in the resolver API. so either way, you have pretty much the same set of interfaces, and the same kind of layering. Keith From owner-idn@ops.ietf.org Thu Jan 25 17:10:37 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09892 for ; Thu, 25 Jan 2001 17:10:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LuJa-0000Wt-00 for idn-data@psg.com; Thu, 25 Jan 2001 13:52:22 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14LuJZ-0000Wm-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 13:52:21 -0800 Message-ID: <010501c08719$b85e64e0$1001a8c0@neteka.com> From: "Edmon" To: "Keith Moore" Cc: , References: <200101251935.OAA19502@astro.cs.utk.edu> Subject: Re: [idn] What happens to 8bit DNS requests Date: Thu, 25 Jan 2001 16:56:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 appreciate that there are different issues associated with UTF-8 or other non-ASCII approach, my main point is that even if we do go to IDNA, chances are that users unknowingly will still be sending multilingual dns requests through existing products that are non-IDNA aware. The known issues paper is used to document these instances that cannot be avoided. I truly believe that we should prepare ourselves for these situations. It would be greatly appreciated if anyone that really care about getting multilingual domain names usable on the Internet to give me some comments on the paper at http://www.openidn.org/issues.html so that more people will know about these behaviours as multilingual names are deployed. I would make it into an Internet draft if anyone thinks that it is something valuable. Edmon > > I really agree with Dongman Lee that we should understand the long term > > solution before rushing into an intermediate fix/hack. > > Any notion of "the" long term solution is pure fantasy. There are lots > of protocols using DNS names as protocol elements. Each one has different > issues associated with using UTF-8 (or some other non-ASCII representation) > in the context of that protocol. Each one has different degrees of > deployment and different difficulties associated with transition to a new > protocol version and with upgrading existing implementations. > Some protocols will necessarily get upgraded before others; some may > never be upgraded at all, or may become obsolete (perhaps replaced by > something completely different) before they are upgraded. > > Keith From owner-idn@ops.ietf.org Thu Jan 25 17:43:39 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10381 for ; Thu, 25 Jan 2001 17:43:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LuuN-0003FE-00 for idn-data@psg.com; Thu, 25 Jan 2001 14:30:23 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14LuuM-0003F6-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 14:30:22 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA21390; Thu, 25 Jan 2001 17:30:15 -0500 (EST) Message-Id: <200101252230.RAA21390@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Edmon" cc: "Keith Moore" , dlee@icu.ac.kr, idn@ops.ietf.org Subject: Re: [idn] What happens to 8bit DNS requests In-reply-to: Your message of "Thu, 25 Jan 2001 16:56:45 EST." <010501c08719$b85e64e0$1001a8c0@neteka.com> Date: Thu, 25 Jan 2001 17:30:15 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I appreciate that there are different issues associated with UTF-8 or other > non-ASCII approach, my main point is that even if we do go to IDNA, chances > are that users unknowingly will still be sending multilingual dns requests > through existing products that are non-IDNA aware. agreed. I think such a document could be useful, with the following caveats: - it would be very hard to make it sufficiently comprehensive that it could serve as guidance for the design of an IDN solution, or even to serve as a guide for users wanting to know which products to buy. - it could take a large amount of time and energy so I wouldn't mind at all seeing such a document produced, but I wouldn't want to see such an effort divert resources from the primary work on IDNs, or delay the primary work on IDNs. regarding the document you referenced (http://www.openidn.org/issues.html) - there are many more kinds of components affected than those that you list (web browser, kernel, proxy server) - there are many more implementations of each of these kinds of components than those that you list. - there are other platforms than those you list, with different issues than these. all of which just illustrates that it's difficult to make this kind of list comprehensive. - it's not clear exactly what is meant by "kernel" or how it comes into play in the interaction between applications. - it appears to be difficult to isolate or even document the nature of certain problems, especially given that the behavior may change depending on program preferences, presense of proxies, choice of platform, etc. - the issues you cite are good examples of how 8-bit characters get mangled by some existing programs, but it's hard to know how to use this information except to demonstrate that 8-bit characters get mangled in a variety of ways. - the "solution" it recommends for squid is somewhat dubious: it oversimplifies the problem of making IDNs work for the web. e.g. even if we adopted a UTF-8 on-the-wire solution for URLs in the HTTP protocol (something that is not within the scope of this group to decide), it's not sufficient to simply change these programs to be 8-bit transparent for typed-in URLs. there are other interfaces which contain URLs (web pages, config files, APIs used to control the browser, cut-and-paste), nameprep would certainly have to be applied to URLs in the browser so that local caching would work (even if proxies and remote servers were also taught to do nameprep) From owner-idn@ops.ietf.org Thu Jan 25 17:46:06 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10419 for ; Thu, 25 Jan 2001 17:46:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Lun5-0002mJ-00 for idn-data@psg.com; Thu, 25 Jan 2001 14:22:51 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Lun4-0002it-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 14:22:50 -0800 Received: (qmail 13263 invoked by uid 1001); 25 Jan 2001 20:16:38 -0000 Date: 25 Jan 2001 20:16:38 -0000 Message-ID: <20010125201638.5735.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: Who does what (Re: [idn] San Diego Meeting Notes) References: <4.3.2.7.2.20010125003230.02ba5828@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Brian W. Spolarich says that ``in most cases'' the IDN work can happen ``completely in the resolver layer.'' For the record: My ACE upgrade list in http://cr.yp.to/proto/idn.html takes this idea into account. It explicitly assumes that the argument to gethostbyname() is in UTF-8. ACE conversion is needed in gethostbyname() but not in applications that merely call gethostbyname(). But the list is still very long, because there are many other uses of names. For example, DNS servers and SMTP servers and web servers need to be upgraded for ACE, so that they can compare incoming ACE names to UTF-8 names in configuration files. ---Dan From owner-idn@ops.ietf.org Thu Jan 25 18:10:40 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10846 for ; Thu, 25 Jan 2001 18:10:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LvDp-0004XH-00 for idn-data@psg.com; Thu, 25 Jan 2001 14:50:29 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14LvDo-0004XA-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 14:50:28 -0800 Received: (qmail 26927 invoked by uid 1001); 25 Jan 2001 20:46:20 -0000 Date: 25 Jan 2001 20:46:20 -0000 Message-ID: <20010125204620.18613.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: [idn] UNIX moving to UTF-8 References: <20010123233243.17988.qmail@cr.yp.to> <200101240227.VAA03438@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: > your analysis assumes that most sites are or will be using UTF-8 locally. > this seems like quite a stretch as it is very different from current reality. For extensive evidence that it's happening: http://www.cl.cam.ac.uk/~mgk25/unicode.html ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html http://czyborra.com/utf/#UTF-8 ---Dan From owner-idn@ops.ietf.org Thu Jan 25 18:30:12 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11163 for ; Thu, 25 Jan 2001 18:30:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LvNL-0005Dc-00 for idn-data@psg.com; Thu, 25 Jan 2001 15:00:19 -0800 Received: from [203.126.116.228] (helo=mail.i-dns.net) by psg.com with esmtp (Exim 3.16 #1) id 14LvNK-0005DU-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 15:00:18 -0800 Received: from jamessonyvaio (unknown [212.45.40.32]) by mail.i-dns.net (Postfix) with SMTP id 9ED82FFC0B; Fri, 26 Jan 2001 07:00:05 +0800 (SGT) Message-ID: <02eb01c08722$61a82060$32272dd4@jamessonyvaio> From: "James Seng/Personal" To: "D. J. Bernstein" , References: <20010123233243.17988.qmail@cr.yp.to> <200101240227.VAA03438@astro.cs.utk.edu> <20010125204620.18613.qmail@cr.yp.to> Subject: Re: [idn] UNIX moving to UTF-8 Date: Fri, 26 Jan 2001 06:58:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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, When is the last time you travel to non-English speaking country and ask the people there when they are going to switch over to UTF-8? -James Seng ----- Original Message ----- From: "D. J. Bernstein" To: Sent: Friday, January 26, 2001 4:46 AM Subject: [idn] UNIX moving to UTF-8 > Keith Moore writes: > > your analysis assumes that most sites are or will be using UTF-8 locally. > > this seems like quite a stretch as it is very different from current reality. > > For extensive evidence that it's happening: > > http://www.cl.cam.ac.uk/~mgk25/unicode.html > ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html > http://czyborra.com/utf/#UTF-8 > > ---Dan > From owner-idn@ops.ietf.org Thu Jan 25 18:33:10 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11232 for ; Thu, 25 Jan 2001 18:33:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Lvfi-0006W5-00 for idn-data@psg.com; Thu, 25 Jan 2001 15:19:18 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14Lvfh-0006Vz-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 15:19:17 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA21900; Thu, 25 Jan 2001 18:19:15 -0500 (EST) Message-Id: <200101252319.SAA21900@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: Who does what (Re: [idn] San Diego Meeting Notes) In-reply-to: Your message of "25 Jan 2001 20:16:38 GMT." <20010125201638.5735.qmail@cr.yp.to> Date: Thu, 25 Jan 2001 18:19:15 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > But the list is still very long, because there are many other uses of > names. For example, DNS servers and SMTP servers and web servers need to > be upgraded for ACE, so that they can compare incoming ACE names to > UTF-8 names in configuration files. they'd have to be upgraded for nameprep anyway, otherwise attempts to compare different UTF-8 representations of the same IDN would fail. Keith From owner-idn@ops.ietf.org Thu Jan 25 18:35:54 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11319 for ; Thu, 25 Jan 2001 18:35:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Lvlt-0006wV-00 for idn-data@psg.com; Thu, 25 Jan 2001 15:25:41 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14Lvls-0006wM-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 15:25:40 -0800 Received: (qmail 24293 invoked by uid 1001); 25 Jan 2001 21:24:50 -0000 Date: 25 Jan 2001 21:24:50 -0000 Message-ID: <20010125212450.26987.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: [idn] nameprep allows Alpha? References: <009801c07dee$19b318b0$8e00a8c0@jamessonyvaio> <032c01c08584$e02803f0$06272dd4@jamessonyvaio> <20010123233243.17988.qmail@cr.yp.to> <20010124022959.14817.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 I'd like to draw more attention to this example from Dan Oscarsson, because I find it extremely worrisome. According to Paul's nameprep script, uppercase Alpha Beta is accepted in domain names, and matches lowercase alpha beta, not ab. But uppercase AB---which, when properly displayed, has the same glyphs--- matches ab, not alpha beta. I thought the point of nameprep was to prevent confusion: in particular, to guarantee that two valid host names will match inside the computer if they match visually. If Alpha Beta and AB are valid, they have to match. Paul Hoffman / IMC writes: > > > http://www.imc.org/nameprep > > Is that (1) up to date and (2) normative? > (2) What do you mean? The final nameprep specification should be working software; anything else is unnecessarily error-prone and unnecessarily difficult to review. My question is whether your software is the current specification. ---Dan From owner-idn@ops.ietf.org Thu Jan 25 19:30:24 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12466 for ; Thu, 25 Jan 2001 19:30:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LwJw-0009VF-00 for idn-data@psg.com; Thu, 25 Jan 2001 16:00:52 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14LwJv-0009UZ-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 16:00:51 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA22356; Thu, 25 Jan 2001 19:00:48 -0500 (EST) Message-Id: <200101260000.TAA22356@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 "25 Jan 2001 20:46:20 GMT." <20010125204620.18613.qmail@cr.yp.to> Date: Thu, 25 Jan 2001 19:00:48 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > For extensive evidence that it's happening: that's not anything of the sort. you cited evidence that a few energetic folks are implementing and modifying existing tools to support UTF-8. that's a far cry from widespread adoption of UTF-8 by real users. Keith From owner-idn@ops.ietf.org Thu Jan 25 22:18:54 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15029 for ; Thu, 25 Jan 2001 22:18:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Lyv9-000Kdl-00 for idn-data@psg.com; Thu, 25 Jan 2001 18:47:27 -0800 Received: from [210.107.128.31] (helo=mail.icu.ac.kr) by psg.com with esmtp (Exim 3.16 #1) id 14Lyv8-000Kdb-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 18:47:26 -0800 Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31]) by mail.icu.ac.kr (8.9.2/8.9.3) with SMTP id LAA07923 for idn@ops.ietf.org; Fri, 26 Jan 2001 11:45:26 +0900 (KST) From: dlee@icu.ac.kr Message-Id: <20010126.AAA980476085@icu.ac.kr> To: idn@ops.ietf.org Reply-To: dlee@icu.ac.kr Subject: [idn] =?euc-kr?B?UmU6IFtpZG5dIFJlOiBSZTogW2lkbl0gU2FuIERpZWdvIE1lZXRpbmcg?= =?euc-kr?B?Tm90ZXM=?= Date: Fri, 26 Jan 2001 11:45:26 +0900 MIME-Version: 1.0 X-Priority: 3 X-Mailer: @MESSAGE-5.0.0830.1.2300 (SunOS 5.6) Content-Type: multipart/mixed; boundary="----=_NextPart_RNB5OMA88BPHJUBGR2W6CZA0" Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_RNB5OMA88BPHJUBGR2W6CZA0 Content-Type: multipart/alternative; boundary="----=_NextPart_B6QZWYROQKIIQQAIA22DYLTE" ------=_NextPart_B6QZWYROQKIIQQAIA22DYLTE Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 PiBBdCA4OjMyIFBNICswOTAwIDEvMjUvMDEsIGRsZWVAaWN1LmFjLmtyIHdyb3RlOg0KPiA+SSBk b24ndCB0aGluayBpdCdzIGEgcmlnaHQgYXBwcm9hY2ggZm9jdXNpbmcgb24gYSBzaG9ydCB0ZXJt IHNvbHV0aW9uIHdpdGhvdXQNCj4gPmNsZWFyIHVuZGVyc3RhbmluZy9ldmFsdWF0aW9uIG9uIHdo YXQgYSBsb25nIHRlcm0gc29sdXRpb24gd291bGQgYmUuDQo+IA0KPiBDb3VsZCB5b3UgY2xhcmlm eSB5b3VyIHJlYXNvbiBmb3IgdGhpcz8gQXMgbG9uZyBhcyB0aGUgc2hvcnQgdGVybSANCj4gcHJl c2VudGF0aW9uLWxheWVyIHNvbHV0aW9uIGRvZXNuJ3QgZm9yY2UgYW55IGRlc2lnbiBjaGFuZ2Ug Zm9yIHRoZSANCj4gbG9uZy10ZXJtIHNvbHV0aW9uLCBpdCBzZWVtcyB0aGF0IHRoZSB0d28gY2Fu IGJlIHVucmVsYXRlZC4gRnVydGhlciwgDQo+IGhhdmluZyBhIHNob3J0LXRlcm0gc29sdXRpb24g aW4gcGxhY2UgZ2l2ZXMgcGVvcGxlIG1vcmUgdGltZSB0byANCj4gZmlndXJlIG91dCB3aGF0IHRo ZSBsb25nIHRlcm0gc29sdXRpb24gc2hvdWxkIGJlLCBhbmQgd2lsbCBhbHNvIGdpdmUgDQo+IHNv bWUgdmFsdWFibGUgZGF0YSBhYm91dCB0aGUgYXR0cmlidXRlcyBvZiB0aGUgbmFtZXMgdGhhdCBu ZWVkIHRvIGJlIA0KPiBoYW5kbGVkIGluIHRoZSBsb25nIHRlcm0gc29sdXRpb24uDQoNClRoZSBw cm9ibGVtIGlzIHdlIGRvbid0IGtub3cgeWV0IHdoYXQgdGhlIGxvbmcgdGVybSBzb2x1dGlvbiB3 b3VsZCBiZS4NCkluIHRoYXQgY29udGV4dCwgSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIHByb3Bv c2VkIHNvbHV0aW9uIGlzIGEgc29sdXRpb24gZm9yIGEgc2hvcnQNCnRlcm0gKGl0IGNvdWxkIGxv Y2sgdXMgdXAgbG9uZ2VyIHRoYW4gd2UgZXhwZWN0IGFzIEtsZW5zaW4gcG9pbnRlZCBvdXQpIHRo b3VnaCBJIGFncmVlIHRoYXQgdGhlIEFDRS1iYXNlZCBhcHByb2FjaCBpcyBhIHNpbXBsZSBzb2x1 dGlvbiB0byBhbGxvdyB1c2VycyB0byB1c2UgSUROIHdpdGggdGhlIGN1cnJlbnQgRE5TIHByb3Rv Y29sLiANCg0KRG9uZ21hbiBMZWUgDQoKCgoKCg== ------=_NextPart_B6QZWYROQKIIQQAIA22DYLTE Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PEhUTUw+CjxIRUFEPjwvSEVBRD4KPEJPRFkgQkdDT0xPUj0id2hpdGUiPgo8Rk9OVCBTSVpFPTI+ Cj4gQXQgODozMiBQTSArMDkwMCAxLzI1LzAxLCBkbGVlQGljdS5hYy5rciB3cm90ZTo8QlI+Cj4g PkkgZG9uJ3QgdGhpbmsgaXQncyBhIHJpZ2h0IGFwcHJvYWNoIGZvY3VzaW5nIG9uIGEgc2hvcnQg dGVybSBzb2x1dGlvbiB3aXRob3V0PEJSPgo+ID5jbGVhciB1bmRlcnN0YW5pbmcvZXZhbHVhdGlv biBvbiB3aGF0IGEgbG9uZyB0ZXJtIHNvbHV0aW9uIHdvdWxkIGJlLjxCUj4KPiA8QlI+Cj4gQ291 bGQgeW91IGNsYXJpZnkgeW91ciByZWFzb24gZm9yIHRoaXM/IEFzIGxvbmcgYXMgdGhlIHNob3J0 IHRlcm0gPEJSPgo+IHByZXNlbnRhdGlvbi1sYXllciBzb2x1dGlvbiBkb2Vzbid0IGZvcmNlIGFu eSBkZXNpZ24gY2hhbmdlIGZvciB0aGUgPEJSPgo+IGxvbmctdGVybSBzb2x1dGlvbiwgaXQgc2Vl bXMgdGhhdCB0aGUgdHdvIGNhbiBiZSB1bnJlbGF0ZWQuIEZ1cnRoZXIsIDxCUj4KPiBoYXZpbmcg YSBzaG9ydC10ZXJtIHNvbHV0aW9uIGluIHBsYWNlIGdpdmVzIHBlb3BsZSBtb3JlIHRpbWUgdG8g PEJSPgo+IGZpZ3VyZSBvdXQgd2hhdCB0aGUgbG9uZyB0ZXJtIHNvbHV0aW9uIHNob3VsZCBiZSwg YW5kIHdpbGwgYWxzbyBnaXZlIDxCUj4KPiBzb21lIHZhbHVhYmxlIGRhdGEgYWJvdXQgdGhlIGF0 dHJpYnV0ZXMgb2YgdGhlIG5hbWVzIHRoYXQgbmVlZCB0byBiZSA8QlI+Cj4gaGFuZGxlZCBpbiB0 aGUgbG9uZyB0ZXJtIHNvbHV0aW9uLjxCUj4KPEJSPgpUaGUgcHJvYmxlbSBpcyB3ZSBkb24ndCBr bm93IHlldCB3aGF0IHRoZSBsb25nIHRlcm0gc29sdXRpb24gd291bGQgYmUuPEJSPgpJbiB0aGF0 IGNvbnRleHQsIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyBh IHNvbHV0aW9uIGZvciBhIHNob3J0PEJSPgp0ZXJtIChpdCBjb3VsZCBsb2NrIHVzIHVwIGxvbmdl ciB0aGFuIHdlIGV4cGVjdCBhcyBLbGVuc2luIHBvaW50ZWQgb3V0KSB0aG91Z2ggSSBhZ3JlZSB0 aGF0IHRoZSBBQ0UtYmFzZWQgYXBwcm9hY2ggaXMgYSBzaW1wbGUgc29sdXRpb24gdG8gYWxsb3cg dXNlcnMgdG8gdXNlIElETiB3aXRoIHRoZSBjdXJyZW50IEROUyBwcm90b2NvbC4gPEJSPgo8QlI+ CkRvbmdtYW4gTGVlIDxCUj4KPEJSPgo8QlI+CjxCUj4KPEJSPjxCUj4KPElNRyBTUkM9Imh0dHA6 Ly9tYWlsLmljdS5hYy5rcjo4MC9jZ2ktYXV0aC9tYWlscmNwdC5jZ2k/dXNlcmlkPWRsZWUmbWFp bGRvbWFpbm5hbWU9aWN1LmFjLmtyJm1zZ2lkPTIwMDEwMTI2LkFBQTk4MDQ3NjA4NUBpY3UuYWMu a3IiPgo8L0ZPTlQ+CjwvQk9EWT48L0hUTUw+Cgo= ------=_NextPart_B6QZWYROQKIIQQAIA22DYLTE-- ------=_NextPart_RNB5OMA88BPHJUBGR2W6CZA0-- From owner-idn@ops.ietf.org Thu Jan 25 23:04:20 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16520 for ; Thu, 25 Jan 2001 23:04:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LzxC-000PA0-00 for idn-data@psg.com; Thu, 25 Jan 2001 19:53:38 -0800 Received: from arachnid.ehsco.com ([209.31.7.46] helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14LzxB-000P9t-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 19:53:38 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 686; Thu, 25 Jan 2001 19:53:35 -0800 Message-ID: <3A70F4BE.30289F2E@ehsco.com> Date: Thu, 25 Jan 2001 19:53:35 -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: Keith Moore CC: "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 References: <200101260000.TAA22356@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: > > > For extensive evidence that it's happening: > > that's not anything of the sort. you cited evidence that a few > energetic folks are implementing and modifying existing tools to > support UTF-8. > > that's a far cry from widespread adoption of UTF-8 by real users. I think it's pretty clear that UTF-8 is the direction that most environments are heading to, if they aren't there already. - Solaris 7 and higher use UTF-8 for the local (Unicode) interfaces - Windows 2000 and CE use Unicode and UTF-8 - MacOS 9 (or X?) and higher same - etc... don't discount the Linux i8n efforts either, it is an extreme likelihood at the very least if not a statement of direction End-user apps that support UTF-8 include Office 2000 and of course most of the modern web/mail front-ends -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Thu Jan 25 23:17:23 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16668 for ; Thu, 25 Jan 2001 23:17:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M0A9-000026-00 for idn-data@psg.com; Thu, 25 Jan 2001 20:07:01 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14M0A8-00001u-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 20:07:01 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA24660; Thu, 25 Jan 2001 23:06:47 -0500 (EST) Message-Id: <200101260406.XAA24660@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eric A. Hall" cc: Keith Moore , "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 In-reply-to: Your message of "Thu, 25 Jan 2001 19:53:35 PST." <3A70F4BE.30289F2E@ehsco.com> Date: Thu, 25 Jan 2001 23:06:47 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > I think it's pretty clear that UTF-8 is the direction that most > environments are heading to, if they aren't there already. no real argument about general direction. my point is that users who have an investment in existing tools and existing files using other charsets may not follow that lead as quickly as some imagine. MIME has been the obvious direction for email for about ten years, and it's amazing how many people are still using user agents that don't support it. Keith From owner-idn@ops.ietf.org Thu Jan 25 23:23:53 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16727 for ; Thu, 25 Jan 2001 23:23:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M08V-000Q0S-00 for idn-data@psg.com; Thu, 25 Jan 2001 20:05:19 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14M08U-000Q0L-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 20:05:18 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17933 for ; Thu, 25 Jan 2001 19:58:56 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20010126.AAA980476085@icu.ac.kr> References: <20010126.AAA980476085@icu.ac.kr> Date: Thu, 25 Jan 2001 20:05:11 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] San Diego Meeting Notes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11:45 AM +0900 1/26/01, dlee@icu.ac.kr wrote: >The problem is we don't know yet what the long term solution would be. >In that context, I'm not sure whether the proposed solution is a >solution for a short >term (it could lock us up longer than we expect as Klensin pointed >out) though I agree that the ACE-based approach is a simple solution >to allow users to use IDN with the current DNS protocol. Well, I certainly won't speak for John, but but I don't remember him speaking about a short-term solution locking us up. He said that an even half-successful short-term solution will make it less likely that users will pressure us to to a good long-term solution. He also warned strongly about any short-term solution that changes the DNS in a way that makes it hard to implement a long-term solution. I agree with both of those. The ACE-based solutions proposed so far will not change the DNS in a way that makes it hard to implement any long-term solution. The ACE-based presentation-layer solutions don't change the characters allowed or disallowed in host names (a through z, 0 through 9, hyphen), with the terribly minor exception of host names that begin with a particular weird prefix. Even in the presentation layer, these solutions don't prevent later presentation-layer changes for different encodings. Of the two themes of long-term DNS proposals so far (marked binary names such as UDNS or IDNE, or a radical change to the DNS such as a new class), neither is affected by a presentation-layer ACE-based solution, other than the desire for them will be slowed. It is easy to imagine that a long-term UTF8-based solution would completely coexist with an ACE-based solution in the presentation layer and on the wire, with no conflict at all. Even the directory-based solutions that have been discussed but not well documented would not be affected by an ACE-based solution, and in fact might be helped, because people will see that the Internet is truly international much sooner. (As you can tell, this is, so far, my preferred long-term solution.) Am I missing some significant effect that ACEs might have on other long-term solutions? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Jan 25 23:46:06 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17414 for ; Thu, 25 Jan 2001 23:46:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M0Uz-0001dd-00 for idn-data@psg.com; Thu, 25 Jan 2001 20:28:33 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 14M0Uz-0001dX-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 20:28:33 -0800 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21509; Thu, 25 Jan 2001 20:28:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA19633; Thu, 25 Jan 2001 20:28:30 -0800 (PST) Received: from sundrop.eng.sun.com (hobo182.EBay.Sun.COM [129.150.99.79]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0Q4SP9955886; Thu, 25 Jan 2001 20:28:26 -0800 (PST) Date: Thu, 25 Jan 2001 20:28:59 -0800 (PST) From: "Carl S. Gutekunst" Reply-To: "Carl S. Gutekunst" Subject: Re: [idn] UNIX moving to UTF-8 To: "Eric A. Hall" Cc: idn@ops.ietf.org In-Reply-To: "Your message with ID" <3A70F4BE.30289F2E@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk > - Windows 2000 and CE use Unicode and UTF-8 Again, the native character set of Windows 2000 is UCS-2, not UTF-8. There are a few applications that partially support UTF-8, notably Internet Explorer and Outlook Express, but that's only in some places, and only because a developer made a conscious decision to offer that support. Run-of-the-mill Windows APIs do not support UTF-8 and will not reliably pass it without damage. From owner-idn@ops.ietf.org Fri Jan 26 00:04:45 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17701 for ; Fri, 26 Jan 2001 00:04:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M0rs-0003IA-00 for idn-data@psg.com; Thu, 25 Jan 2001 20:52:12 -0800 Received: from arachnid.ehsco.com ([209.31.7.46] helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14M0rr-0003I3-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 20:52:11 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 688; Thu, 25 Jan 2001 20:52:07 -0800 Message-ID: <3A710276.1DC29180@ehsco.com> Date: Thu, 25 Jan 2001 20:52:06 -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: "Carl S. Gutekunst" CC: idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Carl S. Gutekunst" wrote: > > > - Windows 2000 and CE use Unicode and UTF-8 > > Again, the native character set of Windows 2000 is UCS-2, not UTF-8. > There are a few applications that partially support UTF-8, notably > Internet Explorer and Outlook Express, but that's only in some places, Their DNS implementation allows UTF-8 encoded names, so I assumed that the APIs for the network interfaces supported it as well. Mea culpa if this is not the case (I am left wondering how names get resolved if that is truly the situation however). > Run-of-the-mill Windows APIs do not support UTF-8 and will not > reliably pass it without damage. The interface to DNS would seem to be the important part for this group, and apparently it does support UTF-8. Good question to ask though, does Solaris' UTF-8 support extend to the resolver APIs? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Jan 26 00:18:26 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17939 for ; Fri, 26 Jan 2001 00:18:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M175-0004NM-00 for idn-data@psg.com; Thu, 25 Jan 2001 21:07:55 -0800 Received: from femail1.sdc1.sfba.home.com ([24.0.95.81]) by psg.com with esmtp (Exim 3.16 #1) id 14M174-0004KR-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 21:07:54 -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 <20010126050715.LRVC2917.femail1.sdc1.sfba.home.com@c1340594a>; Thu, 25 Jan 2001 21:07:15 -0800 Message-ID: <005301c08756$16be6e90$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Eric A. Hall" , "Keith Moore" Cc: "D. J. Bernstein" , References: <200101260000.TAA22356@astro.cs.utk.edu> <3A70F4BE.30289F2E@ehsco.com> Subject: Re: [idn] UNIX moving to UTF-8 Date: Thu, 25 Jan 2001 21:08:57 -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 People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, 32) is not as important, since they all can be converted to each other very efficiently and without loss. It is however an overstatement to say that all environments are headed towards UTF-8. Certainly Windows, JavaScript, and Java use UTF-16; these are not unimportant. I'm not sure about the Mac, but I believe they are also UTF-16. Mark ----- Original Message ----- From: "Eric A. Hall" To: "Keith Moore" Cc: "D. J. Bernstein" ; Sent: Thursday, January 25, 2001 19:53 Subject: Re: [idn] UNIX moving to UTF-8 > > Keith Moore wrote: > > > > > For extensive evidence that it's happening: > > > > that's not anything of the sort. you cited evidence that a few > > energetic folks are implementing and modifying existing tools to > > support UTF-8. > > > > that's a far cry from widespread adoption of UTF-8 by real users. > > I think it's pretty clear that UTF-8 is the direction that most > environments are heading to, if they aren't there already. > > - Solaris 7 and higher use UTF-8 for the local (Unicode) interfaces > - Windows 2000 and CE use Unicode and UTF-8 > - MacOS 9 (or X?) and higher same > - etc... don't discount the Linux i8n efforts either, it is an extreme > likelihood at the very least if not a statement of direction > > End-user apps that support UTF-8 include Office 2000 and of course most of > the modern web/mail front-ends > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > From owner-idn@ops.ietf.org Fri Jan 26 00:27:17 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18239 for ; Fri, 26 Jan 2001 00:27:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M1Ct-0004bC-00 for idn-data@psg.com; Thu, 25 Jan 2001 21:13:55 -0800 Received: from femail1.sdc1.sfba.home.com ([24.0.95.81]) by psg.com with esmtp (Exim 3.16 #1) id 14M1Cs-0004aw-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 21:13:54 -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 <20010126051315.LVVS2917.femail1.sdc1.sfba.home.com@c1340594a>; Thu, 25 Jan 2001 21:13:15 -0800 Message-ID: <008801c08756$ed23d6a0$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "James Seng/Personal" , "D. J. Bernstein" , References: <20010123233243.17988.qmail@cr.yp.to> <200101240227.VAA03438@astro.cs.utk.edu> <20010125204620.18613.qmail@cr.yp.to> <02eb01c08722$61a82060$32272dd4@jamessonyvaio> Subject: Re: [idn] UNIX moving to UTF-8 Date: Thu, 25 Jan 2001 21:14:57 -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 A huge number of people in non-English speaking countries are using Unicode, *and don't know it*. Anyone using Windows NT/2000, or Microsoft Office is, as well as many other products. Many websites use Unicode internally, and just convert to the user's codepage, etc. Mark ----- Original Message ----- From: "James Seng/Personal" To: "D. J. Bernstein" ; Sent: Thursday, January 25, 2001 14:58 Subject: Re: [idn] UNIX moving to UTF-8 > Dan, > > When is the last time you travel to non-English speaking country and ask > the people there when they are going to switch over to UTF-8? > > -James Seng > > ----- Original Message ----- > From: "D. J. Bernstein" > To: > Sent: Friday, January 26, 2001 4:46 AM > Subject: [idn] UNIX moving to UTF-8 > > > > Keith Moore writes: > > > your analysis assumes that most sites are or will be using UTF-8 > locally. > > > this seems like quite a stretch as it is very different from current > reality. > > > > For extensive evidence that it's happening: > > > > http://www.cl.cam.ac.uk/~mgk25/unicode.html > > ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html > > http://czyborra.com/utf/#UTF-8 > > > > ---Dan > > > > From owner-idn@ops.ietf.org Fri Jan 26 00:39:23 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18342 for ; Fri, 26 Jan 2001 00:39:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M1Sa-0005qE-00 for idn-data@psg.com; Thu, 25 Jan 2001 21:30:08 -0800 Received: from h00508b5474ca.ne.mediaone.net ([66.31.216.133] helo=BILL) by psg.com with esmtp (Exim 3.16 #1) id 14M1SZ-0005pv-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 21:30:07 -0800 Received: from localhost [127.0.0.1] by BILL with SMTPBeamer v3.19 ; Fri, 26 Jan 2001 00:29:01 -0500 Message-Id: <3.0.5.32.20010126002900.03b92c10@mail.nic.nu> X-Sender: bill@mail.nic.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Jan 2001 00:29:00 -0500 To: idn@ops.ietf.org From: "J. William Semich" Subject: Re: [idn] UNIX moving to UTF-8 In-Reply-To: References: <"Your message with ID" <3A70F4BE.30289F2E@ehsco.com> Mime-Version: 1.0 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 AAA18342 Microsoft is moving UNICODE/UTF-8 into many other of its applications and systems, and not just Exchange and IE: FROM http://www.microsoft.com/Office/ORK/2000/Five/70ct_15.htm The Microsoft Office 2000 MultiLanguage Pack includes plug-in language features that allow users to change the language of the user interface. When you use Office Web features in an international environment, you can do the following: Conduct Web Discussions in any available language All collaboration data is sent over the wire in Universal Character Set Transformation Format 8-bit (UTF-8). UTF-8 is an ISO standard for transmitting character codes for all languages. ------------------------- FROM http://www.microsoft.com/TechNet/win2000/dnsover.asp Unicode character support. While conventional DNS server implementations limit allowed characters to the set described in RFC 1123, this implementation of DNS accommodates a wider range of characters—including the UTF-8 character encoding (RFC 2044), a superset of ASCII and a translation of the UCS-2 (or Unicode) character encoding. This saves administrators the chore of renaming devices using a non-strict set of characters on a machine-by-machine basis. ------------------------------------ FROM http://msdn.microsoft.com/library/psdk/winui/richedit_9d80.htm Rich Edit 3.0 includes the following features in addition to the features provided by Rich Edit 2.0. ... UTF-8 RTF This is recommended for cutting, copying, and pasting operations. This file format is more compact than ordinary RTF, faster, and compatible with Unicode. And many more .... Bill Semich At 08:28 PM 1/25/01 -0800, Carl S. Gutekunst wrote: >> - Windows 2000 and CE use Unicode and UTF-8 > >Again, the native character set of Windows 2000 is UCS-2, not UTF-8. There are >a few applications that partially support UTF-8, notably Internet Explorer and >Outlook Express, but that's only in some places, and only because a developer >made a conscious decision to offer that support. Run-of-the-mill Windows APIs >do not support UTF-8 and will not reliably pass it without damage. > > > > > Bill Semich President and Founder WorldNames, Inc. http://www.worldnames.net bsemich@worldnames.net From owner-idn@ops.ietf.org Fri Jan 26 00:44:07 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18394 for ; Fri, 26 Jan 2001 00:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M1SQ-0005pM-00 for idn-data@psg.com; Thu, 25 Jan 2001 21:29:58 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14M1SO-0005lo-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 21:29:57 -0800 Message-ID: <003c01c0875a$5de578a0$82022b18@yec1.on.wave.home.com> From: "Edmon Chung" To: "Eric A. Hall" , "Keith Moore" Cc: "D. J. Bernstein" , References: <200101260000.TAA22356@astro.cs.utk.edu> <3A70F4BE.30289F2E@ehsco.com> Subject: Re: [idn] UNIX moving to UTF-8 Date: Fri, 26 Jan 2001 00:39:33 -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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While I am pro-non-ACE-as-final-solution, I must say that although UTF8 is being deployed readily, some implementations such as Win2000 as I have pointed out in my known issues document (http://www.openidn.org/issues.html), is sometimes a bit shaky especially when used to package DNS requests. Edmon > > Keith Moore wrote: > > > > > For extensive evidence that it's happening: > > > > that's not anything of the sort. you cited evidence that a few > > energetic folks are implementing and modifying existing tools to > > support UTF-8. > > > > that's a far cry from widespread adoption of UTF-8 by real users. > > I think it's pretty clear that UTF-8 is the direction that most > environments are heading to, if they aren't there already. > > - Solaris 7 and higher use UTF-8 for the local (Unicode) interfaces > - Windows 2000 and CE use Unicode and UTF-8 > - MacOS 9 (or X?) and higher same > - etc... don't discount the Linux i8n efforts either, it is an extreme > likelihood at the very least if not a statement of direction > > End-user apps that support UTF-8 include Office 2000 and of course most of > the modern web/mail front-ends > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Fri Jan 26 00:54:01 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18478 for ; Fri, 26 Jan 2001 00:54:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M1ha-0006qi-00 for idn-data@psg.com; Thu, 25 Jan 2001 21:45:38 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14M1hZ-0006qc-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 21:45:38 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA25663; Fri, 26 Jan 2001 00:45:32 -0500 (EST) Message-Id: <200101260545.AAA25663@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Davis" cc: "Eric A. Hall" , "Keith Moore" , "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 In-reply-to: Your message of "Thu, 25 Jan 2001 21:08:57 PST." <005301c08756$16be6e90$0c680b41@c1340594a> Date: Fri, 26 Jan 2001 00:45:32 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, > 32) is not as important, since they all can be converted to each other very > efficiently and without loss. And since an ACE is just another encoding of Unicode, you can add ACE to that set. > It is however an overstatement to say that all environments are headed > towards UTF-8. And if there's not a single preferred encoding of Unicode that's being widely supported, using ACE for IDNs makes about as much sense as anything. The fact that ACE doesn't happen to use the 0x80 bit doesn't strike me as a particularly good reason to rule it out - especially when (for a carefully-designed ACE) the encoding will often be more efficient than either UTF-16 or UTF-8. If UTF-8 is optimized for ASCII-compatibility, the C language (so that for instance NUL-terminated strings still work), and to minimize the amount of state that must be maintained while decoding; ACE can be optimized for space-efficiency, compatibility with protocols that were designed for ASCII-only DNS names, and (with nameprep) ease of comparison. It's not as if one is right and the other wrong. They are different encodings to accomodate different sets of transition issues. Keith From owner-idn@ops.ietf.org Fri Jan 26 01:17:27 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20074 for ; Fri, 26 Jan 2001 01:17:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M1wF-0007wO-00 for idn-data@psg.com; Thu, 25 Jan 2001 22:00:47 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14M1wE-0007wI-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 22:00:47 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id BAA25937; Fri, 26 Jan 2001 01:00:30 -0500 (EST) Message-Id: <200101260600.BAA25937@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Davis" cc: "James Seng/Personal" , "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 In-reply-to: Your message of "Thu, 25 Jan 2001 21:14:57 PST." <008801c08756$ed23d6a0$0c680b41@c1340594a> X-SUBJECT-MSG-FROM: "Mark Davis" Date: Fri, 26 Jan 2001 01:00:30 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > A huge number of people in non-English speaking countries are using Unicode, > *and don't know it*. Anyone using Windows NT/2000, or Microsoft Office is, > as well as many other products. Many websites use Unicode internally, and > just convert to the user's codepage, etc. sure. but just because someone is using microsoft office that happens to use some encoding of Unicode doesn't mean they can use it to edit a "plain text" config file that expects IDNs to be in UTF-8 format. From owner-idn@ops.ietf.org Fri Jan 26 02:02:43 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26876 for ; Fri, 26 Jan 2001 02:02:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M2gu-000BDp-00 for idn-data@psg.com; Thu, 25 Jan 2001 22:49:00 -0800 Received: from [203.126.116.228] (helo=mail.i-dns.net) by psg.com with esmtp (Exim 3.16 #1) id 14M2gs-000BDT-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 22:48:59 -0800 Received: from jamessonyvaio (unknown [212.45.39.77]) by mail.i-dns.net (Postfix) with SMTP id 4A3FFFFC04; Fri, 26 Jan 2001 14:48:46 +0800 (SGT) Message-ID: <003f01c08763$db1da8c0$4d272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Mark Davis" , "D. J. Bernstein" , References: <20010123233243.17988.qmail@cr.yp.to> <200101240227.VAA03438@astro.cs.utk.edu> <20010125204620.18613.qmail@cr.yp.to> <02eb01c08722$61a82060$32272dd4@jamessonyvaio> <008801c08756$ed23d6a0$0c680b41@c1340594a> Subject: Re: [idn] UNIX moving to UTF-8 Date: Fri, 26 Jan 2001 14:47:27 +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 Mark, I didnt argue about adoption of Unicode. Most people do use it without realising it. Yes. I am arguing about adoption of UTF-8. -James Seng ----- Original Message ----- From: "Mark Davis" To: "James Seng/Personal" ; "D. J. Bernstein" ; Sent: Friday, January 26, 2001 1:14 PM Subject: Re: [idn] UNIX moving to UTF-8 > A huge number of people in non-English speaking countries are using Unicode, > *and don't know it*. Anyone using Windows NT/2000, or Microsoft Office is, > as well as many other products. Many websites use Unicode internally, and > just convert to the user's codepage, etc. > > Mark > ----- Original Message ----- > From: "James Seng/Personal" > To: "D. J. Bernstein" ; > Sent: Thursday, January 25, 2001 14:58 > Subject: Re: [idn] UNIX moving to UTF-8 > > > > Dan, > > > > When is the last time you travel to non-English speaking country and ask > > the people there when they are going to switch over to UTF-8? > > > > -James Seng > > > > ----- Original Message ----- > > From: "D. J. Bernstein" > > To: > > Sent: Friday, January 26, 2001 4:46 AM > > Subject: [idn] UNIX moving to UTF-8 > > > > > > > Keith Moore writes: > > > > your analysis assumes that most sites are or will be using UTF-8 > > locally. > > > > this seems like quite a stretch as it is very different from current > > reality. > > > > > > For extensive evidence that it's happening: > > > > > > http://www.cl.cam.ac.uk/~mgk25/unicode.html > > > ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html > > > http://czyborra.com/utf/#UTF-8 > > > > > > ---Dan > > > > > > > > From owner-idn@ops.ietf.org Fri Jan 26 04:14:42 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03065 for ; Fri, 26 Jan 2001 04:14:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M4eA-000K2K-00 for idn-data@psg.com; Fri, 26 Jan 2001 00:54:18 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14M4e9-000Jy1-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 00:54:17 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA07288; Fri, 26 Jan 2001 00:53:58 -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 f0Q8rhh20594; Fri, 26 Jan 2001 00:53:43 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA13476; Fri, 26 Jan 2001 00:53:35 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3A710276.1DC29180@ehsco.com> References: <3A710276.1DC29180@ehsco.com> Date: Fri, 26 Jan 2001 09:43:18 +0100 To: "Eric A. Hall" , "Carl S. Gutekunst" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] UNIX moving to UTF-8 Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 20.52 -0800 01-01-25, Eric A. Hall wrote: >The interface to DNS would seem to be the important part for this group, >and apparently it does support UTF-8. No, DNS have very little to do with what this group is doing! This group is about internationalization of domain names. paf From owner-idn@ops.ietf.org Fri Jan 26 04:15:50 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03123 for ; Fri, 26 Jan 2001 04:15:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M4fs-000KAr-00 for idn-data@psg.com; Fri, 26 Jan 2001 00:56:04 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14M4fq-000K6n-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 00:56:02 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id AAA25103; Fri, 26 Jan 2001 00:53:25 -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 f0Q8rMo20509; Fri, 26 Jan 2001 00:53:22 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA13449; Fri, 26 Jan 2001 00:53:07 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 26 Jan 2001 09:37:45 +0100 To: "Brian W. Spolarich" , "Harald Alvestrand" , "Paul Hoffman / IMC" , "James Seng/Personal" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Who does what (Re: [idn] San Diego Meeting Notes) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 14.34 -0500 01-01-25, Brian W. Spolarich wrote: >The authors do not state in IDNA why they believe IDNA >is a better approach than IDNRA, which would be a helpful clarification of >the draft. My take is that it is better to do this in the application as the domainname is not only used in DNS but also in application protocols like SMTP. If we "only" fix the DNS protocol, and applications interaction with DNS, then we have yet another large problem to solve, and that is how to encode domainnames which are used as protocol parameters in each of the protocols using it. By doing nameprep and encoding in the application, the same "output" of this transformation can be used in all communication on the net. Also, if an application is not updated, regardless of how ugly leakage is, the user _can_ use the encoded string directly in the applications which today use as protocol parameter domainnames. I.e. I personally see this as an important feature just because replacement of software will not be as fast as some people might think. I can add some more text on why it is better to have transformation in the application, but not a comparison between the two proposals. They are just I-D's and when one of them (or none) is published, the other (or both) will go away, and the reference to the non-existing document is no longer making sense. Patrik From owner-idn@ops.ietf.org Fri Jan 26 04:24:41 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03066 for ; Fri, 26 Jan 2001 04:14:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14M4eL-000K2R-00 for idn-data@psg.com; Fri, 26 Jan 2001 00:54:29 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14M4eL-000K1y-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 00:54:29 -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 AAA25143; Fri, 26 Jan 2001 00:53:34 -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 f0Q8raI23003; Fri, 26 Jan 2001 00:53:36 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA13466; Fri, 26 Jan 2001 00:53:25 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010125201638.5735.qmail@cr.yp.to> References: <4.3.2.7.2.20010125003230.02ba5828@127.0.0.1> <20010125201638.5735.qmail@cr.yp.to> Date: Fri, 26 Jan 2001 09:40:00 +0100 To: "D. J. Bernstein" , idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Who does what (Re: [idn] San Diego Meeting Notes) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 20.16 +0000 01-01-25, D. J. Bernstein wrote: >For the record: My ACE upgrade list in http://cr.yp.to/proto/idn.html >takes this idea into account. It explicitly assumes that the argument to >gethostbyname() is in UTF-8. ACE conversion is needed in gethostbyname() >but not in applications that merely call gethostbyname(). > >But the list is still very long, because there are many other uses of >names. For example, DNS servers and SMTP servers and web servers need to >be upgraded for ACE, so that they can compare incoming ACE names to >UTF-8 names in configuration files. This is exactly why IDNA say that the encoding into an ACE should be done on a higher level in the application, and not in the resolver. paf From owner-idn@ops.ietf.org Fri Jan 26 10:01:20 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12077 for ; Fri, 26 Jan 2001 10:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MA4H-000I70-00 for idn-data@psg.com; Fri, 26 Jan 2001 06:41:37 -0800 Received: from femail11.sdc1.sfba.home.com ([24.0.95.107]) by psg.com with esmtp (Exim 3.16 #1) id 14MA4H-000I6u-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 06:41:37 -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 <20010126144136.XKTO11834.femail11.sdc1.sfba.home.com@c1340594a>; Fri, 26 Jan 2001 06:41:36 -0800 Message-ID: <004e01c087a6$3f5e00e0$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Keith Moore" , "Mark Davis" Cc: "Eric A. Hall" , "Keith Moore" , "D. J. Bernstein" , References: <200101260545.AAA25663@astro.cs.utk.edu> Subject: Re: [idn] UNIX moving to UTF-8 Date: Fri, 26 Jan 2001 06:42:45 -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 am not at all arguing against using an ACE. I agree that if the particular ACE in question is well-defined, and fits DNS constraints better than UTF-8, it is perfectly appropriate to use it. All I meant to point out is that (a) Unicode is in wide, and rapidly increasing use, (b) the particular form of Unicode that is used depends on the environment, it is not exclusively UTF-8. Mark ----- Original Message ----- From: "Keith Moore" To: "Mark Davis" Cc: "Eric A. Hall" ; "Keith Moore" ; "D. J. Bernstein" ; Sent: Thursday, January 25, 2001 21:45 Subject: Re: [idn] UNIX moving to UTF-8 > > People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, > > 32) is not as important, since they all can be converted to each other very > > efficiently and without loss. > > And since an ACE is just another encoding of Unicode, you can add ACE to > that set. > > > It is however an overstatement to say that all environments are headed > > towards UTF-8. > > And if there's not a single preferred encoding of Unicode that's being > widely supported, using ACE for IDNs makes about as much sense as anything. > The fact that ACE doesn't happen to use the 0x80 bit doesn't strike me > as a particularly good reason to rule it out - especially when (for a > carefully-designed ACE) the encoding will often be more efficient than > either UTF-16 or UTF-8. > > If UTF-8 is optimized for ASCII-compatibility, the C language (so > that for instance NUL-terminated strings still work), and to > minimize the amount of state that must be maintained while decoding; > ACE can be optimized for space-efficiency, compatibility with protocols > that were designed for ASCII-only DNS names, and (with nameprep) > ease of comparison. It's not as if one is right and the other wrong. > They are different encodings to accomodate different sets of > transition issues. > > Keith ... > A huge number of people in non-English speaking countries are using Unicode, > *and don't know it*. Anyone using Windows NT/2000, or Microsoft Office is, > as well as many other products. Many websites use Unicode internally, and > just convert to the user's codepage, etc. sure. but just because someone is using microsoft office that happens to use some encoding of Unicode doesn't mean they can use it to edit a "plain text" config file that expects IDNs to be in UTF-8 format. From owner-idn@ops.ietf.org Fri Jan 26 10:12:54 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12160 for ; Fri, 26 Jan 2001 10:12:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MAJb-000JIi-00 for idn-data@psg.com; Fri, 26 Jan 2001 06:57:27 -0800 Received: from [205.150.182.130] (helo=neteka.com) by psg.com with smtp (Exim 3.16 #1) id 14MAJa-000JIc-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 06:57:26 -0800 Message-ID: <004b01c087a8$fcda6300$1001a8c0@neteka.com> From: "Edmon" To: "Keith Moore" Cc: "Keith Moore" , , References: <200101252230.RAA21390@astro.cs.utk.edu> Subject: Re: [idn] What happens to 8bit DNS requests Date: Fri, 26 Jan 2001 10:02:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Thanks so much for your comment. I understand that it would be very hard to make it totally comprehensive, but at least it goes to show that even when OSs go UTF, it does not necessarily mean that DNS packets are correctly packaged in UTF. Which means that regardless of whether we choose UTF8/16/32 or even ACE most applications still have to be changed. However I do agree that, making UTF8/16/32 right should be easier than introduce yet another transformation. As we go along, we will continue to update the document on other applications. Meanwhile, I look to all of you all to add to the document if you already know of some irregularities regarding certain applications. Once its considerably comprehensive, I think it is valuable to be turned into a draft. Edmon > > I appreciate that there are different issues associated with UTF-8 or other > > non-ASCII approach, my main point is that even if we do go to IDNA, chances > > are that users unknowingly will still be sending multilingual dns requests > > through existing products that are non-IDNA aware. > > agreed. I think such a document could be useful, with the following caveats: > > - it would be very hard to make it sufficiently comprehensive that > it could serve as guidance for the design of an IDN solution, or > even to serve as a guide for users wanting to know which products > to buy. > > - it could take a large amount of time and energy > > > so I wouldn't mind at all seeing such a document produced, but I wouldn't > want to see such an effort divert resources from the primary work on IDNs, > or delay the primary work on IDNs. > > regarding the document you referenced (http://www.openidn.org/issues.html) > > - there are many more kinds of components affected than those that you > list (web browser, kernel, proxy server) > > - there are many more implementations of each of these kinds of components > than those that you list. > > - there are other platforms than those you list, with different issues > than these. > > all of which just illustrates that it's difficult to make this kind of > list comprehensive. > > - it's not clear exactly what is meant by "kernel" or how it comes into > play in the interaction between applications. > > - it appears to be difficult to isolate or even document the nature of > certain problems, especially given that the behavior may change > depending on program preferences, presense of proxies, choice of > platform, etc. > > - the issues you cite are good examples of how 8-bit characters get mangled > by some existing programs, but it's hard to know how to use this > information except to demonstrate that 8-bit characters get mangled > in a variety of ways. > > - the "solution" it recommends for squid is somewhat dubious: > it oversimplifies the problem of making IDNs work for the web. > > e.g. even if we adopted a UTF-8 on-the-wire solution for URLs in the > HTTP protocol (something that is not within the scope of this group > to decide), it's not sufficient to simply change these programs to be > 8-bit transparent for typed-in URLs. there are other interfaces > which contain URLs (web pages, config files, APIs used to control > the browser, cut-and-paste), nameprep would certainly have to be > applied to URLs in the browser so that local caching would work > (even if proxies and remote servers were also taught to do nameprep) From owner-idn@ops.ietf.org Fri Jan 26 10:34:37 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12398 for ; Fri, 26 Jan 2001 10:34:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MAgq-000L2D-00 for idn-data@psg.com; Fri, 26 Jan 2001 07:21:28 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.16 #1) id 14MAgo-000L26-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 07:21:27 -0800 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28572; Fri, 26 Jan 2001 07:21:16 -0800 (PST) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA19333; Fri, 26 Jan 2001 10:21:15 -0500 (EST) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24837; Fri, 26 Jan 2001 10:21:12 -0500 (EST) Message-ID: <3A719533.A292FD38@sun.com> Date: Fri, 26 Jan 2001 10:18:11 -0500 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Davis CC: "Eric A. Hall" , Keith Moore , "D. J. Bernstein" , idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 References: <200101260000.TAA22356@astro.cs.utk.edu> <3A70F4BE.30289F2E@ehsco.com> <005301c08756$16be6e90$0c680b41@c1340594a> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Java uses 16-bit Unicode internally and UTF-8 for most external exchanges (such as class files). This has been true since JDK 1.0. Support for adding other encodings has been present since JDK 1.1. Not that it makes much difference, but I wanted to set the record straight. -Steve Mark Davis wrote: > > People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, > 32) is not as important, since they all can be converted to each other very > efficiently and without loss. > > It is however an overstatement to say that all environments are headed > towards UTF-8. Certainly Windows, JavaScript, and Java use UTF-16; these are > not unimportant. I'm not sure about the Mac, but I believe they are also > UTF-16. > > Mark > > ----- Original Message ----- > From: "Eric A. Hall" > To: "Keith Moore" > Cc: "D. J. Bernstein" ; > Sent: Thursday, January 25, 2001 19:53 > Subject: Re: [idn] UNIX moving to UTF-8 > > > > > Keith Moore wrote: > > > > > > > For extensive evidence that it's happening: > > > > > > that's not anything of the sort. you cited evidence that a few > > > energetic folks are implementing and modifying existing tools to > > > support UTF-8. > > > > > > that's a far cry from widespread adoption of UTF-8 by real users. > > > > I think it's pretty clear that UTF-8 is the direction that most > > environments are heading to, if they aren't there already. > > > > - Solaris 7 and higher use UTF-8 for the local (Unicode) interfaces > > - Windows 2000 and CE use Unicode and UTF-8 > > - MacOS 9 (or X?) and higher same > > - etc... don't discount the Linux i8n efforts either, it is an extreme > > likelihood at the very least if not a statement of direction > > > > End-user apps that support UTF-8 include Office 2000 and of course most of > > the modern web/mail front-ends > > > > -- > > Eric A. Hall http://www.ehsco.com/ > > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > From owner-idn@ops.ietf.org Fri Jan 26 11:30:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13662 for ; Fri, 26 Jan 2001 11:30:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MBYc-000PA2-00 for idn-data@psg.com; Fri, 26 Jan 2001 08:17:02 -0800 Received: from femail11.sdc1.sfba.home.com ([24.0.95.107]) by psg.com with esmtp (Exim 3.16 #1) id 14MBYb-000P9i-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 08:17:01 -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 <20010126161701.XRPT11834.femail11.sdc1.sfba.home.com@c1340594a>; Fri, 26 Jan 2001 08:17:01 -0800 Message-ID: <012f01c087b3$938693a0$0c680b41@c1340594a> Reply-To: "Mark Davis" From: "Mark Davis" To: "Steve Hanna" , "Mark Davis" Cc: "Eric A. Hall" , "Keith Moore" , "D. J. Bernstein" , References: <200101260000.TAA22356@astro.cs.utk.edu> <3A70F4BE.30289F2E@ehsco.com> <005301c08756$16be6e90$0c680b41@c1340594a> <3A719533.A292FD38@sun.com> Subject: Re: [idn] UNIX moving to UTF-8 Date: Fri, 26 Jan 2001 08:18:10 -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 Just to set the record straight, - Java uses a variant of UTF-8 in class files. - That variant is not conformant to the UTF-8 spec. - It is only for internal use within the "compiled" class files and in serialization. (And while it is theoretically possible for a non-Java program to pick apart serialized Java classes, it would be extremely rare.) - UTF-8 is supported by Java for interchange, of course, but the API all uses UTF-16 interfaces. Mark ----- Original Message ----- From: "Steve Hanna" To: "Mark Davis" Cc: "Eric A. Hall" ; "Keith Moore" ; "D. J. Bernstein" ; Sent: Friday, January 26, 2001 07:18 Subject: Re: [idn] UNIX moving to UTF-8 > Java uses 16-bit Unicode internally and UTF-8 for most external > exchanges (such as class files). This has been true since JDK 1.0. > Support for adding other encodings has been present since JDK 1.1. Not > that it makes much difference, but I wanted to set the record straight. > > -Steve > > Mark Davis wrote: > > > > People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, > > 32) is not as important, since they all can be converted to each other very > > efficiently and without loss. > > > > It is however an overstatement to say that all environments are headed > > towards UTF-8. Certainly Windows, JavaScript, and Java use UTF-16; these are > > not unimportant. I'm not sure about the Mac, but I believe they are also > > UTF-16. > > > > Mark > > > > ----- Original Message ----- > > From: "Eric A. Hall" > > To: "Keith Moore" > > Cc: "D. J. Bernstein" ; > > Sent: Thursday, January 25, 2001 19:53 > > Subject: Re: [idn] UNIX moving to UTF-8 > > > > > > > > Keith Moore wrote: > > > > > > > > > For extensive evidence that it's happening: > > > > > > > > that's not anything of the sort. you cited evidence that a few > > > > energetic folks are implementing and modifying existing tools to > > > > support UTF-8. > > > > > > > > that's a far cry from widespread adoption of UTF-8 by real users. > > > > > > I think it's pretty clear that UTF-8 is the direction that most > > > environments are heading to, if they aren't there already. > > > > > > - Solaris 7 and higher use UTF-8 for the local (Unicode) interfaces > > > - Windows 2000 and CE use Unicode and UTF-8 > > > - MacOS 9 (or X?) and higher same > > > - etc... don't discount the Linux i8n efforts either, it is an extreme > > > likelihood at the very least if not a statement of direction > > > > > > End-user apps that support UTF-8 include Office 2000 and of course most of > > > the modern web/mail front-ends > > > > > > -- > > > Eric A. Hall http://www.ehsco.com/ > > > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > > > From owner-idn@ops.ietf.org Fri Jan 26 13:30:10 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17052 for ; Fri, 26 Jan 2001 13:30:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MDJz-0007L2-00 for idn-data@psg.com; Fri, 26 Jan 2001 10:10:03 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.16 #1) id 14MDJy-0007Ku-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 10:10:02 -0800 Received: from smtp2.sybase.com (sybgate2.sybase.com [130.214.88.21]) by inergen.sybase.com with ESMTP id KAA09429; Fri, 26 Jan 2001 10:10:08 -0800 (PST) Received: from olympus.sybase.com (olympus [130.214.160.74]) by smtp2.sybase.com with ESMTP id KAA14530; Fri, 26 Jan 2001 10:09:47 -0800 (PST) Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5) id KAA08632; Fri, 26 Jan 2001 10:09:47 -0800 (PST) Received: (from kenw@localhost) by birdie.sybase.com (8.8.8+Sun/8.8.8) id KAA01314; Fri, 26 Jan 2001 10:09:46 -0800 (PST) Date: Fri, 26 Jan 2001 10:09:46 -0800 (PST) From: Kenneth Whistler Message-Id: <200101261809.KAA01314@birdie.sybase.com> To: idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 Cc: kenw@sybase.com, mark@macchiato.com, ehall@ehsco.com, djb@cr.yp.to X-Sun-Charset: US-ASCII Sender: owner-idn@ops.ietf.org Precedence: bulk Keith Moore said: > > People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, > > 32) is not as important, since they all can be converted to each other very > > efficiently and without loss. > > And since an ACE is just another encoding of Unicode, you can add ACE to > that set. This was malarkey the first time it was stated, and it is still malarkey. UTF-8, UTF-16, and UTF-32 are official, standard encoding forms of the Unicode character encoding. ACE is a transformation encoding syntax (TES) -- *not* an encoding form. > The fact that ACE doesn't happen to use the 0x80 bit doesn't strike me > as a particularly good reason to rule it out - especially when (for a > carefully-designed ACE) the encoding will often be more efficient than > either UTF-16 or UTF-8. > > If UTF-8 is optimized for ASCII-compatibility, the C language (so > that for instance NUL-terminated strings still work), and to > minimize the amount of state that must be maintained while decoding; > ACE can be optimized for space-efficiency, compatibility with protocols > that were designed for ASCII-only DNS names, and (with nameprep) > ease of comparison. It's not as if one is right and the other wrong. > They are different encodings to accomodate different sets of > transition issues. I'm not opposed to the ACE proposals for solving the short-term IDN issue, but... UTF-8 is a general-purpose encoding form for open interchange of Unicode data is all kinds of contexts. It is also used as a general-purpose processing form in many systems. ACE is *not* general-purpose. It is a custom-tailored TES designed to meet the constraints of a particular protocol, and its use is very likely to be limited to that particular context. Arguing for an ACE-based solution for the IDN problem by rhetorically blurring the distinction does not seem to be a useful way forward to me. --Ken From owner-idn@ops.ietf.org Fri Jan 26 14:38:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19598 for ; Fri, 26 Jan 2001 14:38:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MEMM-000C7X-00 for idn-data@psg.com; Fri, 26 Jan 2001 11:16:34 -0800 Received: from ns.jck.com ([209.187.148.211] helo=A4.JCK.COM) by psg.com with esmtp (Exim 3.16 #1) id 14MEML-000C7P-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 11:16:33 -0800 Received: from r2.jck.com ("port 1053"@[209.187.148.221]) by a4.jck.com (PMDF V6.0-23 #44844) with ESMTPA id <0G7S00J27AV65W@a4.jck.com> for idn@ops.ietf.org; Fri, 26 Jan 2001 14:16:29 -0500 (EST) Date: Fri, 26 Jan 2001 10:29:12 -0500 From: John C Klensin Subject: Re: [idn] Re: Re: [idn] San Diego Meeting Notes In-reply-to: To: Paul Hoffman / IMC Cc: idn@ops.ietf.org Message-id: <1252408992.980504952@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.5 (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 Thursday, 25 January, 2001 08:52 -0800 "Paul Hoffman / IMC" wrote: > Could you clarify your reason for this? As long as the short > term presentation-layer solution doesn't force any design > change for the long-term solution, it seems that the two can be > unrelated. Further, having a short-term solution in place gives > people more time to figure out what the long term solution > should be, and will also give some valuable data about the > attributes of the names that need to be handled in the long > term solution. Paul, I would just remind you that, for Internet applications, once something is deployed that does the relevant job at least half-adequately (or even a bit less), and no matter how "short term" it is intended to be, our success level in replacing it with good (and "long term") solutions has been just about zero. Indeed, the only exceptions I can think of involve incremental improvements to the same protocol, not replacement by something new. john From owner-idn@ops.ietf.org Fri Jan 26 15:39:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20939 for ; Fri, 26 Jan 2001 15:39:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MFP5-000G57-00 for idn-data@psg.com; Fri, 26 Jan 2001 12:23:27 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14MFP4-000G51-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 12:23: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 PAA29727; Fri, 26 Jan 2001 15:23:22 -0500 (EST) Message-Id: <200101262023.PAA29727@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Kenneth Whistler cc: idn@ops.ietf.org, mark@macchiato.com, ehall@ehsco.com, djb@cr.yp.to Subject: Re: [idn] UNIX moving to UTF-8 In-reply-to: Your message of "Fri, 26 Jan 2001 10:09:46 PST." <200101261809.KAA01314@birdie.sybase.com> Date: Fri, 26 Jan 2001 15:23:22 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > > > People are clearly moving to Unicode. Exactly which UTF they choose (8, 16, > > > 32) is not as important, since they all can be converted to each other very > > > efficiently and without loss. > > > > And since an ACE is just another encoding of Unicode, you can add ACE to > > that set. > > This was malarkey the first time it was stated, and it is still malarkey. > > UTF-8, UTF-16, and UTF-32 are official, standard encoding forms of the > Unicode character encoding. > > ACE is a transformation encoding syntax (TES) -- *not* an encoding form. I didn't use the precise term "encoding form" I used the imprecise term "encoding". ACE most certainly is an encoding of Unicode. If adopted by IETF, ACE will also be an "official" "standard" - though not an ISO standard. If memory serves, neither Unicode nor UTF-8 started out in ISO either, so the fact that ACE didn't start there shouldn't be cause for concern. > I'm not opposed to the ACE proposals for solving the short-term IDN > issue, but... > > UTF-8 is a general-purpose encoding form for open interchange of > Unicode data is all kinds of contexts. It is also used as a general-purpose > processing form in many systems. UTF-8 certainly has wider applicability than ACE. However ACE is not designed to meet the constraints of *a* particular protocol, it is designed to meet the constraints of *several* protocols that use ASCII DNS names as protocol elements. Keith From owner-idn@ops.ietf.org Fri Jan 26 17:22:07 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23363 for ; Fri, 26 Jan 2001 17:22:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MGzR-000M8i-00 for idn-data@psg.com; Fri, 26 Jan 2001 14:05:05 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14MGzQ-000M6r-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 14:05:04 -0800 Received: (qmail 26005 invoked by uid 1001); 26 Jan 2001 22:02:12 -0000 Date: 26 Jan 2001 22:02:12 -0000 Message-ID: <20010126220212.25253.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: [idn] Interactions between short-term and long-term References: <20010126.AAA980476085@icu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC writes: > Am I missing some significant effect that ACEs might have on other > long-term solutions? Yes. If we allow ACE-based IDNs, then we'll have to keep them working during the subsequent transition to UTF-8. Consider, for example, franXais.com, but with c-cedilla in place of X. Someone registers the ACE version of this. We make the huge changes required for ACE. Users can then send mail to franXais.com. Then we switch to UTF-8. There's a transition period where some clients send ACE franXais.com and some clients send UTF-8 franXais.com. Both of these will have to work! The registrar and domain owner have to copy all their ACE data to UTF-8 data, and make subsequent changes in both forms. The costs of this duplication aren't present in the initial move to ACE. They also aren't present in a direct move to UTF-8. They're extra costs of a transition. An initial move doesn't have to keep old IDNs working; a transition does. ---Dan From owner-idn@ops.ietf.org Fri Jan 26 18:13:30 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24391 for ; Fri, 26 Jan 2001 18:13:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MHpb-000PPk-00 for idn-data@psg.com; Fri, 26 Jan 2001 14:58:59 -0800 Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14MHpa-000PPX-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 14:58:58 -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 WAA06310; Fri, 26 Jan 2001 22:55:05 GMT From: "Brian W. Spolarich" To: "D. J. Bernstein" , Subject: RE: [idn] Interactions between short-term and long-term Date: Fri, 26 Jan 2001 17:59:05 -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: <20010126220212.25253.qmail@cr.yp.to> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | Then we switch to UTF-8. There's a transition period where some clients | send ACE franXais.com and some clients send UTF-8 franXais.com. Both of | these will have to work! The registrar and domain owner have to copy all | their ACE data to UTF-8 data, and make subsequent changes in both forms. Seems like the nameserver could take care of this automagically if such a protocol extension were to be defined in the future. Meaning, in dumb pseudocode: foreach label (zone) { if ((label is ACE) and (auto_generate_utf8_flag is TRUE) ){ utf8_label = acetoutf8(label); load(label); load(utf8label); } elseif ((label is UTF8) and (auto_generate_ace_flag is TRUE)) { ace_label = utf8toace(label); load(label); load(ace_label); } else { load(label); } } This assumes that all labels have been nameprepped, although that checking could also be done if necessary before the data is loaded. -bws From owner-idn@ops.ietf.org Sat Jan 27 03:13:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14313 for ; Sat, 27 Jan 2001 03:13:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MQ7I-0005ku-00 for idn-data@psg.com; Fri, 26 Jan 2001 23:49:48 -0800 Received: from asadal.cs.pusan.ac.kr ([164.125.164.185]) by psg.com with esmtp (Exim 3.16 #1) id 14MQ7H-0005km-00 for idn@ops.ietf.org; Fri, 26 Jan 2001 23:49:47 -0800 Received: from localhost (gimgs@localhost) by asadal.cs.pusan.ac.kr (8.8.8+Sun/8.8.8) with ESMTP id QAA04593; Sat, 27 Jan 2001 16:46:42 +0900 (KST) Date: Sat, 27 Jan 2001 16:46:42 +0900 (KST) From: GIM Gyeongseog-KIM Kyongsok To: John C Klensin cc: Paul Hoffman / IMC , idn@ops.ietf.org Subject: [idn] short- vs. long-term solution In-Reply-To: <1252408992.980504952@localhost> 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 Fri, 26 Jan 2001, John C Klensin wrote: > --On Thursday, 25 January, 2001 08:52 -0800 "Paul Hoffman / IMC" > wrote: > > Paul, I would just remind you that, for Internet applications, > once something is deployed that does the relevant job at least > half-adequately (or even a bit less), and no matter how "short > term" it is intended to be, our success level in replacing it > with good (and "long term") solutions has been just about zero. i have nearly the same concern. > john ±è °æ¼®, ºÎ»ê´ë Á¤º¸ ÄÄÇ»ÅÍ °øÇкÎ; 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 Sat Jan 27 05:23:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14797 for ; Sat, 27 Jan 2001 05:23:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MSNa-000FNw-00 for idn-data@psg.com; Sat, 27 Jan 2001 02:14:46 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14MSNa-000FMa-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 02:14:46 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA01729 for ; Sat, 27 Jan 2001 02:14:30 -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 f0RAEKE24177 for ; Sat, 27 Jan 2001 02:14:20 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA14607 for ; Sat, 27 Jan 2001 02:14:13 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sat, 27 Jan 2001 10:57:41 +0100 To: From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [idn] Interactions between short-term and long-term Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 17.59 -0500 01-01-26, Brian W. Spolarich wrote: > This assumes that all labels have been nameprepped, although that checking >could also be done if necessary before the data is loaded. It can not because the use of the domainname in DNS is only one of the places where domainnames are in use. Client software have to do the right thing, including nameprep, and nothing else. Existing software can _not_ be used. Can someone remind me why I have to say this so many times on this list even though the design teams already have explained this? paf From owner-idn@ops.ietf.org Sat Jan 27 05:28:29 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14809 for ; Sat, 27 Jan 2001 05:28:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MSNW-000FNe-00 for idn-data@psg.com; Sat, 27 Jan 2001 02:14:42 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14MSNV-000FMC-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 02:14:41 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA01700 for ; Sat, 27 Jan 2001 02:14:25 -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 f0RAEAS06565 for ; Sat, 27 Jan 2001 02:14:10 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA14602 for ; Sat, 27 Jan 2001 02:14:08 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010126220212.25253.qmail@cr.yp.to> References: <20010126.AAA980476085@icu.ac.kr> <20010126220212.25253.qmail@cr.yp.to> Date: Sat, 27 Jan 2001 10:55:40 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Interactions between short-term and long-term Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 22.02 +0000 01-01-26, D. J. Bernstein wrote: >Paul Hoffman / IMC writes: >> Am I missing some significant effect that ACEs might have on other >> long-term solutions? > >Yes. If we allow ACE-based IDNs, then we'll have to keep them working >during the subsequent transition to UTF-8. Why should UTF-8 be the long-term solution? Why not UCS-2 or some other representation? >Consider, for example, franXais.com, but with c-cedilla in place of X. >Someone registers the ACE version of this. We make the huge changes >required for ACE. Users can then send mail to franXais.com. Consider another example where a user is using an existing software which doesn't do nameprep, and tries to send email to a user in a domain which include a character which is changed because of nameprep, what then happens? Dan you have still not answered my question on how much email you send and receive where the language in the mail is not english, and what languages you use? Knowing this will help knowing what scripts you actually have experience with, and based on that judge the importance of your input to this mailing list. Patrik From owner-idn@ops.ietf.org Sat Jan 27 06:58:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15106 for ; Sat, 27 Jan 2001 06:58:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MTpl-000L0T-00 for idn-data@psg.com; Sat, 27 Jan 2001 03:47:57 -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 14MTpk-000L0L-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 03:47:56 -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 f0RBfWD18066; Sat, 27 Jan 2001 12:41:32 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Sat, 27 Jan 2001 12:46:44 +0100 Message-ID: From: Karlsson Kent - keka To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , idn@ops.ietf.org Subject: RE: [idn] Interactions between short-term and long-term Date: Sat, 27 Jan 2001 12:44: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 GAA15106 > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Saturday, January 27, 2001 10:56 AM > To: idn@ops.ietf.org > Subject: Re: [idn] Interactions between short-term and long-term > > > At 22.02 +0000 01-01-26, D. J. Bernstein wrote: > >Paul Hoffman / IMC writes: > >> Am I missing some significant effect that ACEs might have on other > >> long-term solutions? > > > >Yes. If we allow ACE-based IDNs, then we'll have to keep them working > >during the subsequent transition to UTF-8. > > Why should UTF-8 be the long-term solution? Why not UCS-2 or some > other representation? UCS-2 should be regarded as outdated. 10646-2 (FDIS) and Unicode 3.1 adds characters on plane 01 and plane 02, that cannot be represented in UCS-2 (though they can be represented in UTF-16, as well as UTF-8 and UTF-32). Some of those characters may be used in IDNs. /kent k From owner-idn@ops.ietf.org Sat Jan 27 07:12:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15157 for ; Sat, 27 Jan 2001 07:12:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MU1w-000Lpn-00 for idn-data@psg.com; Sat, 27 Jan 2001 04:00:32 -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 14MU1u-000Lpg-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 04:00:30 -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 f0RBsCD78150; Sat, 27 Jan 2001 12:54:12 +0100 Received: by MSXSTH1.im.se with Internet Mail Service (5.5.2653.19) id ; Sat, 27 Jan 2001 12:59:24 +0100 Message-ID: From: Karlsson Kent - keka To: "'Keith Moore'" Cc: idn@ops.ietf.org Subject: RE: [idn] UNIX moving to UTF-8 Date: Sat, 27 Jan 2001 12:57:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08858.50A40540" Sender: owner-idn@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08858.50A40540 Content-Type: text/plain; charset="iso-8859-1" Keith, (regarding your reply to Ken:) I would suggest you read Ken's e-mail again, slowly. It's not that "ACE" didn't start out at ISO that is of concern. It's the fact that the "ACE"s have an extremenly narrow field if applicability (IDNs) that is of concern. UTF-{8,16,32} are general purpose encodings, that do and will find support in many, many places. "ACE"s can only be used for IDNs, and will never find widespread support for anything else. (regarding your reply to Mark:) There may be other reasons for not using MS Word for editing config files; but MS Word can indeed edit plain text files, in UTF-8 as well as many other encodings. However, to be able to edit config files with "ACE"s in them, there is no, and will never be any general purpose editor that supports that. You will need an editing tool (or auxilliary tool) SPECIFIC for IDN containing config file editing to be able to edit such a config file if you want to be able to read what is really encoded there in the "ACE"d IDNs. /kent k ---------------------------------------------------------------------------- ----- > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, January 26, 2001 7:01 AM > To: Mark Davis > Cc: James Seng/Personal; D. J. Bernstein; idn@ops.ietf.org > Subject: Re: [idn] UNIX moving to UTF-8 > > > > A huge number of people in non-English speaking countries > are using Unicode, > > *and don't know it*. Anyone using Windows NT/2000, or > Microsoft Office is, > > as well as many other products. Many websites use Unicode > internally, and > > just convert to the user's codepage, etc. > > sure. but just because someone is using microsoft office that happens > to use some encoding of Unicode doesn't mean they can use it to edit > a "plain text" config file that expects IDNs to be in UTF-8 format. ---------------------------------------------------------------------------- ----- > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, January 26, 2001 9:23 PM > To: Kenneth Whistler > Cc: idn@ops.ietf.org; mark@macchiato.com; ehall@ehsco.com; > djb@cr.yp.to > Subject: Re: [idn] UNIX moving to UTF-8 > > > > > > People are clearly moving to Unicode. Exactly which UTF > they choose (8, 16, > > > > 32) is not as important, since they all can be > converted to each other very > > > > efficiently and without loss. > > > > > > And since an ACE is just another encoding of Unicode, you > can add ACE to > > > that set. > > > > This was malarkey the first time it was stated, and it is > still malarkey. > > > > UTF-8, UTF-16, and UTF-32 are official, standard encoding > forms of the > > Unicode character encoding. > > > > ACE is a transformation encoding syntax (TES) -- *not* an > encoding form. > > I didn't use the precise term "encoding form" I used the > imprecise term > "encoding". > > ACE most certainly is an encoding of Unicode. If adopted by > IETF, ACE > will also be an "official" "standard" - though not an ISO standard. > If memory serves, neither Unicode nor UTF-8 started out in > ISO either, > so the fact that ACE didn't start there shouldn't be cause > for concern. > > > I'm not opposed to the ACE proposals for solving the short-term IDN > > issue, but... > > > > UTF-8 is a general-purpose encoding form for open interchange of > > Unicode data is all kinds of contexts. It is also used as a > general-purpose > > processing form in many systems. > > UTF-8 certainly has wider applicability than ACE. However ACE > is not designed to meet the constraints of *a* particular protocol, > it is designed to meet the constraints of *several* protocols that > use ASCII DNS names as protocol elements. > > Keith > ------_=_NextPart_001_01C08858.50A40540 Content-Type: text/html; charset="iso-8859-1" RE: [idn] UNIX moving to UTF-8

Keith,

(regarding your reply to Ken:)
I would suggest you read Ken's e-mail again, slowly.

It's not that "ACE" didn't start out at ISO that is of concern.
It's the fact that the "ACE"s have an extremenly narrow field
if applicability (IDNs) that is of concern.  UTF-{8,16,32} are
general purpose encodings, that do and will find support
in many, many places.  "ACE"s can only be used for IDNs,
and will never find widespread support for anything else.

(regarding your reply to Mark:)
There may be other reasons for not using MS Word for editing config
files; but MS Word can indeed edit plain text files, in UTF-8 as well
as many other encodings.

However, to be able to edit config files with "ACE"s in them, there
is no, and will never be any general purpose editor that supports that.
You will need an editing tool (or auxilliary tool) SPECIFIC for IDN
containing config file editing to be able to edit such a config file if
you want to be able to read what is really encoded there in the
"ACE"d IDNs.


                /kent k

---------------------------------------------------------------------------------

> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: Friday, January 26, 2001 7:01 AM
> To: Mark Davis
> Cc: James Seng/Personal; D. J. Bernstein; idn@ops.ietf.org
> Subject: Re: [idn] UNIX moving to UTF-8
>
>
> > A huge number of people in non-English speaking countries
> are using Unicode,
> > *and don't know it*. Anyone using Windows NT/2000, or
> Microsoft Office is,
> > as well as many other products. Many websites use Unicode
> internally, and
> > just convert to the user's codepage, etc.
>
> sure.  but just because someone is using microsoft office that happens
> to use some encoding of Unicode doesn't mean they can use it to edit
> a "plain text" config file that expects IDNs to be in UTF-8 format.

---------------------------------------------------------------------------------
> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: Friday, January 26, 2001 9:23 PM
> To: Kenneth Whistler
> Cc: idn@ops.ietf.org; mark@macchiato.com; ehall@ehsco.com;
> djb@cr.yp.to
> Subject: Re: [idn] UNIX moving to UTF-8
>
>
> > > > People are clearly moving to Unicode. Exactly which UTF
> they choose (8, 16,
> > > > 32) is not as important, since they all can be
> converted to each other very
> > > > efficiently and without loss.
> > >
> > > And since an ACE is just another encoding of Unicode, you
> can add ACE to
> > > that set.
> >
> > This was malarkey the first time it was stated, and it is
> still malarkey.
> >
> > UTF-8, UTF-16, and UTF-32 are official, standard encoding
> forms of the
> > Unicode character encoding.
> >
> > ACE is a transformation encoding syntax (TES) -- *not* an
> encoding form.
>
> I didn't use the precise term "encoding form" I used the
> imprecise term
> "encoding". 
>
> ACE most certainly is an encoding of Unicode.  If adopted by
> IETF, ACE
> will also be an "official" "standard" - though not an ISO standard. 
> If memory serves, neither Unicode nor UTF-8 started out in
> ISO either,
> so the fact that ACE didn't start there shouldn't be cause
> for concern.
>
> > I'm not opposed to the ACE proposals for solving the short-term IDN
> > issue, but...
> >
> > UTF-8 is a general-purpose encoding form for open interchange of
> > Unicode data is all kinds of contexts. It is also used as a
> general-purpose
> > processing form in many systems.
>
> UTF-8 certainly has wider applicability than ACE.  However ACE
> is not designed to meet the constraints of *a* particular protocol,
> it is designed to meet the constraints of *several* protocols that
> use ASCII DNS names as protocol elements.
>
> Keith
>

------_=_NextPart_001_01C08858.50A40540-- From owner-idn@ops.ietf.org Sat Jan 27 11:29:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16745 for ; Sat, 27 Jan 2001 11:29:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MXwt-000AIA-00 for idn-data@psg.com; Sat, 27 Jan 2001 08:11:35 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.16 #1) id 14MXws-000AEg-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 08:11:34 -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 IAA20674 for ; Sat, 27 Jan 2001 08:11:06 -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 f0RGB7R14799 for ; Sat, 27 Jan 2001 08:11:07 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA29321 for ; Sat, 27 Jan 2001 08:10:48 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sat, 27 Jan 2001 17:07:28 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [idn] Interactions between short-term and long-term Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12.44 +0100 01-01-27, Karlsson Kent - keka wrote: >UCS-2 should be regarded as outdated. 10646-2 (FDIS) and Unicode 3.1 >adds characters on plane 01 and plane 02, that cannot be represented >in UCS-2 (though they can be represented in UTF-16, as well as UTF-8 >and UTF-32). Some of those characters may be used in IDNs. Understood, but my point was that I didn't see that we should take for granted that UTF-8 is what is to be used if not ACE is used. paf From owner-idn@ops.ietf.org Sat Jan 27 11:29:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16756 for ; Sat, 27 Jan 2001 11:29:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MXx1-000AIL-00 for idn-data@psg.com; Sat, 27 Jan 2001 08:11:43 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14MXx1-000AFu-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 08:11:43 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04432 for ; Sat, 27 Jan 2001 08:11:27 -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 f0RGBGX14839 for ; Sat, 27 Jan 2001 08:11:16 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA29382 for ; Sat, 27 Jan 2001 08:11:07 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sat, 27 Jan 2001 17:10:23 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [idn] UNIX moving to UTF-8 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 12.57 +0100 01-01-27, Karlsson Kent - keka wrote: >However, to be able to edit config files with "ACE"s in them, there >is no, and will never be any general purpose editor that supports that. >You will need an editing tool (or auxilliary tool) SPECIFIC for IDN >containing config file editing to be able to edit such a config file if >you want to be able to read what is really encoded there in the >"ACE"d IDNs. You don't only need the ACE encoding but also the nameprep algorithm. So, specific tools _will_ be needed, just as special applications which use IDN. And, these special tools will be needed regardless of ACE or UTF-8. I think that that is the point Keith (and myself) tries to make. With the introduction of IDN, we can no longer "just" edit the config files in whatever applications. So, existing applications can not be used. We need new tools. paf From owner-idn@ops.ietf.org Sat Jan 27 13:07:07 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17214 for ; Sat, 27 Jan 2001 13:07:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MZWM-000G8K-00 for idn-data@psg.com; Sat, 27 Jan 2001 09:52:18 -0800 Received: from df-inet1.exchange.microsoft.com ([131.107.8.8] helo=DF-INET-1.dogfoodinternet.com) by psg.com with esmtp (Exim 3.16 #1) id 14MZWL-000G4o-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 09:52:17 -0800 Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Sat, 27 Jan 2001 09:23:29 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 27 Jan 2001 09:24:14 -0800 (Pacific Standard Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Sat, 27 Jan 2001 09:24:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4633.0 content-class: urn:content-classes:message Subject: RE: [idn] UNIX moving to UTF-8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 27 Jan 2001 09:24:13 -0800 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E045BA985@DF-SCRAPPY.platinum.corp.microsoft.com> Thread-Topic: [idn] UNIX moving to UTF-8 Thread-Index: AcCIW7ekzMMrzv3qRY6S4xr+Go9RdwAKeCkQ From: "Russ Rolfe" To: "Karlsson Kent - keka" , "Keith Moore" Cc: X-OriginalArrivalTime: 27 Jan 2001 17:24:14.0214 (UTC) FILETIME=[F82D9A60:01C08885] Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17214 > There may be other reasons for not using MS Word for editing config > files; but MS Word can indeed edit plain text files, in UTF-8 as well > as many other encodings. Hey even Notepad on Windows 2000 edits UTF-8 files. Regards, Russ -----Original Message----- From: Karlsson Kent - keka [mailto:keka@im.se] Sent: Saturday, January 27, 2001 3:57 AM To: 'Keith Moore' Cc: idn@ops.ietf.org Subject: RE: [idn] UNIX moving to UTF-8 Keith, (regarding your reply to Ken:) I would suggest you read Ken's e-mail again, slowly. It's not that "ACE" didn't start out at ISO that is of concern. It's the fact that the "ACE"s have an extremenly narrow field if applicability (IDNs) that is of concern. UTF-{8,16,32} are general purpose encodings, that do and will find support in many, many places. "ACE"s can only be used for IDNs, and will never find widespread support for anything else. (regarding your reply to Mark:) There may be other reasons for not using MS Word for editing config files; but MS Word can indeed edit plain text files, in UTF-8 as well as many other encodings. However, to be able to edit config files with "ACE"s in them, there is no, and will never be any general purpose editor that supports that. You will need an editing tool (or auxilliary tool) SPECIFIC for IDN containing config file editing to be able to edit such a config file if you want to be able to read what is really encoded there in the "ACE"d IDNs. /kent k ------------------------------------------------------------------------ --------- > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, January 26, 2001 7:01 AM > To: Mark Davis > Cc: James Seng/Personal; D. J. Bernstein; idn@ops.ietf.org > Subject: Re: [idn] UNIX moving to UTF-8 > > > > A huge number of people in non-English speaking countries > are using Unicode, > > *and don't know it*. Anyone using Windows NT/2000, or > Microsoft Office is, > > as well as many other products. Many websites use Unicode > internally, and > > just convert to the user's codepage, etc. > > sure. but just because someone is using microsoft office that happens > to use some encoding of Unicode doesn't mean they can use it to edit > a "plain text" config file that expects IDNs to be in UTF-8 format. ------------------------------------------------------------------------ --------- > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, January 26, 2001 9:23 PM > To: Kenneth Whistler > Cc: idn@ops.ietf.org; mark@macchiato.com; ehall@ehsco.com; > djb@cr.yp.to > Subject: Re: [idn] UNIX moving to UTF-8 > > > > > > People are clearly moving to Unicode. Exactly which UTF > they choose (8, 16, > > > > 32) is not as important, since they all can be > converted to each other very > > > > efficiently and without loss. > > > > > > And since an ACE is just another encoding of Unicode, you > can add ACE to > > > that set. > > > > This was malarkey the first time it was stated, and it is > still malarkey. > > > > UTF-8, UTF-16, and UTF-32 are official, standard encoding > forms of the > > Unicode character encoding. > > > > ACE is a transformation encoding syntax (TES) -- *not* an > encoding form. > > I didn't use the precise term "encoding form" I used the > imprecise term > "encoding". > > ACE most certainly is an encoding of Unicode. If adopted by > IETF, ACE > will also be an "official" "standard" - though not an ISO standard. > If memory serves, neither Unicode nor UTF-8 started out in > ISO either, > so the fact that ACE didn't start there shouldn't be cause > for concern. > > > I'm not opposed to the ACE proposals for solving the short-term IDN > > issue, but... > > > > UTF-8 is a general-purpose encoding form for open interchange of > > Unicode data is all kinds of contexts. It is also used as a > general-purpose > > processing form in many systems. > > UTF-8 certainly has wider applicability than ACE. However ACE > is not designed to meet the constraints of *a* particular protocol, > it is designed to meet the constraints of *several* protocols that > use ASCII DNS names as protocol elements. > > Keith > From owner-idn@ops.ietf.org Sat Jan 27 13:51:18 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17419 for ; Sat, 27 Jan 2001 13:51:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MaJ4-000J46-00 for idn-data@psg.com; Sat, 27 Jan 2001 10:42:38 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14MaJ3-000J0U-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 10:42:38 -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 KAA13150; Sat, 27 Jan 2001 10:42:10 -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 f0RIfwf09132; Sat, 27 Jan 2001 10:41:58 -0800 (PST) Received: from [193.0.4.72] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA09489; Sat, 27 Jan 2001 10:41:07 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <766EFCAA12CB514CAC64D8C440F5A50E045BA985@DF-SCRAPPY.platinum.corp.microso ft.com> References: <766EFCAA12CB514CAC64D8C440F5A50E045BA985@DF-SCRAPPY.platinum.corp.microso ft.com> Date: Sat, 27 Jan 2001 19:40:13 +0100 To: "Russ Rolfe" , "Karlsson Kent - keka" , "Keith Moore" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [idn] UNIX moving to UTF-8 Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 09.24 -0800 01-01-27, Russ Rolfe wrote: > > There may be other reasons for not using MS Word for editing config >> files; but MS Word can indeed edit plain text files, in UTF-8 as well >> as many other encodings. > >Hey even Notepad on Windows 2000 edits UTF-8 files. Does it do nameprep? paf From owner-idn@ops.ietf.org Sat Jan 27 14:06:02 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17598 for ; Sat, 27 Jan 2001 14:06:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MaX4-000Jsi-00 for idn-data@psg.com; Sat, 27 Jan 2001 10:57:06 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14MaX3-000Jsc-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 10:57:05 -0800 Received: (qmail 29216 invoked by uid 1001); 27 Jan 2001 18:57:26 -0000 Date: 27 Jan 2001 18:57:25 -0000 Message-ID: <20010127185725.28976.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Interactions between short-term and long-term References: <20010126220212.25253.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 Brian W. Spolarich writes: [ copying all ACE data to UTF-8 data during a transition ] > Seems like the nameserver could take care of this automagically No! It isn't just the DNS server. You're making the same old ACE mistake of failing to look at all the ways that names are used. Example: The domain owner will have the ACE franXais.com in his mail server's configuration files, but he has to start accepting mail for the UTF-8 franXais.com too. ---Dan From owner-idn@ops.ietf.org Sat Jan 27 15:07:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18087 for ; Sat, 27 Jan 2001 15:07:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MbTj-000NVp-00 for idn-data@psg.com; Sat, 27 Jan 2001 11:57:43 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14MbTi-000NVi-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 11:57:42 -0800 Received: (qmail 32246 invoked by uid 1001); 27 Jan 2001 19:57:56 -0000 Date: 27 Jan 2001 19:57:56 -0000 Message-ID: <20010127195756.26554.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: [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 Patrik writes: > With the introduction of IDN, we can no longer "just" edit the config > files in whatever applications. The worst case---for places like Japan, where we've heard that you can't even type a dot without special effort---is that the operating system needs ONE domain-name-typing tool as part of the keyboard interface. I'm explicitly assuming that we _won't_ allow names needing nameprep in configuration files. Bad names disappear as soon as they leave the keyboard. That's fast nameprep. The changes are isolated inside the keyboard interface. You're implicitly assuming that we _will_ allow names needing nameprep in configuration files. That's slow nameprep. It's horribly expensive. Hundreds of programs will need to learn about nameprep. ---Dan From owner-idn@ops.ietf.org Sat Jan 27 15:41:22 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18169 for ; Sat, 27 Jan 2001 15:41:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Mbsn-000P6F-00 for idn-data@psg.com; Sat, 27 Jan 2001 12:23:37 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14Mbsn-000OzY-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 12:23:37 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA02984 for ; Sat, 27 Jan 2001 12:23:21 -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 f0RKNAY25964 for ; Sat, 27 Jan 2001 12:23:10 -0800 (PST) Received: from [10.0.1.29] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA16395 for ; Sat, 27 Jan 2001 12:23:02 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010127195756.26554.qmail@cr.yp.to> References: <20010127195756.26554.qmail@cr.yp.to> Date: Sat, 27 Jan 2001 21:22:48 +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 19.57 +0000 01-01-27, D. J. Bernstein wrote: >I'm explicitly assuming that we _won't_ allow names needing nameprep in >configuration files. Bad names disappear as soon as they leave the >keyboard. That's fast nameprep. The changes are isolated inside the >keyboard interface. > >You're implicitly assuming that we _will_ allow names needing nameprep >in configuration files. That's slow nameprep. It's horribly expensive. >Hundreds of programs will need to learn about nameprep. No, you misunderstand me. We talk about exactly the same thing. We need something between the keyboard and the config file which do the nameprep, so never non-nameprepped things end up in configuration files. That's the whole idea with IDNA. Do nameprep as "close" to the keyboard as possible (and the reverse when displaying). paf From owner-idn@ops.ietf.org Sat Jan 27 21: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 VAA19370 for ; Sat, 27 Jan 2001 21:24:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Mh8M-000AtI-00 for idn-data@psg.com; Sat, 27 Jan 2001 18:00:02 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.16 #1) id 14Mh8L-000At6-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 18:00:01 -0800 Received: from CLASSIC.viagenie.qc.ca (1Cust191.tnt1.santa-clara2.ca.da.uu.net [63.59.192.191]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f0S29Md74439; Sat, 27 Jan 2001 21:09:23 -0500 (EST) X-Accept-Language: fr,en,es Message-Id: <5.0.2.1.1.20010127180444.043deeb8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 27 Jan 2001 18:05:56 -0500 To: Patrik Fältström , idn@ops.ietf.org From: Marc Blanchet Subject: Re: [idn] Fast nameprep vs. slow nameprep In-Reply-To: References: <20010127195756.26554.qmail@cr.yp.to> <20010127195756.26554.qmail@cr.yp.to> 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/À 21:22 2001-01-27 +0100, Patrik Fältström you wrote/vous écriviez: >At 19.57 +0000 01-01-27, D. J. Bernstein wrote: >>I'm explicitly assuming that we _won't_ allow names needing nameprep in >>configuration files. Bad names disappear as soon as they leave the >>keyboard. That's fast nameprep. The changes are isolated inside the >>keyboard interface. >> >>You're implicitly assuming that we _will_ allow names needing nameprep >>in configuration files. That's slow nameprep. It's horribly expensive. >>Hundreds of programs will need to learn about nameprep. > >No, you misunderstand me. We talk about exactly the same thing. We need >something between the keyboard and the config file which do the nameprep, >so never non-nameprepped things end up in configuration files. well, we hope so, but reality will probably be not that perfect. Marc. >That's the whole idea with IDNA. Do nameprep as "close" to the keyboard as >possible (and the reverse when displaying). > > paf > Marc Blanchet Viagénie 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 Sat Jan 27 23:27:54 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21598 for ; Sat, 27 Jan 2001 23:27:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MjCT-000DWP-00 for idn-data@psg.com; Sat, 27 Jan 2001 20:12:25 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14MjCS-000DVz-00 for idn@ops.ietf.org; Sat, 27 Jan 2001 20:12:24 -0800 Received: (qmail 12383 invoked by uid 1001); 28 Jan 2001 04:12:37 -0000 Date: 28 Jan 2001 04:12:37 -0000 Message-ID: <20010128041237.15447.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: <20010127195756.26554.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 Patrik writes: > We need something between the keyboard and the config file which do the > nameprep, so never non-nameprepped things end up in configuration files. I'm glad you agree. So why do you keep claiming that (for example) BIND and djbdns and Sendmail and qmail need to learn about nameprep? ---Dan From owner-idn@ops.ietf.org Sun Jan 28 04:55:43 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07437 for ; Sun, 28 Jan 2001 04:55:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MoDY-000KeU-00 for idn-data@psg.com; Sun, 28 Jan 2001 01:33:52 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14MoDY-000KdG-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 01:33:52 -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 BAA20568 for ; Sun, 28 Jan 2001 01:33:33 -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 f0S9XLI13319 for ; Sun, 28 Jan 2001 01:33:21 -0800 (PST) Received: from [10.0.1.29] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id BAA25278 for ; Sun, 28 Jan 2001 01:33:15 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010128041237.15447.qmail@cr.yp.to> References: <20010127195756.26554.qmail@cr.yp.to> <20010128041237.15447.qmail@cr.yp.to> Date: Sun, 28 Jan 2001 10:25:32 +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="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 04.12 +0000 01-01-28, D. J. Bernstein wrote: >Patrik writes: >> We need something between the keyboard and the config file which do the >> nameprep, so never non-nameprepped things end up in configuration files. > >I'm glad you agree. So why do you keep claiming that (for example) BIND >and djbdns and Sendmail and qmail need to learn about nameprep? I don't. I have been talking about ACE v.s. UTF-8 (which is completely independent on where nameprep is done), and claim that IF we do nameprep and ACE in whatever tools that exists between the user and the software which handle the application protocols, then no changes are needed in the software you mention. See the idna spec which myself and Paul has written. The main idea in that spec is that you do nameprep and encoding as "high" up in the protocol stack as possible, as the nameprepped encoded domainname can be easilly reused in all protocols without any changes what so ever in qmail, sendmail, bind, djbdns etc. It's even the case that the existing webpages which some people have created (or separate software) which converts between whatever charset one use natively and encoded nameprep is used, so the user know the ace encoded nameprepped string, then that string can be used in all existing software. Ugly, but doable. I said one day on this list: At 09.24 +0100 01-01-06, Patrik Fältström wrote: >I.e. I could register one day maybe: > > fältström.com > >...but could also on my buissness card have (if the ACE ends up being RACE): > > bq--abtoi3duon2hf5tn .com > >Yes, it looks ugly, it explicitly is leakage which we all hate, but, >it makes it possible for people with non-IDN software to access the >domain. Of course, I can in parallell have a domain which is >"faltstrom.com" or whatever, but I might think that my customers if >I help them that way never update their software. I.e. I _WANT_ >people to be able to use "fältström.com" probably, so I would only >help them to some degree, and that might be to give them the ace >encoding in paralel with the real name. paf From owner-idn@ops.ietf.org Sun Jan 28 05:04:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07467 for ; Sun, 28 Jan 2001 05:04:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MoWa-000L7W-00 for idn-data@psg.com; Sun, 28 Jan 2001 01:53:32 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14MoWZ-000L7P-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 01:53:32 -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 f0S9rP413364; Sun, 28 Jan 2001 10:53:25 +0100 (MET) Message-Id: <200101280953.f0S9rP413364@malmo.trab.se> Date: Sun, 28 Jan 2001 10:52:23 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] Interactions between short-term and long-term To: paf@cisco.com, idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GZY+nEKevHhaJi2NllygPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Patrik wrote: >>Consider, for example, franXais.com, but with c-cedilla in place of X. >>Someone registers the ACE version of this. We make the huge changes >>required for ACE. Users can then send mail to franXais.com. > >Consider another example where a user is using an existing software >which doesn't do nameprep, and tries to send email to a user in a >domain which include a character which is changed because of >nameprep, what then happens? > It works without problems. Both DNS-servers and e-mail MTAs understand how to compare domain names. Patrik is right in saying that DNS is not the only place where domain names must be compared and therefore not the only place where knowledge how to match domain names must exist. Even existing software of today do not do this correctely. A domain name must be matched case insensitivly, but a lot of programs (Unix have a lot of them) do not. But everybody do not have to understand "nameprep"!! The basics for interoperability of text data is to agree on character to code point mapping and normalisation. And normalisation means to use ONE representation of a character instead of like Unicode allow many variations. A good base would be UCS normalised using Unicode form C (or maybe KC). All programs should use this, otherwise interoperability will fail. Within text data some parts will be host names, domain labels or other DNS data. You cannot restrict input on these parts not mangle the characters (like converting to lower case). Just think of a text editor where it recognises I am typing a host name in the middle of some text and starts messing around. No, the basic text input can do normalisation but not full "nameprep". And when I edit a zone file, it will not have "namepreped" names. It will be in normal text data format. It is the responsibility of the DNS server to reject loading of names that have illegal characters (though I do not know how it is going to know what names are host names) and to apply "domain name matching rules" when comparing domain names. A DNS server should not mangle the names by doing forced conversion to lower case. If every program knows "nameprep" they will know how to match names. If we really want the world to get an easy start on interoperability on text data, we should at protocol level use something like UCS normalised using form C and encoded using UTF-8 (or UCS-2 or UCS-4). And the for DNS use, define a standard library that can be used in both DNS servers and in clients that can take a name in normalised text form and compare them. Doing like "nameprep" wants, by converting a name into a representation that can be used compare domain names by binary matching, is totally wrong for me. In a way it is like the ACE versus UTF-8 debate, ACE and "nameprep" introduces a special form on text intermixed with normal formatted text. Dan From owner-idn@ops.ietf.org Sun Jan 28 05:22:10 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07496 for ; Sun, 28 Jan 2001 05:22:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Mome-000LUu-00 for idn-data@psg.com; Sun, 28 Jan 2001 02:10:08 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14Momd-000LUm-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 02:10:07 -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 f0SAA5415955 for ; Sun, 28 Jan 2001 11:10:05 +0100 (MET) Message-Id: <200101281010.f0SAA5415955@malmo.trab.se> Date: Sun, 28 Jan 2001 11:09:03 +0100 (MET) From: Dan Reply-To: Dan Subject: [idn] Some other aspects To: idn@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GOEcMKhned14gfyEEYekwA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk We are very focused on host names, but maybe we should think a little broader. Let us think we have reached a time where all protocols use UTF-8. And your system works with and uses UTF-8 (or other form of UCS). Still, it will not be able to display all characters in UCS (and it might not even be wanted). What is going to happen with text that cannot be displayed? For a domain name an ACE could be used, but why not use a single standard form for all text? One easy way could be to do like: abc\uXXXXef\UXXXXXXXXgh\xXXij. Where \uXXXX represents 16-bit UCS value as hex in XXXX and the orther two for 31-bit and 8-bit UCS-values. All programs could use this way. There is no need to use something like an ACE to make it compact and fit some ASCII world. It would be much simple than like now having ACE, quoted-printable, %-encoding and probably some more special encodings. What I want to say with the above is that, yes UTF-8 (UCS) is fine, but it will not make all of UCS be displayable everywhere so we still need a way to present non-displayable characters to the user. But lets not do this by introducing special encodings into ASCII for every application. - I also IDN is the wrong level to start implementing international DNS. For internationalisation of DNS, we should start by making DNS use UCS for all character data by having it normalised and using well defined matching rules. At an upper layer, above basic DNS, we can add IDN rules like what character are forbidden. But these rules should not be applied to the lower levels of DNS because they restrict DNS to be only "host names", now and forever. Dan From owner-idn@ops.ietf.org Sun Jan 28 05:40:03 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07568 for ; Sun, 28 Jan 2001 05:40:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Mp32-000LrX-00 for idn-data@psg.com; Sun, 28 Jan 2001 02:27:04 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14Mp31-000Lr4-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 02:27:04 -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 CAA28932 for ; Sun, 28 Jan 2001 02:26:45 -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 f0SAQXc19654 for ; Sun, 28 Jan 2001 02:26:33 -0800 (PST) Received: from [10.0.1.29] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA26982 for ; Sun, 28 Jan 2001 02:26:28 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200101280953.f0S9rP413364@malmo.trab.se> References: <200101280953.f0S9rP413364@malmo.trab.se> Date: Sun, 28 Jan 2001 11:26:18 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Interactions between short-term and long-term Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 10.52 +0100 01-01-28, Dan wrote: >Patrik wrote: > > >Consider another example where a user is using an existing software > >which doesn't do nameprep, and tries to send email to a user in a > >domain which include a character which is changed because of > >nameprep, what then happens? > >It works without problems. Both DNS-servers and e-mail MTAs understand how >to compare domain names. Read again what I wrote: One user uses existing software which doesn't to nameprep, and enters a domainname which includes a chaaracter which should have been changed according to the nameprep algorithm. It doesn't get changed because the software doesn't do the required change, and therefore non-nameprepped characters end up inside configuration files or in the SMTP protocol. You said youself that you didn't want non-nameprepped domainnames used as domainnames in configuration files etc. If we don't require software to do the right thing (which includes nameprep) then comparison will not be possible, or we are back to what you didn't like which is doing nameprep algorithm on the server side and not client side (as close to the keyboard as possible). >Even existing software of today do not do this correctely. A domain name >must be matched case insensitivly, but a lot of programs (Unix have a lot >of them) do not. > >But everybody do not have to understand "nameprep"!! Not everyone, that is correct. According to the IDNA spec only the software which accept input from keyboard (etc) have to do nameprep. Existing DNS software, resolver libraries, SMTP software etc doesn't have to understand it at all. Only client applications (including tools for changing configuration of DNS software ct) have to understand nameprep. See IDNA spec. >The basics for interoperability of text data is to agree on character >to code point mapping and normalisation. And normalisation means to >use ONE representation of a character instead of like Unicode allow >many variations. A good base would be UCS normalised using Unicode >form C (or maybe KC). >All programs should use this, otherwise interoperability will fail. Please read the nameprep spec. It explains in detail what is needed for domainnames. >No, the basic text input can do normalisation >but not full "nameprep". Correct. But I would as use not like software doing normalization either. >And when I edit a zone file, it will not have >"namepreped" names. It all depends on what program you use when creating the zonefile. >It will be in normal text data format. It is the >responsibility of the DNS server to reject loading of names that >have illegal characters (though I do not know how it is going to >know what names are host names) and to apply "domain name matching rules" >when comparing domain names. This is already discussed in the nameprep draft. >A DNS server should not mangle the names >by doing forced conversion to lower case. Do not talk about other things than nameprep. That's the only thing that is needed. >If we really want the world to get an easy start on interoperability >on text data, we should at protocol level use something like >UCS normalised using form C and encoded using UTF-8 (or UCS-2 or UCS-4). Might be a good generic goal for "protocol elements", and partly already specified (the need for a goal) in the IAB Charset report created several years ago. >And the for DNS use, define a standard library that can be used in both >DNS servers and in clients that can take a name in normalised text form >and compare them. Doing like "nameprep" wants, by converting a name >into a representation that can be used compare domain names by >binary matching, is totally wrong for me. The keyword which you miss in your discussion is "compatibility" with existing software which do not do nameprep. If we follow your scenario and require nameprep functionality in all software which compares domainnames then we will not have IDN implemented for many more years. Instead, if we create a format where binary (or case insensitive comparison which is used today) comparison is possible, then existing deployed servers and clients can be used. Much faster deployment of IDN, and that is very important. >In a way it is like >the ACE versus UTF-8 debate, ACE and "nameprep" introduces a special >form on text intermixed with normal formatted text. Yes, and that is a good thing. Saying that we _have_to_ change all software on the planet is just a non-starter, and because of that we need an encoding form of domainnames which makes them work with existing software. Something which is already is pointed out in the documents from the design teams, and something we discussed on this mailing list more than one year ago, so why do this again? paf From owner-idn@ops.ietf.org Sun Jan 28 05:41:20 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07583 for ; Sun, 28 Jan 2001 05:41:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Mp6B-000Lvd-00 for idn-data@psg.com; Sun, 28 Jan 2001 02:30:19 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by psg.com with esmtp (Exim 3.16 #1) id 14Mp6A-000Lum-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 02:30:19 -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 CAA29391 for ; Sun, 28 Jan 2001 02:30:00 -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 f0SATmJ08320 for ; Sun, 28 Jan 2001 02:29:48 -0800 (PST) Received: from [10.0.1.29] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA27074 for ; Sun, 28 Jan 2001 02:29:43 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200101281010.f0SAA5415955@malmo.trab.se> References: <200101281010.f0SAA5415955@malmo.trab.se> Date: Sun, 28 Jan 2001 11:28:58 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Some other aspects Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11.09 +0100 01-01-28, Dan wrote: >At an upper layer, above basic DNS, we can add IDN rules like >what character are forbidden. But these rules should not be applied to >the lower levels of DNS because they restrict DNS to be only >"host names", now and forever. The proposals from the design teams doesn't propose any changes to DNS at all. In the DNS protocol, each label can contain octets of any value. This is not changed anywhere. paf From owner-idn@ops.ietf.org Sun Jan 28 06:04:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07687 for ; Sun, 28 Jan 2001 06:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MpSi-000MSc-00 for idn-data@psg.com; Sun, 28 Jan 2001 02:53:36 -0800 Received: from malmo.trab.se ([131.115.48.10]) by psg.com with esmtp (Exim 3.16 #1) id 14MpSh-000MSW-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 02:53:35 -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 f0SArX420489; Sun, 28 Jan 2001 11:53:33 +0100 (MET) Message-Id: <200101281053.f0SArX420489@malmo.trab.se> Date: Sun, 28 Jan 2001 11:52:31 +0100 (MET) From: Dan Reply-To: Dan Subject: Re: [idn] Interactions between short-term and long-term To: idn@ops.ietf.org, paf@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KoxSqZElL8v7pQ3ZsZn1PQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-idn@ops.ietf.org Precedence: bulk Patrik wrote: > >You said youself that you didn't want non-nameprepped domainnames >used as domainnames in configuration files etc. No I did not, but there is one more Dan on this list. I want to edit my configuration files using my normal text editor. It is the responsibility of the application using the configuration files to convert them into the character set used internally in it. >>But everybody do not have to understand "nameprep"!! > >Not everyone, that is correct. According to the IDNA spec only the >software which accept input from keyboard (etc) have to do nameprep. So you expect my text editor to do "nameprep" on the host names it finds in my text? >>And when I edit a zone file, it will not have >>"namepreped" names. > >It all depends on what program you use when creating the zonefile. A text editor. >>A DNS server should not mangle the names >>by doing forced conversion to lower case. > >Do not talk about other things than nameprep. That's the only thing >that is needed. nameprep mangles my host names. They contain mixed case. And I want that for more than ASCII. It is ok to change "double width A", "greek A", "russian A" into A because it will still be an A. But to make it lower case will make non-nameprep enhanced programs fail and reduce readability on names. >>And the for DNS use, define a standard library that can be used in both >>DNS servers and in clients that can take a name in normalised text form >>and compare them. Doing like "nameprep" wants, by converting a name >>into a representation that can be used compare domain names by >>binary matching, is totally wrong for me. > >The keyword which you miss in your discussion is "compatibility" with >existing software which do not do nameprep. If we follow your >scenario and require nameprep functionality in all software which >compares domainnames then we will not have IDN implemented for many >more years. Not at all. The way I have stated in my drafts where only the authorative DNS server need to understand how to compare domain names will allow quick introduction of IDN. The moment I have updated my DNS server to allow IDN others in the world can lookup my names even though the intermidate DNS servers do not understand how to do the matching. Dan From owner-idn@ops.ietf.org Sun Jan 28 07:17:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07924 for ; Sun, 28 Jan 2001 07:17:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14MqZN-000O05-00 for idn-data@psg.com; Sun, 28 Jan 2001 04:04:33 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.16 #1) id 14MqZM-000Nys-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 04:04:32 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA04494 for ; Sun, 28 Jan 2001 04:04:16 -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 f0SC42H00651 for ; Sun, 28 Jan 2001 04:04:02 -0800 (PST) Received: from [10.0.1.29] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id EAA00045 for ; Sun, 28 Jan 2001 04:03:56 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <200101281053.f0SArX420489@malmo.trab.se> References: <200101281053.f0SArX420489@malmo.trab.se> Date: Sun, 28 Jan 2001 13:02:59 +0100 To: idn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [idn] Interactions between short-term and long-term Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk At 11.52 +0100 01-01-28, Dan wrote: >It is the responsibility of the application using >the configuration files to convert them into the character set >used internally in it. And if the program doesn't do it, then you have to enter the domainnames in a nameprepped form. > >Not everyone, that is correct. According to the IDNA spec only the >>software which accept input from keyboard (etc) have to do nameprep. > >So you expect my text editor to do "nameprep" on the host names it finds >in my text? It all depends on in what context the textual string is a domainname. > >>And when I edit a zone file, it will not have >>>"namepreped" names. >> >>It all depends on what program you use when creating the zonefile. > >A text editor. I repeat myself: it all depends on what program you use. Where the support is doesn't matter. > >Do not talk about other things than nameprep. That's the only thing >>that is needed. > >nameprep mangles my host names. They contain mixed case. And I want that >for more than ASCII. Then complain on the nameprep algorithm specifically. paf From owner-idn@ops.ietf.org Mon Jan 29 00:19:52 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14319 for ; Mon, 29 Jan 2001 00:19:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14N6GN-000Jff-00 for idn-data@psg.com; Sun, 28 Jan 2001 20:49:59 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14N6GL-000JfX-00 for idn@ops.ietf.org; Sun, 28 Jan 2001 20:49: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 XAA20429; Sun, 28 Jan 2001 23:49:44 -0500 (EST) Message-Id: <200101290449.XAA20429@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Karlsson Kent - keka cc: "'Keith Moore'" , idn@ops.ietf.org Subject: Re: [idn] UNIX moving to UTF-8 In-reply-to: Your message of "Sat, 27 Jan 2001 12:57:25 +0100." Date: Sun, 28 Jan 2001 23:49:44 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > It's not that "ACE" didn't start out at ISO that is of concern. > It's the fact that the "ACE"s have an extremenly narrow field > if applicability (IDNs) that is of concern. agreed that it's a narrow field of applicability, but it's an important one for what we're trying to solve. UTF-8 might be quite flexible, but it doesn't let us transmit domain names in the ASCII-only fields that most existing protocols and applications were written to expect. Keith From owner-idn@ops.ietf.org Mon Jan 29 07:06:18 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29738 for ; Mon, 29 Jan 2001 07:06:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NCjV-0006fM-00 for idn-data@psg.com; Mon, 29 Jan 2001 03:44:29 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14NCjU-0006fG-00 for idn@ops.ietf.org; Mon, 29 Jan 2001 03:44:28 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29147; Mon, 29 Jan 2001 06:44:22 -0500 (EST) Message-Id: <200101291144.GAA29147@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-requirements-04.txt Date: Mon, 29 Jan 2001 06:44:22 -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 : Requirements of Internationalized Domain Names Author(s) : Z. Wenzel, J. Seng Filename : draft-ietf-idn-requirements-04.txt Pages : 8 Date : 26-Jan-01 This document describes the requirement for encoding international characters into DNS names and records. This document is guidance for developing protocols for internationalized domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-04.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-requirements-04.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-requirements-04.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: <20010126083258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010126083258.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Mon Jan 29 16:57:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10473 for ; Mon, 29 Jan 2001 16:57:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NLnj-0007bc-00 for idn-data@psg.com; Mon, 29 Jan 2001 13:25:27 -0800 Received: from ns.secondary.com ([208.184.76.39]) by psg.com with esmtp (Exim 3.16 #1) id 14NLni-0007bW-00 for idn@ops.ietf.org; Mon, 29 Jan 2001 13:25:26 -0800 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23578 for ; Mon, 29 Jan 2001 13:18:41 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Mon, 29 Jan 2001 13:25:07 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: [idn] Proposal to re-prohibit U+3002 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idn@ops.ietf.org Precedence: bulk Greetings again. James Seng pointed out a difference between nameprep-00 and nameprep-02 that has a significant impact on Asian input mechanisms. In many Asian IMEs, typing the "period" character on the keyboard enters U+3002 into the IME. Clearly, the user is doing this to enter a period (U+002E), and the only way to actually enter U+002E is to toggle between their native characters and ASCII for that single character. U+3002 was prohibited in nameprep-00 because of its similarity to U+002E, but it is allowed in nameprep-02. The nameprep design team has tentatively agreed that we should revise nameprep to prohibit U+3002, not because it looks like U+002E (in fact, in many fonts, they look different), but because it is used as if it were U+002E in input mechanisms. This would allow IME makers to safely map U+3002 to U+002E *before* doing nameprep without worrying about preventing users from accessing legitimate host name parts. Just to be clear, this is not "fixing" something in 10646/Unicode, but making it easier for Asian IMEs to do the right thing with name parts. Comments? --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Jan 29 19:09:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12389 for ; Mon, 29 Jan 2001 19:09:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NNyT-000BSY-00 for idn-data@psg.com; Mon, 29 Jan 2001 15:44:41 -0800 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by psg.com with esmtp (Exim 3.16 #1) id 14NNyS-000BSP-00 for idn@ops.ietf.org; Mon, 29 Jan 2001 15:44:40 -0800 Received: from daemon.inl.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id IAA89450; Tue, 30 Jan 2001 08:44:29 +0900 (JST) Received: (qmail 64319 invoked by alias); 30 Jan 2001 08:44:29 +0900 Received: (qmail 64303 invoked from network); 30 Jan 2001 08:44:28 +0900 Received: from daemon.inl.ntts.co.jp (HELO localhost) by daemon.inl.ntts.co.jp with SMTP; 30 Jan 2001 08:44:28 +0900 To: idn@ops.ietf.org Subject: Re: [idn] Proposal to re-prohibit U+3002 In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010130084422J.yone@po.ntts.co.jp> Date: Tue, 30 Jan 2001 08:44:22 +0900 (JST) From: Yoshiro YONEYA X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Paul Hoffman / IMC Subject: [idn] Proposal to re-prohibit U+3002 Date: Mon, 29 Jan 2001 13:25:07 -0800 > U+3002 was prohibited in nameprep-00 because of its similarity to > U+002E, but it is allowed in nameprep-02. The nameprep design team > has tentatively agreed that we should revise nameprep to prohibit > U+3002, not because it looks like U+002E (in fact, in many fonts, > they look different), but because it is used as if it were U+002E in > input mechanisms. This would allow IME makers to safely map U+3002 to > U+002E *before* doing nameprep without worrying about preventing > users from accessing legitimate host name parts. I think prohibiting U+3002 is essential. Actually some Japanese vocal groups using it as name, so that some people oppose or nervous prohibiting it, but using it is harmful in technical reason. Names using U+3002 looks like domain name, but actually it is a single word, then DNS queries for that name will cause TLD query to the root servers. I explained this problem at APAN/TransPAC/NLANR/Internet2 Techs Workshop today. The presentation material will be available soon from the following URL. http://www.ncne.nlanr.net/training/techs/2001/0128/mtgnotice.html P.S. Next version of mDNkit will provide such delimiter mapping as a part of localization functionality. mDNkit is distributed at JPNIC's web page as opensource with BSD-like license. It is now included in ISC BIND's (BIND-8.2.3 / BIND-9.1.0) contrib area. -- Yoshiro YONEYA aka From owner-idn@ops.ietf.org Tue Jan 30 04:50:24 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02633 for ; Tue, 30 Jan 2001 04:50:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NWz8-000Jqz-00 for idn-data@psg.com; Tue, 30 Jan 2001 01:21:58 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14NWz7-000Jqs-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 01:21:57 -0800 Received: (qmail 12224 invoked by uid 1001); 30 Jan 2001 09:22:12 -0000 Date: 30 Jan 2001 09:22:12 -0000 Message-ID: <20010130092212.23751.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: <20010127195756.26554.qmail@cr.yp.to> <20010128041237.15447.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 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. (2) UTF-8 with slow nameprep. Names in configuration files may be bad. This lets us leave the keyboard interface alone, at the expense of putting nameprep into a huge number of programs. Yuck. When Patrik said that qmail and djbdns and so on ``have to be changed because of the nameprep stage,'' he was talking about #2. (3) ACE with fast nameprep and slow encoding. Names in configuration files are good UTF-8 names. The keyboard interface has to help users type good names. Furthermore, a huge number of programs need to learn about ACE. Yuck. When Patrik recently agreed that qmail and djbdns and so on _don't_ have to learn about nameprep, he was talking about #3 and #4. He still refuses to acknowledge #1. (4) ACE with fast nameprep and fast encoding. Names in configuration files are good ACE names. The keyboard interface has to help users type good names and convert them to ACE. Furthermore, users need to use an extra filter to read the ACE names every time they access configuration files with tools such as vi, grep, etc. Yuck. The big difference between #1 and #4 is that the world is moving to UTF-8, not ACE, as the default extension of ASCII. UTF-8 already works with vi and grep on my system; ACE never will. (5) ACE with slow nameprep. Names in configuration files are UTF-8, and may be bad. This lets us leave the keyboard interface alone. But a huge number of programs need to learn about nameprep and ACE. Yuck. I hope this list is helpful. I wish Patrik and Keith would stop denying the existence of #1. ---Dan From owner-idn@ops.ietf.org Tue Jan 30 04:53:21 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02661 for ; Tue, 30 Jan 2001 04:53:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NXFM-000K5N-00 for idn-data@psg.com; Tue, 30 Jan 2001 01:38:44 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14NXFL-000K5G-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 01:38:43 -0800 Received: (qmail 26945 invoked by uid 1001); 30 Jan 2001 09:39:04 -0000 Date: 30 Jan 2001 09:39:04 -0000 Message-ID: <20010130093904.17799.qmail@cr.yp.to> Mail-Followup-To: idn@ops.ietf.org From: "D. J. Bernstein" To: idn@ops.ietf.org Subject: Re: [idn] Interactions between short-term and long-term References: <200101280953.f0S9rP413364@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idn@ops.ietf.org Precedence: bulk Dan writes: > Just think of a text editor where it recognises I am typing a host > name in the middle of some text and starts messing around. The idea is an extra input mode---and that shouldn't be necessary in most locales. Does your keyboard produce any non-KC-normalized strings? > 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? ---Dan From owner-idn@ops.ietf.org Tue Jan 30 05:05:40 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02753 for ; Tue, 30 Jan 2001 05:05:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NXW2-000KLb-00 for idn-data@psg.com; Tue, 30 Jan 2001 01:55:58 -0800 Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14NXW1-000KLU-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 01:55:57 -0800 Received: (qmail 30205 invoked by uid 1001); 30 Jan 2001 09:56:15 -0000 Date: 30 Jan 2001 09:56:15 -0000 Message-ID: <20010130095615.27316.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: <200101290449.XAA20429@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 says that ``most'' applications expect ``ASCII-only fields.'' Details, please. Exactly which software has to be upgraded for UTF-8? My current list includes the gethostbyname() library, mutt, pine, and sendmail. Note that all of these would also need changes for ACE with slow nameprep, and for ACE with fast nameprep and slow encoding. ---Dan From owner-idn@ops.ietf.org Tue Jan 30 12:54:26 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14119 for ; Tue, 30 Jan 2001 12:54:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NeeP-0000Be-00 for idn-data@psg.com; Tue, 30 Jan 2001 09:33:05 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14NeeO-0000BY-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 09:33:04 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA04523; Tue, 30 Jan 2001 12:33:02 -0500 (EST) Message-Id: <200101301733.MAA04523@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 "30 Jan 2001 09:56:15 GMT." <20010130095615.27316.qmail@cr.yp.to> Date: Tue, 30 Jan 2001 12:33:02 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk > Details, please. Exactly which software has to be upgraded for UTF-8? Essentially everything that accepts input containing DNS names. Or do you claim that you've exhaustively analyzed every program that handles domain names on every platform and that none of them (other than pine, mutt, sendmail, and than those which dynamically load gethostby* and for which the problems can be remedied by replacing that library?) exhibit any kind of failure when presented with UTF-8 domain names - including munging those names or a failure to recognize two different representations of the same name as equivalent? I thought not. Keith From owner-idn@ops.ietf.org Tue Jan 30 12:54:34 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14142 for ; Tue, 30 Jan 2001 12:54:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NeX4-00005v-00 for idn-data@psg.com; Tue, 30 Jan 2001 09:25:30 -0800 Received: from astro.cs.utk.edu ([128.169.93.168]) by psg.com with esmtp (Exim 3.16 #1) id 14NeX2-00005m-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 09:25:28 -0800 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA04447; Tue, 30 Jan 2001 12:25:17 -0500 (EST) Message-Id: <200101301725.MAA04447@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] Fast nameprep vs. slow nameprep In-reply-to: Your message of "30 Jan 2001 09:22:12 GMT." <20010130092212.23751.qmail@cr.yp.to> Date: Tue, 30 Jan 2001 12:25:17 -0500 Sender: owner-idn@ops.ietf.org Precedence: bulk this is indeed a helpful list, as it helps identify at least part of the difference in assumptions. my assumption is that for most languages and most people's platforms the "keyboard interface" for entry of DNS names does not exist - i.e. it's no different from the "keyboard interface" used for ordinary text. and nameprep is still needed for many languages for which the input environments don't need a special keyboard interface to allow users to type in DNS names. thus, we don't have the luxury of isolating nameprep with the keyboard interface. most of the programs that accept entry of DNS names will do so using the normal text interface, which doesn't do any kind of nameprep. and in many cases (email messages, zone files, etc.) IDNs will be mixed with normal text. so they have to separate IDNs from other text and perform nameprep (and perhaps ACE) on those IDNs. thus I don't think the approach you listed as #1 is feasible. Keith From owner-idn@ops.ietf.org Tue Jan 30 13:30:15 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14961 for ; Tue, 30 Jan 2001 13:30:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NfFv-0000iz-00 for idn-data@psg.com; Tue, 30 Jan 2001 10:11:51 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14NfFu-0000it-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 10:11:51 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 712 for ; Tue, 30 Jan 2001 10:11:48 -0800 Message-ID: <3A7703E3.3E5249E7@ehsco.com> Date: Tue, 30 Jan 2001 10:11: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 To: IDN Subject: [idn] should BOM be supported Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Encoding and where-to-do-nameprep issues aside, has the subject of byte order mark been covered? I'm still trying to catch up with all of the older material so if this topic has already come up, a quick answer will be appreciated. Anwyay, it seems to me that in order to provide for a truly international namespace we need to allow for BOM within the labels. This is particularly true given a mix of names in legacy TLDs which may conflict with any newer internationalized TLDs which may be eventually developed. For example, [arabic].sa needs to support right-to-left BOM for the [arabic] label while also supporting traditional left-to-right encoding for the sa TLD label. I say its a potential issue because if [arabic] is required to be represented in LTR form then a future (albeit only a potential) arabic TLD for any of the Middle East nations could cause a variety of name recognition and IP disputes. Ignore the potential byte cost and encoding issues for the moment please. Is this feasible? What other issues are there? If the inclusion of BOM is not feasible for nameprep then should the issue of byte ordering be dealt with as a part of nameprep process (dictate the orderuing that must be used, but exclude BOM). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jan 30 16:02:34 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17623 for ; Tue, 30 Jan 2001 16:02:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NheN-0002zZ-00 for idn-data@psg.com; Tue, 30 Jan 2001 12:45:15 -0800 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14NheM-0002zT-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 12:45:14 -0800 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 734 for ; Tue, 30 Jan 2001 12:45:12 -0800 Message-ID: <3A7727D7.7073F001@ehsco.com> Date: Tue, 30 Jan 2001 12:45:11 -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 Subject: Re: [idn] should BOM be supported References: <3A7703E3.3E5249E7@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If the inclusion of BOM is not feasible for nameprep then should the > issue of byte ordering be dealt with as a part of nameprep process > (dictate the orderuing that must be used, but exclude BOM). Following myself up, I had an off-line chat and a future version of nameprep is likely to clarify that labels are handled left-to-right so any formatting which is applied prior to this stage must be dealt with prior to this stage. Explicit policy statement expected. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-idn@ops.ietf.org Tue Jan 30 17:06:59 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18226 for ; Tue, 30 Jan 2001 17:06:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14NiaM-0003rc-00 for idn-data@psg.com; Tue, 30 Jan 2001 13:45:10 -0800 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.16 #1) id 14NiaL-0003rW-00 for idn@ops.ietf.org; Tue, 30 Jan 2001 13:45:09 -0800 Received: (from tale@localhost) by gro.dd.org (8.9.0/8.8.5) id QAA17278; Tue, 30 Jan 2001 16:45:07 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14967.13795.181073.807498@gro.dd.org> Date: Tue, 30 Jan 2001 16:45:07 -0500 (EST) From: tale@nominum.com (David C Lawrence) To: IDN Subject: Re: [idn] should BOM be supported In-Reply-To: <3A7703E3.3E5249E7@ehsco.com> References: <3A7703E3.3E5249E7@ehsco.com> Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please note that the Byte Order Mark is not used in the bidirectional algorithms. Its purpose is to indicate the endianness of 16 bit and 32 bit characters, not to indicate the display direction. I don't think it would make much sense to use the BOM on a per-label basis. More likely you'd see in places such as the start of a zone file that is stored in UCS-2 or UCS-4, to indicate the byte order of the entire file.