Re: [idn] draft-ietf-idn-requirements-07.txt

[Dan <[e-mail]>]

I have read through the latest version of the requirements and there are
a few things I would like to discuss:


How are we going to handle a draft like IDNA that does not change the
DNS protocol and does not fulfill all protocol requirements?
In [3] it is said that the protocol must not limit the code points
that can be used. As IDNA does not change the protocol, it does not
limit the protocol directely, but it does indirectely as some IDNA
removes all upper case letters. And in [13] it says that the
protocol must specify how characters are encoded in DNS records.
This is not solved by IDNA - it only says how characters in names can
be encoded.


-
Then there is one section about "canonicalisation".

While not specified I assume "canonicalisation" is the process to
change a character string into a format the allows it to be binary
compared with an other string.

In [19] it is said that cononicalisation must be done at a single
well-defined place in the DNS resolution process. As canonicalisation
may result in data being destroyed, it should be required that
if canonicalisation is done at client end the canonicalisation
process must not destroy data in a name.

In [21] it is required that case insensitivity is reatined for ASCII, but
not for the rest of UCS.
In LDAP case insensitivity is a MUST, why is it not a MUST in DNS?
Not requiring case insensitivity for all letters will result in
many problems including confused users.
As DNS has always been case insensitive it is not good to change that
now. (Note: to force all names to be lower case is not to make it
case insensitive).

[23] - is this really needed. If canonicalisation is the process to
make a string into a binary comparable string, it will always
be done before or as part of the domain name resolution.


   Dan