[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Expected handling of labels
- To: idn@ops.ietf.org
- Subject: Re: [idn] Expected handling of labels
- From: "D. J. Bernstein" <djb@cr.yp.to>
- Date: 17 Feb 2002 08:00:52 -0000
- Automatic-legal-notices: See http://cr.yp.to/mailcopyright.html.
- Mail-followup-to: idn@ops.ietf.org
- References: <3C6E4E80.CA0C16D0@trab.se>
Dan Oscarsson writes:
> Think of how people want to use a database where you bind a
> name to an object.
Okay. Here are three examples of well-known case-sensitive databases
that you probably use every day:
* The UNIX password list, accessed by account name.
* The UNIX filesystem, accessed by filename.
* The World Wide Web, accessed by URL.
Do you find yourself trying to log into your computer as ``dAn'' rather
than ``dan'' and wondering why it doesn't work? Have you been screaming
at the UNIX filesystem designers, telling them that they need nameprep?
How about W3C?
The simple fact is that users have already adapted to a huge number of
case-sensitive systems. Byte-string comparisons have not brought the
world to an end. This is true even for databases allowing full Unicode
names: look at the Plan 9 filesystem, for example.
``But it's confusing when I have separate objects named foo and Foo!''
you say. That's why people rarely set up such objects: they choose names
that _won't_ be confused. The IDNC3 proposal described at
http://cr.yp.to/proto/idnc3.html
extends this principle to domain-name registrars.
The clincher is the fact that, if we set up case-insensitivity for
non-ASCII characters, we'll never be able to escape. We'll have to
suffer the costs of supporting it forever. In contrast, if we take the
conservative IDNC3 approach, we'll still have the option of adding
case-insensitivity later, _if_ it turns out to be necessary.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago