1. International Domain Name Committee Proceedings Report Ghana, March 2002

2. 1 ICANN IDN Committee Proceedings Report March, 2002 ICANN IDN Activities Timeline Creation of IDN Committee IDN Committee Structure Members of the IDN Committee Key Issues under Consideration IDN.IDN Keyword Issue Permissible Code Point Issue A Preliminary Framework for non ASCII TLDs UDRP Review Proposed Next Steps How to Provide Feedback to the IDN Committee Table of Contents

3. 2 ICANN IDN Committee Proceedings Report March, 2002 ICANN IDN Activities Timeline March 2001- Creation of ICANN Board IDN Working Group (Melbourne) June 2001- IDN Working Group Status Report (Stockholm) September 2001- IDN Working Group Final Report (Montevideo) September 2001- Creation of IDN Committee (Montevideo) June 2002- Expected Completion Date for IDN Committee (Bucharest)

4. 3 ICANN IDN Committee Proceedings Report March, 2002 Creation of IDN Committee At the September 10, 2001 meeting in Montevideo, the ICANN Board passed a resolution establishing a new IDN Committee "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."

5. 4 ICANN IDN Committee Proceedings Report March, 2002 IDN Committee Structure The Board has approved ten Committee Members (with more to be added at a later date), including individuals from the ICANN Board, GAC, Supporting Organizations, and other experts. Panels of Volunteer Experts from different fields and language groups will also be consulted. Charged with developing specific IDN policy alternatives and recommendations for ICANN Board consideration.

6. 5 ICANN IDN Committee Proceedings Report March, 2002 Members of the IDN Committee Masanobu Katoh (Committee Chair, ICANN Director) Mouhamet Diop (ICANN Address Council Listener) Patrik Faltstrom (IETF/IESG) Qiheng Hu (Internet Society of China) John Klensin (IAB Chair) Sang-Yong Kyong (ICANN Director) Stuart Lynn (ICANN President) Elisabeth Porteneuve (ICANN Names Council) Mohd Sharil Tarmizi (GAC Vice Chair) Vincent Wen-Sung Chen (TWNIC)

7. 6 ICANN IDN Committee Proceedings Report March, 2002 Key Issues under Consideration IDN.IDN Keywords Permissible Code Points Non ASCII TLDs UDRP Review

8. 7 ICANN IDN Committee Proceedings Report March, 2002 IDN.IDN Keyword Issue The IDN Committee strongly recommends against the introduction of Internet keyword services that utilize the period, or dot ("."), as the separator between the different name segments. This recommendation is particularly emphatic in the case of non- ASCII Internet keyword offerings. The IDN Committee recommends 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.

9. 8 ICANN IDN Committee Proceedings Report March, 2002 Permissible Code Point Issue By ‘permissible code point’ issues, we refer to the problems that might arise from the use of certain non-ASCII characters included in the Unicode Standard within IDN domain name labels. At present, the DNS host name specifications limit permissible code points in domain name labels to a restricted subset of 7-bit ASCII. In addition to the characters of every language that could be identified and standardized by the Unicode Consortium, the Unicode Standard contains several sets of "characters" that do not, in fact, appear in any conventional human language.

10. 9 ICANN IDN Committee Proceedings Report March, 2002 Permissible Code Point Issue (2) The IDN Committee has made a recommendation to the IETF that it should proceed conservatively, using an "inclusion-based" approach to the definition of "Internationalized Hostnames", so as to leave out – at least temporarily – the sets of potentially problematic characters, most notably: - line and symbol-drawing characters; - symbols and icons that are neither alphabetic nor ideographic language characters, such as typographical dingbats; - punctuation characters; and - spacing characters.

11. 10 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLD - Introductory Comments A comprehensive selection and implementation process for non- ASCII TLDs would include a number of steps, including: - Finalization of IDNA standard; - Root zone implementation testing; - Selection of registry operators; and - Registry-level testing and deployment. The focus of the next nine slides is a preliminary selection framework for non-ASCII TLDs themselves.

12. 11 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Brief Explanation of the Six Categories 1.Semantic association with Geographic Units A TLD string that to a typical reader would be clearly linked to recognized geographic unit, as is the case with the existing ASCII ccTLDs. 2. Semantic association with Languages A TLD string that to a typical reader would be clearly linked to the name of a language. For example, the Arabic word for "Arabic." 3. Semantic association with Cultural Groups or Ethnicities A TLD string that to a typical reader would be clearly linked to a cultural group or ethnicity that is not defined by recognized national boundaries. For example, the Kurdish or Swahili peoples.

