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
