[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Where will we see bad domain names?
- To: idn@ops.ietf.org
- Subject: [idn] Where will we see bad domain names?
- From: "D. J. Bernstein c/o James Seng" <James@Seng.cc>
- Date: 7 Jan 2001 22:29:17 -0000
- Delivery-date: Sun, 07 Jan 2001 14:30:56 -0800
- Envelope-to: idn-data@psg.com
- Mail-Followup-To: idn@ops.ietf.org
- Reply-To: "D. J. Bernstein" <djb@cr.yp.to>
Why do we need name preparation in applications?
I'm not saying the nameprep work is useless. We should provide a program
to detect bad names: names with confusing characters, or with uppercase
characters, or that aren't KC-normalized. Registries will then prohibit
bad names.
But what will go wrong if these rules are hidden from applications? Why
should a typical application worry about bad names? Good names will be
accurately copied by cut-and-paste. When will bad names show up?
Mark Davis writes:
> The chances that the average application would, by chance, duplicate
> the same normalization is minimal.
You're saying that a user will see a good name on paper, type it into
his computer in his favorite way, and end up with a bad name that looks
the same.
Can you please give some real examples? What were the good names? What
keyboard-interface software was involved? What did the user type? Why
didn't the user end up with good names? Was it a bug in the software?
Perhaps there's a need for a tool that fixes bad Chinese domain names.
However, I don't see why this conversion should be stuck into every
piece of software that reads domain names from configuration files.
---Dan
P.S. RFC 1034 says ``When you receive a domain name or label, you should
preserve its case.'' Are we going to scrap this part of RFC 1034, and
encourage clients to fold case for ASCII characters? Or are we going to
say that the case of ASCII characters should be preserved?
Of course, for interoperability, DNS software and mail software and so
on will continue _comparing_ ASCII characters without regard to case.