Internationalized Domain Names (IDN) Committee
Final Report to the ICANN Board
27 June 2002

1.0 Executive Summary

The ICANN Board established the Internationalized Domain Name ("IDN") Committee at the ICANN Meeting in Montevideo in September 2001. The Board directed the committee to "to serve as a general coordination body for the work on policy issues identified in the IDN Working Group Report and such other policy issues that the IDN Committee shall identify."

To that end the committee has developed draft policy frameworks employing a bottom-up process, after consulting a wide range of expertise on the issues at hand.

Specifically the committee has:

• Published a briefing paper regarding Internet keyword issues;
• Made a public statement strongly recommending against the use in Internet keyword services of the period, or dot ("."), as the separator between the different name segments;
• Published a briefing paper regarding IDN permissible code point problems;
• Communicated a statement of input to the Internet Engineering Task Force ("IETF") on permissible code point problems;
• Published a discussion paper on non-ASCII top-level domain policy issues^[1] ; and
• Published a discussion paper on registry selection considerations for non-ASCII top-level domains.

A significant portion of the ICANN community continues to support the deployment of IDNs.^[2] There is broad recognition that IDNs are highly likely to help facilitate Internet use by the majority of the world's population whose native scripts are non-Latin. However, a number of crucial technical and policy issues essential to ensuring that IDNs might be deployed in a manner that does not harm the stability of the Internet remain unresolved including:

• Finalization of the International Domain Names in Applications (‘"IDNA") standard;^[3]
• The decision whether and when to proceed and adopt non-ASCII TLDs;
• Root-zone implementation testing;
• Selection of registry operators; and
• Registry-level testing and deployment.

The committee received wide ranging stakeholder feedback that indicated that significant support within the ICANN community exists for an IDN policy framework based on extending existing policies and concepts for the creation of ASCII generic TLDs (gTLDs) and ASCII country-code TLD (ccTLDs) employing a taxonomy of classifications linked to the evident semantic meaning of the TLD strings themselves.

In addition to specific recommendations contained within the papers and statements noted above the Committee makes the following top level recommendations:

• The ICANN Board should continue to take a conservative approach to IDN policy issues; and
• ICANN's ongoing policy development and co-ordination role should be facilitated by a yet-to-be-established Expert Group that serves as a general advisory body for the ICANN board and community on IDN and internationalization issues.

2.0 Introduction

ICANN's "Internationalized Domain Name" (IDN) efforts were the subject of a 25 September 2000 resolution by the ICANN Board of Directors, in which it recognized "that it is important that the Internet evolve to be more accessible to those who do not use the ASCII character set," but stressed that "the internationalization of the Internet's domain name system must be accomplished through standards that are open, non-proprietary, and fully compatible with the Internet's existing end-to-end model and that preserve globally unique naming in a universally resolvable public name space."

In March 2001, the ICANN Board created an internal working group to investigate facts and identify issues that may arise concerning IDNs. The internal working group issued its final report on 28 August 2001. Based on that report the ICANN Board created the IDN Committee. Major recommendations were:

• The ICANN Board should encourage the adoption of an IDN standard by the IETF.
• ICANN should charter a steering committee with representatives from the supporting organizations, the GAC, and the Working Group to advise the Board on policy issues relating to IDNs.

The committee understands that the Internet Engineering Task Force's IDN Working Group is in the last call phase of the Request for Comment ("RFC") process with respect to the proposed IDNA protocol.

3.0 Activities of the Committee

3.1 Formation and Composition

The ICANN Board established the IDN committee at the ICANN meeting in Montevideo in September 2001 by resolutions 01.94 through 01.100. The members of the IDN Committee are:

• Vincent Wen-Sung Chen (TWNIC)
• Mouhamet Diop (ICANN Address Council)
• Patrik Faltstrom (IETF/IESG)
• Qiheng Hu (Internet Society of China)
• Masanobu Katoh (Committee Chair) (ICANN Director)
• John Klensin (Former IAB Chair)
• Sang-Hyon Kyong (ICANN Director)
• Stuart Lynn (ICANN President)
• Elisabeth Porteneuve (ICANN Names Council)
• Mohd Sharil Tarmizi (GAC Vice Chair)

3.2 Schedule of Activities

The committee has met face to face in Taipei in January 2002, at ICANN Accra in March 2002, and is due to meet for its final face to face meeting at ICANN Bucharest. A significant fraction of the committee, including both DNS technical experts, have unfortunately not been able to attend the face to face meetings. In addition it has held a total of nine teleconference meetings. Since its inception the committee has sought and received input from a range of experts as it deemed necessary.

