Subject: Re: [idn] WG last call summary

From: Pete Resnick <[email-masked]>
Date: Mon, 18 Mar 2002 14:38:38 -0600

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
applications is not a failure.

>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: "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

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.