[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Let's go forward with IDNA and UTF-8
- To: "D. J. Bernstein" <djb@cr.yp.to>, idn@ops.ietf.org
- Subject: Re: [idn] Let's go forward with IDNA and UTF-8
- From: Patrik Fältström <paf@cisco.com>
- Date: Sun, 27 May 2001 09:48:44 +0200
- Delivery-date: Sun, 27 May 2001 01:08:58 -0700
- Envelope-to: idn-data@psg.com
--On 01-05-26 17.16 +0000 "D. J. Bernstein" <djb@cr.yp.to> wrote:
> I have a much more serious concern: the short-term costs of deploying
> ACE appear to be much larger than the total costs of moving directly to
> UTF-8. See http://cr.yp.to/proto/idn.html for details.
I see two differences between UTF-8 and ACE which was what I used as
arguments when I made up my mind:
(1) Risk of loss of information
ACE approach is NOT destroying any information when data is sent from
sender to receiver in any of the protocols we have today. It is 100%
backward compatible.
Use of UTF-8 in any place in any protocol where we have a domainname today
MIGHT (I don't use any stronger term, but I don't see I have to either)
destroy some data during transport.
(2) How to fix broken domainnames
In an ACE approach, the enduser himself can change his own applications to
get rid of the ACE encoding and instead see the IDN as it was expected.
In an UTF-8 approach the user MIGHT have to change his applications so they
can display UTF-8 characters and (here comes the important part) someone
else than the enduser MUST upgrade the intermediary boxes (HTTP proxies,
SMTP gateways, SMTP MTA's, POP servers, IMAP servers etc) which is not
under his control.
I.e. if we compare with when we launched MIME, many people have told me
that "but the goal is that the user should not see the ACE, and geee what
Quoted Printable was ugly, let's not use the same mechanism again".
You all should know that I do not listen to people saying that which do not
need Quoted Printable to display their own name.
We need something which can be moved from A to B with existing protocols
and services which are deployed, and then the ability for A and B (alone,
not their network managers, or anyone with a root password) to use IDN's.
Patrik H:son Fältström