On Feb 14, "D. J. Bernstein" <[EMAIL PROTECTED]> wrote: >Bottom line: If the user sees (glyphs for) non-ASCII characters, then >other programs will receive non-ASCII characters (in the local character >encoding). Many of those programs won't know anything about IDNA, so >their domain-name lookups will fail. And if the user types non-ASCII characters with his own keyboard then programs which do not know about IDN will receive non-ASCII characters and their domain-name lookups will fail. So what? Users will learn that entering IDN in applications not IDN-enabled does not work and will update them or use a X applet with an embedde punycode converter.
>How are we supposed to avoid these failures? What are software authors >supposed to do? If you really want to know, while waiting for all software to be updated to the IDN API (which I hope that in simple cases like ping or telnet would amount to adding a flag to getaddrinfo(3) or something like this) my plan is to LD_PRELOAD a simple library which will wrap name resolution library calls and call the new API. This may not work with more complex programs like a MUA which puts a domain in a RFC 2822 header, but would fix all simple programs like ping and telnet (and I think your tcpclient). And "just entering UTF-8" would still not work for my MUA, because UTF-8 characters are not allowed in mail headers until DRUMS says so. >The current X release has full UTF-8 support; you simply set a UTF-8 >locale such as LANG=en_US.UTF-8. Copy-and-paste handles full Unicode. As I explained, in most countries you cannot "simply set a UTF-8 locale" because that would damage interoperability with other people using a native charset, so this is not a generally applicable solution. -- ciao, Marco
