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 PROTECTED]> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
