Subject: [iucg] Comments on draft-iab-idn-encoding-00.txt

From: JFC Morfin <[email-masked]>
Date: Fri, 28 Aug 2009 02:21:15 +0200

Dear
The IUCG participating users think that your 
draft-iab-idn-encoding-00.txt is to be considered in a WG-IDNABIS 
perspective with its set of documents presently under WG/LC. Here are 
the comments we made.

1. "An Internationalized Domain Name (IDN) is a name that contains 
one or more non-ASCII characters.". What is a "name" vs. a domain name?

1. "When an IDN is encoded with Punycode, it is prefixed with 
"xn--",". Is an IDN a label?

1. "it is prefixed with "xn--", which assumes that ASCII names do not 
start with this prefix." Isn't the whole thing supposed to use "xn--" 
ASCII labels instead of non-ASCII entries?

1. "reversible Unicode-to-Punycode conversion .... reversible 
Punycode-to-Unicode conversion". Unicode is a table, Punycode is an 
algorithm. Punycode is not reversible, but its use can be restricted 
to codepoints in turn permitting it to perform reversibly.

1. "UTF-8 [RFC3629] is a mechanism for encoding a Unicode character 
in a variable number of 8-bit octets, where an ASCII character is 
preserved as-is." Characters belong to scripts that may or may not be 
supported by ASCII and Unicode encoding tables.

1.1. "When used with a DNS resolver library, IDNA is inserted as a 
"shim" between the application and the resolver library": that shim 
should be located in Figure 2.

1.1. "Again this assumes that ASCII names never start with "xn--", 
and also that UTF-8 strings never contain an ESC character". It may 
be worth documenting whether "IDN", "names", "labels", and "strings" 
are or are not the same thing.

2. "Applications that convert an IDN to Punycode before calling 
getaddrinfo() will result in name resolution failures if the Punycode 
name is directly used in such protocols. " Why? Is that not actually 
due to the reason that was given in 3? "Applications that convert an 
IDN to Punycode before calling getaddrinfo() will result in name 
resolution failures if the name is actually registered in a private 
name space in some other encoding (e.g., UTF-8)."

3. "While implementations of the DNS protocol must not place any 
restrictons on the labels that can be used, applications that use the 
DNS are free to impose whatever restrictions they like, and many 
have." Wouldn't these two rules contradict the proposed WG-IDNABIS 
charter change? Wouldn't they permit the support of cases such as 
Tatweel, Tamil figures, and French majuscules?

3.4. "The DNS resolver will append suffixes in the suffix search 
list". Where is the "suffix search list" documented?

4. "even when DNS is used, the conversion to Punycode should be done 
only by an entity that knows which name space will be used." 
Fundamental. Yet, this is not considered by IDNA rationale or protocol.

4.1. "Indeed the choice of conversion within the resolver libraries 
is consistent with the quote from [RFC3490] section 6.2 stating that 
Punycode conversion "might be performed inside these new versions of 
the resolver libraries". - "the recommendation is that a resolver 
library be more liberal in what it would accept from an application 
would mean that such a name would be accepted and re-encoded as 
needed". These recommended architectures (such as ML-DNS) are not 
considered in the IDNA rationale. Will IDNA be interoperable with 
these recommended architectures?

4. "encoding conversion between Punycode and UTF-8 is unambiguous". 
(?). This could lead to stabilization through punycode and A-labels, 
in turn making A-labels the DNS referent entry for UTF support?

5. Security considerations. This kind of consideration is already 
posing a problem for TM protection. This is the "Babel Names" case. 
This occurs when someone trademarks the U-label corresponding to a 
protected Roman script TM. When that U-label displays under its ASCII 
label form, it infringes on the Roman script TM rights. Ex.: 
"xn--coca-cola" or "xn--vint-cerf".

jfc morfin