3.3 Nature of Committee

The committee was created by ICANN Board resolutions 01.94 through 01.100, which directed it to:

Serve as a general coordination body for the work on policy issues identified in the IDN Working Group Report and such other policy issues that the IDN committee shall identify.

And to:

Be responsible for promoting the coordination of the work of the ICANN supporting organizations, committees, and other groups on the policy issues arising from IDNs, as documented in the final report, and to promote timely development of policy recommendations on those issues for consideration by the community and the ICANN Board;

Seek to ensure that any recommendations are achieved through a bottom-up process, and that those recommendations reflect a wide range of expertise on the different aspects relevant to the issues; [and]

Commission panels of volunteer experts from different countries with practical experience in the policy issues identified in the Final Report, and linguistic experts (including experts in non-ASCII character sets and languages not spoken by persons active in current discussions); ....

3.4 Summary of Findings and Recommendations - Internet Keyword Issues Briefing Paper and Statement on IDN Keyword Issues

This briefing paper provided background information, defined the potential problems, and reviewed the policy considerations and issues from an ICANN perspective. It advised strongly against the introduction of Internet keywords using the dot (".") as a separator, on the grounds that (1) that format would generate needless user confusion with DNS domain names, and (2) there is a vast range of alternatives to the dotted notation format that now characterizes DNS hostnames.

The committee said:

To be abundantly clear: the IDN committee believes that Internet keyword services can be valuable tools for many Internet users; in the interest of avoiding unnecessary user confusion, however, keyword providers should simply avoid mirroring the dotted format of DNS domain names.

Finally, the IDN Committee recommended that ICANN and its Domain Name Supporting Organization (particularly the registries and registrars) consider how best to educate Internet users about the differences between DNS domain names and Internet keywords, particularly if and when the IETF's IDNA standard is completed and deployable.

3.5 Summary of Findings and Recommendations – IDN Permissible Code Point Problems Briefing Paper and Input to the IETF on Permissible Code Point Problems

On 27 February 2002 , the committee published a briefing paper on IDN permissible code point problems, available online at <http://www.icann.org/committees/idn/idn-codepoint-paper.htm>. On the same date the committee published its input to the IETF on permissible code point problems, available online at <http://www.icann.org/committees/idn/idn-codepoint-input.htm>.

This briefing paper addressed a set of IDN policy issues referred to as "permissible code point" problems. The paper began with a definition of the issue, and then summarized some specific policy problems that appear likely to arise upon implementation of the IDNA standard that is under consideration by the IETF.

In a related paper, entitled "input to the IETF on permissible code point problems", the committee urged the IETF to determine the set of code points to be permitted by the IDNA standard – i.e. what code points should be added to the existing LDH hostname specification – in a cautious, conservative manner, in order to avoid imposing potentially harmful policy choices by default. More specifically, the committee recommended that the IETF employ an "inclusion-based" mechanism for identifying permissible code points, and that at least the following sets of characters not be included, pending further analysis:

• Line and symbol-drawing characters;
• Symbols and icons that are neither alphabetic nor ideographic language characters, such as typographical and pictographic dingbats;
• Punctuation characters; and
• Spacing characters.

These comments were submitted to the IETF's Internet Engineering Steering Group (IESG) for its consideration.

3.6 Summary of Findings and Recommendations – Non-ASCII Top-Level Domain Policy Issues Discussion Paper

On 17 April 2002, the committee published a discussion paper on non-ASCII top-level domain policy issues, available online at <http://www.icann.org/committees/idn/non-ascii-tld-paper.htm>. On 13 June 2002 the committee published a revised draft of this paper available online at </committees/idn/non-ascii-tld-paper-13jun02.htm>.

This paper suggested a tentative framework for classifying possible non-ASCII TLDs based on the semantic meaning of the TLD string. The rationale for classification recognized that different types of TLDs (whether ASCII or non-ASCII) may require different selection mechanisms, depending upon the peculiar policy considerations that arise in connection with each category.

Following from these premises, the committee undertook to imagine the DNS namespace as a whole (including ASCII and non-ASCII TLDs), and to attempt a general (and probably incomplete) classification of potential TLD strings, oriented around semantic meaning.

The following basic possible categories were identified:

1. Semantic association with Geographic Units
2. Semantic association with Languages
3. Semantic association with Cultural Groups or Ethnicities
4. Semantic association with Existing Sponsored TLDs
5. Semantic association with Existing Unsponsored TLDs
6. Everything else.

