One necessary step in the publication process is the assignment of an
ACE prefix ("ACE" stands for ASCII Compatible Encoding) for
the proposed standard (see Section 5 of <draft-ietf-idn-idna-14.txt>).
This assignment is the responsibility of the IANA, which has scheduled
the selection of the ACE prefix for 11 February 2003, with a public
announcement immediately afterward. The RFC Editor will then assign RFC
numbers and take the other steps required to complete its publication
On behalf of Masanobu Katoh, Chair of the ICANN IDN Committee, and
myself, I am writing to give you some information about ICANN's newly-formed
Internationalized Domain Name (IDN) Registry Implementation Committee,
and to invite the participation of those registries that are currently
undertaking operational implementation of the IETF's Internationalized
Domain Names in Applications (IDNA) standard.
- Purpose of IDN Registry Implementation Committee
In October, the IESG approved the publication of "Internationalizing
Domain Names in Applications" (IDNA) as a standards-track protocol.
The focus of domain-name internationalization efforts will now shift
from standard setting by the IETF to implementation by the existing
TLD registries that will implement the IDNA protocol at the second level
While IDNA is an exciting development for the DNS, it brings with it
significant risks. The DNS functions well in part to due its simplicity
of design and well-developed documentation; IDNA represents a new set
of complications that must be well understood and accounted for by implementing
registries. For example, the IDNA protocol enables the translation of
all Unicode code points into unique ASCII strings. It has become clear
over the past year that collisions, confusion, and other potentially
damaging side-effects will arise if registration of all arbitrary characters
available in the Unicode encoding system is permitted. These and other
potential problems cannot be solved at the protocol level; they must
instead be addressed by registries in their technical implementations
and registration policies.
Because these problems are common to all DNS registries (both gTLD
and ccTLD) that choose to implement IDNA, it is essential to have a
global forum for registry-level dialogue, consultation, and exchange
of information, open to the registries, registrars, and technical experts
closest to the issue. Accordingly, in December the ICANN Board directed
me, in consultation with Katoh-san, to convene a President's IDN Registry
Implementation Committee "to consider and exchange information
on ways to resolve the issues associated with implementation of IDN
capabilities in existing top level domains."
The relevant ICANN Board resolutions can be found at:
For the benefit of Internet users everywhere, it is extremely important
that the registries pioneering the implementation of IDNA share information
and experiences with each other, particularly on issues of common concern,
such as the use of character equivalence tables. See, for example, the
proposed "Internationalized Domain Names Registration and Administration
Guideline for Chinese, Japanese and Korean", draft-jseng-idn-admin-02.txt.
Membership in the IDN Registry Implementation Committee is intended
for those who are directly involved in the implementation of IDNA (such
as registry-level IDN project managers), and several independent IDN
There is a tension between keeping the committee as open as possible,
and keeping it small enough to get its work done. Accordingly, I am
advising registries of the following guidelines. For gTLD and ccTLD
registries, I invite any registry that is currently working to implement
IDNA within the next six months to nominate someone at the level of
a project or technical manager in other words, an individual
with actual responsibility for IDNA implementation. For the gTLD registrars,
I have invited the Registrars Constituency to name two such individuals
from among its member registrars. And for technical expertise, I have
invited several of the IETF architects of IDNA to join as well.
Please do let me know if your registry meets these guidelines and wishes
to participate; and, if so, the name of the person you wish to rperesent
your ccTLD on the Committee.
To provide continuity and to ensure optimal communications, I have
invited Katoh-san to chair the new IDN Registry Implermentation Committee
while he continues to chair the IDN Committee, and he has graciously
agreed to accept this dual role. He has also requested that I serve
on the IDN Registry Implementation Committee, and I am pleased to do
The IDN Registry Implementation Committee will begin immediately. Work
will proceed via mailing list and, if needed, the occasional teleconference.
I anticipate that the Committee members will begin by sharing information
and plans for registry-level IDN registration and administration policies,
including the use of character equivalence tables (such as the CJK guidlines
cited above) and the exclusion of certain non-language code point ranges.
It is important to emphasize that the committee is not intended to set
hard rules for ccTLD registries, but rather to facilitate dialogue and
information sharing so that IDNA project managers can educate and learn
from each other and develop common solutions to common problems.
Both Katoh-San and I look forward to working with the ccTLD registry
community on these important problems.
Please feel free to contact me with any questions you might have.
 The three standards-track IETF documents comprising
Since 1999, the IANA has maintained the authoritative database
concerning the delegation of ccTLDs. This database is published in a variety
Recently an additional field has been added to the database to display
the domain names at which port 43 Whois services are available
for each of the ccTLDs. It you want your port 43 Whois service listed,
please send an e-mail message to <firstname.lastname@example.org>
with the domain name of the host at which the service is available.