[idn] Is ACE really "IDN"?

["Edmon Chung" <edmon@neteka.com>]

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" <paul@iconoplex.co.uk>
To: <ietf@ietf.org>; <iesg@ietf.org>; <iab@isi.edu>; <idn@ops.ietf.org>
Sent: Tuesday, March 19, 2002 3:57 PM
Subject: Re: [idn] WG last call summary


> On Mar 19, "D. J. Bernstein" <djb@cr.yp.to> 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
>
>
>
>