Re: [idn] WG last call summary

[Pete Resnick <presnick@qualcomm.com>]

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:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102