13. 12 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Brief Explanation of the Six Categories (2) 6.Everything else. In this category, we mean to include every word or abbreviation that is not semantically associated with one of the previous five categories. 5.Semantic association with Existing Unsponsored TLDs A non-ASCII TLD string that to a typical reader would be clearly linked to the an existing unsponsored ASCII gTLD, such as.com,.net,.org,.info,.biz, or.name. 4. Semantic association with Existing Sponsored TLDs A non-ASCII TLD string that to a typical reader would be clearly linked to an existing ASCII sponsored TLD.

14. 13 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Advantages of each TLD 1.Semantic association with Geographic Units The existing ISO-3166-1 table provides a clear definition of recognized geographic units. The process for delegating ASCII ccTLDs is well-defined. The use of the ISO-3166-1 provides certainty both by inclusion and exclusion. The use of the principles of RFC-1591 and ICP-1 in the context of non-ASCII TLDs would provide policy clarity. A limit to the total number of TLDs eligible for delegation. 2.Semantic association with Languages Enhanced end user usability by simply create a single TLD for each non-ASCII language.

15. 14 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Advantages of each TLD (2) 3. Semantic association with Cultural Groups or Ethnicities 4.Semantic association with Existing Sponsored TLDs Giving a preference for equivalent non-ASCII strings to existing ASCII sponsored registries would be simple, and somewhat logical.

16. 15 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Advantages of each TLD (3) 6.Everything else. 5.Semantic association with Existing Unsponsored TLDs There appear to be no significant advantages, other than for the existing registry operators themselves.

17. 16 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Disadvantages of each TLD 1.Semantic association with Geographic Units The ISO-3166-1 table does not solve the problem of what non-ASCII names (or abbreviations) should be assigned to each recognized geographic unit. 2.Semantic association with Languages In a sense, a language-associated TLD string would be redundant. Language communities cross sovereign national boundaries. Languages are the products of thousands of years of history, generate tremendous emotional attachments among people. Attempting to create TLDs semantically linked to languages would raise a large number of extremely difficult political problems.

18. 17 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Disadvantages of each TLD (2) 3.Semantic association with Cultural Groups or Ethnicities All of the problems with language-associated TLDs would also apply to this set of TLD strings. As with languages, the names of cultures and ethnicities are the subjects of great emotion and, often, political controversy. 4.Semantic association with Existing Sponsored TLDs The selection of TLD registries is complicated. Each TLD string should be treated differently, and should be open for proposals to any potential registry operator that can establish the basic requirements for a sponsored TLD, including support within the community to be served.

19. 18 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Disadvantages of each TLD (3) 6.Everything else. 5.Semantic association with Existing Unsponsored TLDs Given the generic nature of the terms at issue, and the wide-ranging complexities of meaning across languages, it would be extremely difficult to determine which non-ASCII words and abbreviations should qualify for the preference. The principles registry-level competition and geographic distribution of registries both argue strongly against giving any preference to existing ASCII gTLD registry operators

20. 19 ICANN IDN Committee Proceedings Report March, 2002 A Preliminary Framework for non ASCII TLDs Summary Matrix Chart Proposed non ASCII TLD CategoryProposed Policy Reference Semantic association with Geographic UnitsISO 3166 1 Country Code list Semantic association with LanguagesNot yet defined Semantic association with Cultural Groups or Ethnicities Not yet identified Semantic association with Existing Sponsored TLDs Relevant Sponsoring Group Semantic association with Existing Unsponsored TLDs Not yet identified Everything elseNot yet identified

21. 20 ICANN IDN Committee Proceedings Report March, 2002 UDRP Review Internationalized domain names is highly likely to dramatically increase the opportunities for cybersquatting. The IDN Committee urges the UDRP Review Working Group to consider IDN issues as it performs its review

22. 21 ICANN IDN Committee Proceedings Report March, 2002 Proposed Next Steps April 1st to 21st - First Public Comments Period April 1- Announce Issue Paper for iTLDs June 17 - Final Recommendations to the Board May 6th to 26th - Second Public Comments Period May 6 - Announce Second Draft Issue Paper June 24 - 29 – Consideration by ICANN Board (Bucharest)

23. 22 ICANN IDN Committee Proceedings Report March, 2002 How to Provide Feedback to the IDN Committee The IDN Committee has established a idn-comments@icann.org e-mail address to allow interested members of the Internet Community to provide input to the Committee’s deliberations. Feedback can be provided at any time up until June 17th 2002. Comments are especially encouraged during the following formal comment periods: April 1 st to 21 st - First Public Comments Period; May 6 th to 26 th - Second Public Comments Period.

24. 23 ICANN IDN Committee Proceedings Report March, 2002 Questions