[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Why IDNA breaks copy-and-paste



On Feb 14, "D. J. Bernstein" <djb@cr.yp.to> 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