Dear Colleagues,

The IAB has noticed the continued work the Unicode Consortium is doing
with TR46. The IAB strongly advises the Unicode Consortium to be extremely
explicit in its recommendations so that the reader of both the
IDNA2008 specifications and TR46 do not end up being confused, and, in
particular, conclude that the two documents contradict each other.

A fundamental issue with IDNA2003 was that it created confusion as to
what is a valid domain name. The entire space of unmapped and mapped
forms become "valid" domain names since some such instances would be
mapped into what IDNA2008 calls PVALID U-label constructs. However,
those instances could not be mapped back to the original form:
information about what the original form had been was lost and users
often entered one name but saw what appeared to them to be a rather
different one after IDNA operations.

The introduction of extensive or required mapping into IDNA2008
expands on and risks changing one of the fundamental values of
IDNA2008: the normative and strict definition of U-label/A-label
duality. U-labels are made up only of strings of Unicode code points
that convert 1:1 into "Punycode" A-label forms.

To be more precise, the IAB is concerned over two possible
consequences if the concepts as described in TR46 (currently the
version of 2010.02.04) were approved:

(1) That TR46 will describe implementation of "mapping" of characters
in such a way that users think the domain name that is mapped
into an A-Label/U-Label pair --one that would not be possible to
use without the mapping-- would also be a valid domain name.

(2) That TR46 will suggest a transition from IDNA2003 to IDNA2008
conventions whose consequence will be that the number of changes
for the Internet Community will be two, instead of one. While we
recognize the difficulties with the transition, we believe that
one transition, even if painful, is better than two painful
transitions and that dragging the transition process out longer
than necessary will serve no one well.

Regarding the first, the IAB is concerned about the possibility of domain
name holders becoming confused over what domain name they have
actually registered. Several sets of guidelines that go back to the
time RFC 3490 was published made suggestions that would have prevented
that situation, but confusion about which ones were applicable and
inconsistencies among them (as well as ignorance of them and a
minority of domain administrators who where indifferent to confusion
and related problems) led to those guidelines being widely ignored.
We fear a repetition of the problem if people read UTR 46 as
contradicting the clear requirements of the IDNA2008 protocol.

"Helping" the user at the time of typing a domain name is one thing,
making the user believe that anything that is typed can also be
resolved is another. The IAB agrees with the consensus in the IETF that
only the domain names that are valid according to IDNA2008 -- hence
valid A-label/U-label pairs -- are valid domain names. The IAB thinks
this design choice of having a strict 1:1 mapping between U- and
A-labels to be an important decision and one with which we agree. The
IAB has also discussed similar possibilities for confusion in RFC
2825 and draft-iab-idn-encoding-01.txt (current version as of Jan 25,
2010) [work in progress].

The IETF is also still working on its own mapping recommendations as
represented in current versions (e.g., -05) of
draft-ietf-idnabis-mappings and other discussions. No decision has
been made and the risks for confusion are very high if the Unicode
Consortium issues a standard while the IETF is still working on what
the WG, at least so far, believes should be a set of recommendations.

Another, perhaps broader, issue is that the IETF specifications were
developed with careful and expert consideration of the actual DNS
applications, implications for the many uses of the DNS protocols, and
operational considerations for the DNS. That work included
considering input from various actors and application developers in
the DNS space, not just, e.g., web browsers and web-based
applications. As the IETF moves to update other protocols and tables
that were originally developed as part of IDNA (such as "Stringprep"
(RFC 3454)), reviews of optimal behavior of each of the relevant
applications are a near-certainty. We recognize UTC's expertise in
character, coding, and character classfications and want and need to
work with you to get things as nearly right as possible in those
areas. At the same time, many of the decisions about how to apply and
profile Unicode need to be made in the context of the actual
applications and operations in which it will be used. We hope and
believe that the Unicode Consortium will continue to recognize the
expertise of the IETF and the IETF's processes in those areas.

We are also concerned that the existence of two recommendations about
mapping (even if one is for extensive mapping and the other is that as
little mapping be done as possible and only in narrow contexts), will
inherently lead to confusion. This may result in one part of the
industry assuming that alternate character issues are resolved and
only U-labels and A-labels appear while another part of the industry
acts assuming the deviations and their related security problem need
acting upon. That could exacerbating the problem and cause
considerable user-perceived interoperability issues in proactive.

The IAB therefore requests that the Unicode Consortium very carefully
considers the wording in any potential versions of TR46. We assume
that, as part of our healthy liaison relation, you will at least give
us the opportunity to perform a final review of the penultimate TR46
draft, make recommendations based on its possible impact on the IETF
standards and their implementation and, as needed, suggest changes to
reduce potential applications problems or implementer confusion.


For the IAB,

Olaf Kolkman
IAB Chair