Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

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

Comments on draft-ietf-idn-idna-08.txt

-
Section 1: Introduction

Here it is stated that IDNA does not require changes in any
infrastructure and that the existing ASCII name service of DNS
is sufficient.

This is wrong.

Regarding the ASCII names of DNS is sufficient you probably mean
that it is sufficient for IDNA. It is not generally sufficient.

As DNS allowes non-ASCII octet values in names, IDNA require
changes in the infrastructure as IDNA prohibits non-ASCII
octet values which in turn breaks backward compatibility.

Also, it is stated that resolvers do not need to be changed.
But it is probably the resolver libraries that should be
changed. By changing the resolver libraries on my system
so that applications are not aware of ACE-encoded names,
there is a good possibility for me to use domain names
containg non-ASCII very quickly as all applications will
get it at the same time. If it is implemented using new
application code I am not sure I can use non-ASCII in
my names, even 10 years in the future.

-
The definition of what IDN means is complex.
It is defined to be a domain name on which ToASCII can
be applied without failing. And then in the text IDN
is sometimes used to mean a ACE-encoded name and
sometimes to mean a UCS-encoded name.

This can easily confuse the reader.

The basic definition for domain names should be
something like:
A domain name is a sequence of hierachicaly orderd
labels, each label being a sequence of characters.

Note: characters, not octets.

A domain name must always use the character set of
its context!

Using the above two rules you get domain names working as
most people expect them.

Section 3 says in requirement 1) that several
different "dots" are allowed between labels when written
that way. There are probably more "dots" in UCS that
could work. I see no reason to forbid them, unless
all are forbidden exepct U+002E.
Only one type of dots simplifies comparing of names.
Only one type of "dot" should be used in each context.
In a Latin based context only U+002E should be used.

Most of Section 3 is directly given by the two rules above.

2) If a name is put into an ASCII context, it will have
to be converterd into ACE using ToASCII.

3) If a name is put an a non_ASCII context it must be
changed to the character set of that context (ToUnicode
is not enough, all context are Unicode).

4) When two names are compared they must both be
in the same context and be normalised.

IDNA mandates (probably) that a domain name used
in a link in a html document must be ACE encoded.
This is not what is natural for people to use.
People will expect a domain name in a html document
to use the same character set as the rest of the text.
Expect conflicts here. People will not ACE-encode names.
It is important for everybody to immediately
accept non-ASCII characters in domain names, even though
standards are not fully up to date.

-
Section 6.3 and Section 6.6

In the beginning of the document it is stated that IDNA
do not change the DNS system. But in Section 6.3 and 6.6
this draft states a change to DNS conflicting with the
existing standard.

It says: domain names conating non-ASCII characters must
use ACE encoded labels.

This is in conflict with current DNS RFCs which allowes
domain names containing non-ASCII. It also breaks
backward compatibility as that type of domain names are
in use today.

The difficulty of the current DNS standard is that it does not
define what octet values should be used for characters
outside the ASCII range. As ISO 01646 is the most recommended
form of code point values, the current DNS standard should
be updated defining that octet values outside the ASCII
range are UTF-8 or ISO 8859-1 (as both are ASCII compatible).
Best would be if DNS labels were updated to use UTF-8 or
ISO 8859-1 (both can be used as they can easily be
identified and handled by the same decoder code).

IDNA must NOT restrict current usage and DNS standards
making it impossible to update the DNS standard later
with a suitable defined handling of non-ASCII octet
values!

IDNA is not an update of the DNS standard. IDNA is a
way to put one more layer on top of DNS by encoding
names into ASCII code values. DNS itself must
be allowed to evolve in a simple easy manner.


   Dan