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
