Re: [idn] WG last call summary

["cdns-jwlin" <cdns@bach.iis.sinica.edu.tw>]

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" <presnick@qualcomm.com>
To: "D. J. Bernstein" <djb@cr.yp.to>
Cc: <idn@ops.ietf.org>; <ietf@ietf.org>; <iesg@ietf.org>; <iab@isi.edu>
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
> 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
>
>
>
>