I guess the fundamental question is whether ACE is really "IDN"? Is not ACE just an ugly mask slapped on to the DNS to allow clients to fake out the user in that they are getting a multilingual domain name, but in fact, all they got from the DNS operators is a string of uninteligible ASCII characters? Also remember that with the introduction of ACE, we are effectively creating an "alternative system" to the DNS! Cause now we are saying that (for the following example imagine, xx--ace = a multilingual label <ML>) - xx--ace is NOT really xx--ace as you see it, but it really is <ML> - OR <ML> is the same as xx--ace Either way, it means that we have fundamentally changed the concept of a "unique" DNS name. All the while risking that the solution is not even solving the IDN problem. So what do you tell the customer they got? An ASCII String? or a Multilingual Domain name? Or do you say its a Buy one Get one Free?!
Here is my thought: ACE is an easier route for server operators (transport), and therefore is a good intermediary solution towards IDN for servers; Just use 8-bit is an easier route for users and client apps (display), and therefore is a good intermediary solution towards IDN for clients. Why cant we go both routes and layout a roadmap for an eventual convergence with a protocol change that utilizes 8bit data? Edmon ----- Original Message ----- From: "Paul Robinson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, March 19, 2002 3:57 PM Subject: Re: [idn] WG last call summary > On Mar 19, "D. J. Bernstein" <[EMAIL PROTECTED]> wrote: > > > Go sell a Greek user an ``internationalized domain name'' with a delta, > > Pete. Then tell him that most of his correspondents will see the delta > > as incomprehensible gobbledygook rather than a delta. See what he says. > > OK, scenario 1: > > You tell him that although it's gobbledygook to people without greek > alphabet support, it will still work. It's not convenient, but it WILL work. > Guaranteed. For his business colleagues and friends in Greece, who DO have > the latest and greatest software, it will display as a delta. His ISP hasn't > had to upgrade, and everybody in the world can use his domain - eventually > they will see it as a delta as well, but for now they see it as an encoded > string they can still use no problem. > > Scenario 2: > > Oops, sorry, our mistake, it's NOT gobbledygook, it's prefectly fine. For > everybody in Greece. Unfortunately, his bank in the UK can't understand his > e-mail address because the S/360 coders haven't got time to upgrade all the > systems and applications software. His family won't be able to send him mail > through systems that are running proprietary or legacy mail applications > because they don't understand this 8-bt stuff. When he's abroad, his website > and e-mail address may be useless. But it's OK, because it's a CLEAN > implementation and a great protocol, and everybody else will catch up > sometime in the next 4-10 years. Until then, he has to get a 'normal' domain > to see himself over. > > > Of course, display failures are not as intolerable as interoperability > > failures. But they're still failures. > > And they are failures for OS developers and application developers. Not the > IETF. Not for the IDNA WG. Not for anybody who wants to get IDNs through. > Not for the people who don't want to have to re-write the MTA on the PDP > they have running in the back office. Not for people who want to have to > deal with another SMTP spec change. The only problem as I see it, is that > until software that deals with IDN knows how to display PunyCode properly, > people will see some crap on the screen. What you are proposing IS > introducing an interoperability failure, which through your own admission is > worse than a display failure. > > > Surely you agree that bounced mail is serious! > > Which of these is easier to implement: > > 1. An updated DNS resolver > 2. Making every piece of software and display device that might ever have to > deal with IDNs capable of handling UTF-8? > > If you were IT director of a large firm, and you had a choice as to which to > roll out, which would you choose? > > -- > Paul Robinson > > > >
