mail sent by our Chair on behalf of the IUCG to IAB. These comments have been inserted in <a href="http://wikidna.org/index.php?title=WG-IDNA_LC">http://wikidna.org/index.php?title=WG-IDNA_LC</a>.<br><br>Portzamparc.<br><br>
----<br><br>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.<br>
<br>
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?<br>
<br>
1. "When an IDN is encoded with Punycode, it is prefixed with "xn--",". Is an IDN a label?<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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)."<br>
<br>
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?<br>
<br>
3.4. "The DNS resolver will append suffixes in the suffix search list". Where is the "suffix search list" documented?<br>
<br>
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.<br>
<br>
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?<br>
<br>
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?<br>
<br>
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".<br>
<br>