[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] San Diego Meeting Notes
- To: idn@ops.ietf.org
- Subject: Re: [idn] San Diego Meeting Notes
- From: "D. J. Bernstein" <djb@cr.yp.to>
- Date: 14 Jan 2001 09:09:11 -0000
- Delivery-date: Sun, 14 Jan 2001 01:10:29 -0800
- Envelope-to: idn-data@psg.com
- Mail-Followup-To: idn@ops.ietf.org
- User-Agent: Mutt/1.2.5i
Don't confuse protocols with software.
The ACE _protocol_ extensions are isolated in user-interface protocols,
while the UTF-8 _protocol_ extensions are not. But it is a serious
mistake to conclude that the ACE _software_ changes are more isolated
than the UTF-8 _software_ changes.
> ACE solutions, positive
> - they are easier to implement than the long term solutions,
That's simply not true.
The most easily implemented and deployed solution is straight UTF-8.
Nameprep can be handled in the way I've described. This solution allows
many existing 8-bit-clean programs, such as hundreds of thousands of
qmail installations, to handle IDNs properly.
(Yes, many UNIX users have to get the Unicode fonts and the UTF-8 xterm,
but ACE won't avoid that. These tools are included in current systems.)
The ACE solutions require more extensive code changes in more programs.
They then require more deployment effort. They will, for example,
require that qmail perform ACE conversions when
* reading domain names from command lines,
* reading domain names from environment variables,
* reading domain names from configuration files,
* printing domain names in logs, and
* printing domain names in mail-queue summaries,
because all of these are part of qmail's user interface. After these
changes, qmail will have to be redeployed.
UTF-8 needs changes in most MUAs, some browsers, and certain servers,
notably Sendmail; deployment will not be easy. But ACE needs changes in
every MUA, every browser, every MTA, every web server, and many other
programs; deployment will be vastly more difficult.
In short, the costs of making ACE work are much higher than the costs of
making UTF-8 work. And that's not counting the future costs of switching
from ACE to UTF-8 later or inflicting ACE on future implementors.
> - the obvious advantage is that update just applications will go faster
> than updating applications and the entire naming infrastructure
This concept of ``applications'' is bogus. The OSI model does not match
the reality of low-level programs talking directly to users.
---Dan