Subject: Re: [idn] Expected handling of labels

From: Dan Oscarsson <[email-masked]>
Date: Sun, 17 Feb 2002 16:54:49 +0100

D. J. Bernstein wrote:

>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?

You quite often lears to bypass defect interfaces and quit complaining
after a while. Though you still dislike it.

Yes, Unix is one system full of bad designs. You have to learn to live
with it
and always type your account name of file names using the exact case
stored in the system (but you do not have to use lower case always).
URLs have always been case-insensitive on my web even though the server
is running under Unix. Much easier for the users!

>``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.

Yes and when using case-sensitive systems you probably should avoid
having
to names only different in case in the same scope. But you want to
use different case to enhance readability.

I use mixed case in my Unix filesystem to enhance readability.
I use tcsh which can compleate file names ignoring case.
I would be much nicer it the file system was case-insensitive.

Some want their host name or URL to contain mixed case because
it corresponds to their trademark or makes the meaning clearer.

>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.

Actually case-insensitivity for many Latin based letters can easily
be handled without a large cost. One thing that could be done
is to avoid the difficult cases from the beginning.

One important question is:
Is it more important to lower the cost of software then to
lower the cost of the human - computer interface?

From what I have seen the cost of increased human time to handle
difficlut interfaces is very much more costly than fixing
software.

   Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 2002 03:37:00 -0000

Dan Oscarsson writes:
> Much easier for the users!

Where are the HCI studies evaluating the actual usability impact of
allowing uppercase Unicode labels?

You claim without evidence that there's a readability benefit. I could
claim, with just as much evidence, that there is a huge typability loss.
I could also claim that users who don't know Greek will be confused by
uppercase Greek Gamma matching lowercase Greek gamma. ``Hey, this
certificate is for the wrong site! Impostors!''

You say that usability will be improved so much that programmers should
take time away from other features to implement this one. But are you so
sure about this that you're willing to commit the entire Internet to
this decision _now_, with no way to escape if you turn out to be wrong?

IDNC3, http://cr.yp.to/proto/idnc3.html, takes a conservative approach.
It provides safe deployment of lowercase IDNs, and allows uppercase to
be safely added later _if_ that turns out to be a good idea.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "Kent Karlsson" <[email-masked]>
Date: Sun, 24 Feb 2002 12:41:20 +0100

> be safely added later _if_ that turns out to be a good idea.

I don't agree with that approach, I think uppercase should
be allowed, since it is allowed for ASCII.  

But maybe one should reconsider the use of *case folding* and
instead just *map to lowercase* (in the 'default' way; not
localised for Turkish/similar nor for Lithuanian).   This
recognises that domain names most commonly are written in
lowercase anyway, and also allows for the distinction of "ss"
and sharp s, as well as the distinction of (the *different* letters)
i and dotless i (and similarly for Lithuanian), IF the domain
name is written in lowercase. Note also that there are several
(Latin) letters that do not even have ANY uppercase form (used
for IPA/similar).

		Kind regards
		/kent k