A detailed analysis of advantages and disadvantages associated with this taxonomy was described. Comments were invited from the ICANN community both in respect to a series of specific posed questions and more generally about any issues raised within the paper. The comments received are referenced in summary form in Section 6.2 of this report.

3.7 Summary of Findings and Recommendations – non-ASCII TLD Registry Selection Policy Considerations

In this paper, the committee addressed issues that would arise in selecting registry operators for non-ASCII TLDs.  Continuing with the general view that procedures for ASCII and non-ASCII TLD should be harmonized, the committee examined the question of whether any special policies or considerations for the selection of registry operators would be required in the context of non-ASCII TLDs.

Key criteria proposed for registry selection were discussed:

• Technical competence;
• Support from relevant community of interest;
• Independent evaluation panels; and
• Incumbency preference issues.

3.8 Additional Policy Comments

During the course of its deliberations, the committee has identified a non-exhaustive set of policy issues that, although not necessarily central to its main policy focus, were deemed important enough to make note of in this report. The purpose of this is twofold:

• To raise ICANN community awareness of these issues; and
• To ensure that they are considered as IDN policy development continues in the future.

Examples of these issues are:

3.8.1. Nothing within any future non-ASCII TLD space inherently constrains names or labels to any language character set.   For example, nothing in the protocols would prevent a domain label from being created (at the top-level or otherwise) that consists of a Chinese character, followed by a Roman-derived character, followed by a Thai character, followed by an Arabic character, followed by a Cyrillic character, etc.

3.8.2. Even if IDNs not compatible with a given language at the second level of a TLD are prohibited, enforcement of this at the third or fourth level or beyond is likely to prove challenging. ^[4]

3.8.3. If a non-ASCII TLD is approved based on representations made in any given registry proposal (regarding, for example, permissible character sets and names, communities to be served etc.), then procedures for holding the registry to such representations will need to be developed.

3.8.4. In order to avoid an unmanageable expansion of TLDs within the DNS, consideration needs to be given to the desirability of rules regarding the translation of the names of existing TLDs to different languages. For example, if it were deemed appropriate to approve a sponsored TLD to serve museums in Korea , then it would also be necessary to consider whether it would also be appropriate to have sponsored TLDs for Irish museums, Hindi museums, Thai museums, and so on for hundreds of other languages.

4.0 Next Step Recommendations

• The ICANN Board should continue to take a conservative approach to IDN policy issues; and
  
  
• ICANN's ongoing policy development and co-ordination role should be facilitated by a yet-to-be-established Expert Group that serves as a general advisory body for the work on policy issues identified in the IDN Working Group Report, this report, and such other relevant Internationalized policy issues that the ICANN Board might identify".

5.0 References

The following non exhaustive list of references was considered and or cited during the course of Committee's consideration.

[RFC952] K. Harrenstien, M.K. Stahl, E.J. Feinler, "DoD Internet Host Table Specification," RFC 952, October 1985.

