[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] A case for *ACE, other good/bad ideas, and a rant...
- To: idn@ops.ietf.org
- Subject: Re: [idn] A case for *ACE, other good/bad ideas, and a rant...
- From: "D. J. Bernstein" <djb@cr.yp.to>
- Date: 8 Jan 2001 22:29:39 -0000
- Delivery-date: Mon, 08 Jan 2001 14:32:28 -0800
- Envelope-to: idn-data@psg.com
- Mail-Followup-To: idn@ops.ietf.org
William Morris writes:
> Nameprep is manditory for IDN. there is no way around it. Using the
> Japanese input method for Win98 if you hit period you get one of two
> characters depending on which mode (Japanese/English) you are in.
You are confusing two separate issues: the dots, and the stuff between
the dots.
The nameprep discussion is all about the stuff between the dots. There's
nothing in the nameprep draft about normalizing dots. In fact, dots and
things that look like dots are specifically prohibited.
[ embedded devices ]
> *ACE deals with this issue well, UTF-8 does not.
What if the sysadmin has to use an embedded device that can't deal with
name components longer than, say, 10 bytes? He has a much better chance
of finding a tolerable 10-byte UTF-8 string than of finding a tolerable
10-byte ACE string with any of the ACE proposals. (Of course, neither
chance is good if the name is supposed to be in Chinese.)
Why should we believe that failures to handle 8-bit data cleanly are
more common than failures to handle long domain names cleanly?
> Unless someone takes over the Internet again, there will continue to
> be systems running cc: mail or worse.
Are you saying that cc:Mail isn't 8-bit clean? Are you also saying that
cc:Mail has no trouble with long domain names?
(It has been a while since I've spotted any cc:Mail systems, so I don't
have an easy way to test any of this.)
---Dan