[idn] Expected handling of labels

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

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