IUCG comments on IDN-IAB

jean-michel bernier de portzamparc jmabdp at gmail.com
Fri Aug 28 03:20:55 CEST 2009


mail sent by our Chair on behalf of the IUCG to IAB. These comments have
been inserted in http://wikidna.org/index.php?title=WG-IDNA_LC.

Portzamparc.

----

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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090828/d655ad8b/attachment-0001.htm 


More information about the Idna-update mailing list