Subject: Re: [idn] WG last call summary

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2002 03:32:28 -0000

Pete Resnick writes:
> Inability to display non-US-ASCII glyphs by legacy
> applications is not a failure.

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.

Of course, display failures are not as intolerable as interoperability
failures. But they're still failures.

The IDNA proposal, in attempting to limit these display failures,
creates interoperability failures that would not have occurred with
ASCII domain names. IDNA coauthor Adam Costello has already admitted
this. Surely you agree that bounced mail is serious!

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "cdns-jwlin" <[email-masked]>
Date: Wed, 20 Mar 2002 02:25:11 +0800

For people who don't know Han, there is not differet between the ACEs and
Hans.
But the case is not suitable for us who use Chinese or other non-ASCII
glyphs.
There is much different to see a Han or a ACE!!

Your criteria for success are too low for us.

----- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 19, 2002 4:38 AM
Subject: Re: [idn] WG last call summary

> On 3/18/02 at 6:20 AM +0000, D. J. Bernstein wrote:
>
> >``Internationalized domain names are a failure if non-ASCII glyphs
> >don't appear on the screen.'' What kind of idiot would disagree with
> >that?
>
> I'm one of those kind of idiots. I expect that there will be many
> applications that won't put non-US-ASCII glyphs on the screen at the
> get-go. The three criteria for success (for me) are:
>
> 1. Applications, if they are properly coded, *can* display non-US-ASCII
> glyphs.
> 2. All of the new domain names can appear (in some form) in legacy
> applications without breaking those applications.
> 2. All applications, legacy or otherwise, are able to resolve new
> domain names. If there exists an domain name (and I'm referring to
> the logical entity, not some particular glyph representation of it)
> that a legacy application can't address, that's a failure.
>
> That is to say, balkanization during the transition is a failure of
> the protocol. Inability to display non-US-ASCII glyphs by legacy
> >Obviously the IDNA authors understand the desire to put non-ASCII
> >glyphs on the screen.
>
> To what is this a response? Has anyone claimed that it is
> *undesireable* to display non-US-ASCII glyphs?
>
> >* Preventing _all_ the interoperability problems means turning off
> >conversion for _every_ display subject to IDNA-unaware piping,
> >IDNA-unaware copy-and-paste, etc.---and that's a massive failure to
> >achieve the IDN goal.
>
> I cannot disagree more; this is not a massive failure. Unless of
> course MIME has also been a massive failure to send around binary
> attachments. In the same way, if I use an e-mail client that decodes
> base64 into binary and pipes the output to a program that expects
> US-ASCII input, I've done something broken. If I decode IDNA names
> and pipe them to a program that expects US-ASCII domain names, I have
> again done something broken. And in IDNA, we do MIME one better: The
> undecoded IDNA names are usable, even if they aren't pretty. A base64
> encoded file is near useless to anything without decoding.
>
> >* The proposal on the table, IDNA, does not disable these
> >conversions. It explicitly encourages these conversions.
>
> Textual support? 6.1 and 6.4 seem to give lots of reasons not to do
> the conversions.
>
> pr
> --
> Pete Resnick <mailto:[email-masked]>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>
>
>
>

---

From: Paul Robinson <[email-masked]>
Date: Tue, 19 Mar 2002 20:57:33 +0000

> 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.

> 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