Subject: [idn] Expected handling of labels

From: Dan Oscarsson <[email-masked]>
Date: Sat, 16 Feb 2002 13:20:16 +0100

I see that still, after so long time, the people of the IDN working
group
do not agree of how labels in DNS should be handled.

DNS, as defined by RFC 1035, defines for me what I would expect
of a database with objects having an owner name:
- A name is a sequence of printable characters.
- The character data in a name is preserved.
- Names are matched case-insensitive.

Yes, it is printable characters even though RFC 1035 does not
forbid it because that is how it is generally used.
If we want to use binary data in labels, either define
a new binary label or encode binary data using ACE.

There is now much different discussions of how DNS should work
when be broaden the scope of characters of all of the world's need.
Some want to force special rules on some labels (like requiring
host names to be lower case) and some want anything to be possible
including binary data and un-normalised character data.

I strongly oppose DNS having more than ONE form of character labels.
All character labels (it is ok to define a binary one) in DNS
must follow the same rules. To be well working and follow what would
be expected of names used for matching in directorys or other types of
databases, they should:
- Be only printable characters (no control codes).
  This because they are names, not application data.
- Be normalised. Unicode form C or probably KC is suitable.
  This because only one representation of a character must
  exist so that data can be easily processed.
  I cannot say if KC is OK for everybody. From what I can
  see for Latin based letters KC is fine. Things like
  full/double width or circled forms are display options like
  bold or italic and should not have a special code in a
  character set.
- Be stored and returnd in queries using the original
  entered form (including mixed case and other characteristics
  available).
  This because form may be significat in some systems and
  it is important to enhance readability.
- Be matched using form-insensitive matching (this includes
  case-insensitive matching).
  This because for the common man, form is not significant.

Using the above rules DNS (which are defined in RFC 1035 or
the current usage/semantics of DNS) would continue having
a broad and easy to use functionality.

If there exist specific need to have binary or form-exact
matching, new label types can be defined for those labels.

Please stop thinking so much about programmers. Think
of how people want to use a database where you bind a
name to an object. At least I want things to work
like LDAP and DNS today works: I define an object,
give it a name, the name is reatind and returned from
the database in the same form I entered it and when
doing matching the database ignores case of letters.

   Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Feb 2002 08:00:52 -0000

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