[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," RFC 1034, November 1987.

[RFC 1035] P. Mockapetris, "Domain Names - Implementation and Specification," RFC 1035, November 1987.

[RFC1123] R. Braden, "Requirements for Internet Hosts - Application and Support," RFC 1123, October 1989.

[RFC 1591] J. Postel, "Domain Name System Structure and Delegation," RFC 1591, March 1994.

[RFC 3066] H. Alvestrand, "Tags for the Identification of Languages," RFC 3066, January 2001.

The Unicode Standard, Version 3.1.1, defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 <http://www.unicode.org/reports/tr27/> and the Unicode 3.1.1 Update Notice <http://www.unicode.org/versions/Unicode3.1.1.html>: The Unicode Consortium.

P. Faltstrom, "Internationalizing Domain Names in Applications (IDNA)," draft-ietf-idn-idna. Most recent version: <http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt>.

Paul Hoffman and Marc Blanchet, "Stringprep Profile for Internationalized Host Names," draft-ietf-idn-nameprep. Most recent version: <http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-07.txt>.

Adam Costello, "Punycode," draft-ietf-idn-punycode. Most recent version: <http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt>.

Evgeniy Gabrilovich and Alex Gontmakher, "The Homograph Attack," Inside Risks 140, CACM 45, 2, February 2002, <http://www.csl.sri.com/users/neumann/insiderisks.html#140>.

John Klensin , "Role of the Domain Name System". Most Recent Version: <http://search.ietf.org/internet-drafts/draft-klensin-dns-role-02.txt>.

6.0 Thanks

The committee wishes to thank the following people who contributed valuable feedback for its consideration via e-mail during the course of the committee's tenure.

• Asaad Alnajjar of Millennium Inc. and the Arabic Internet Names Consortium (AINC)
• Marilyn Cade of AT&T
• Prof. Kilnam Chon
• Roger Cochetti of VeriSign
• Peter Constable of the Non-Roman Script Initiative, SIL International
• Martin Duerst , W3C Internationalization Activity Lead, PSO-PC member
• Richard Hill of the International Telecommunication Union
• Håvard Hjulstad , Chairman of ISO/TC37 and convener of ISO/TC37/SC2/WG1
• Hiro Hotta of JPRS
• Cary Karp of the Museum Domain Management Association
• S. Maniam of the International Forum for IT in Tamil (INFITT)
• Jeffrey J. Neuman of  NeuStar , Inc.
• Stefan Probst
• James Seng
• Siavash Shahshahani of the . ir ccTLD Registry
• Konstantin Vinogradov of the International Centre for Scientific and Technical Information (ICSTI)
• Eric Brunner-Williams of Wampumpeag LLC
• Cord Wischhöfer of the ISO 3166 Maintenance Agency
• Yoshiro Yoneya
• Danny Younger

7.0 Attachments

7.1 Papers Published

7.1.1 Briefing Paper on Internet Keyword Issues
<http://www.icann.org/committees/idn/idn-keyword-paper.htm>

7.1.2 Statement on Internet Keyword Issues
<http://www.icann.org/committees/idn/idn-keyword-statement.htm>

7.1.3 Briefing Paper on IDN Permissible Code Point Problems
<http://www.icann.org/committees/idn/idn-codepoint-paper.htm>

7.1.4 Input to the IETF on Permissible Code Point Problems
<http://www.icann.org/committees/idn/idn-codepoint-input.htm>

7.1.5 Discussion Paper on non-ASCII Top-Level Domain Policy Issues
<http://www.icann.org/committees/idn/non-ascii-tld-paper.htm>

7.1.6 Discussion Paper on non-ASCII Top-Level Domain Policy Issues Second Draft
<http://www.icann.org/committees/idn/non-ascii-tld-paper-13jun02.htm>

7.1.7   Registry Selection Considerations for non-ASCII Top-Level Domains
<http://www.icann.org/committees/idn/registry-selection-paper-13jun02.htm>

7.2 First Round Public Feedback Summary

7.2.1  Structured Question Comments
<http://www.icann.org/committees/idn/feedback1-structuredquestioncomments.htm>

7.2.1  General Comments
<http://www.icann.org/committees/idn/feedback1-generalcomments.htm>

7.2.1   Specific Comments
<http://www.icann.org/committees/idn/feedback1-specificcomments.htm>

7.3 Second Round Public Feedback Summary
<http://www.icann.org/committees/idn/feedback2.htm>

[1] The phrase "non-ASCII top-level domains" refers to domains whose names, at the topmost level, i.e., the presentation forms of the names that appear in the root zone file, contain one or more non-ASCII characters.

[2] It is likely that IDNs are widely supported only insofar as they are perceived as a solution to the problem of referencing and accessing Internet services. Further it is worthy of note that a number of technical experts have suggested non DNS solutions to this problem. See John Klensin , "Role of the Domain Name System".  Most recent version: <http://search.ietf.org/internet-drafts/draft-klensin-dns-role-02.txt>

[3] If IDNA (or any other ACE-based method) is the agreed-upon solution for IDNs, it is important to make the distinction between "the presentation form of a DNS name" as opposed to the name itself (or its "DNS form", if you prefer).  IDNA does not permit any non-ASCII characters to appear in the DNS.  It is, instead, a client-side protocol and set of conventions that permit particular types of ASCII strings to be interpreted as Unicode (ISO 10646) characters.

[4] If the IDNA standard currently under IETF consideration is approved and permitted, there will be no such  thing, except by convention, as a "Japanese domain name", or an "Arabic domain name", or an "non-ASCII domain name".  A registry controlling a domain at a particular level would be able (ICANN permitting) to create and enforce rules at the registry level that insist that all sub-domains of that domain be words in a particular language, or be made of exclusively of characters used in some particular script (which characters it lists), and so on.  But, in general, such rules will be unenforceable below the registry level.  An "IDN", under the IDNA scheme (and any other conceivable scheme given properties of the DNS) will be able to be an arbitrary mix of permitted Unicode characters, in any combination or sequence, just as current domain names (as registered and accepted by applications) may be any arbitrary mix of permitted ASCII characters, in any combination or sequence (as long as the restrictions on the location of hyphen are obeyed).

Page Updated 29-Jun-2002
©2002  The Internet Corporation for Assigned Names and Numbers. All rights reserved.