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