OUTCOMES REPORT OF THE GNSO INTERNATIONALIZED DOMAIN NAMES WORKING GROUP (IDN WG)

OUTCOMES REPORT OF THE GNSO INTERNATIONALIZED DOMAIN NAMES WORKING GROUP (IDN WG)

http://gnso.icann.org/issues/idn-tlds/

Wiki: http://idn.wat.ch

Working Group Chair: Ram Mohan

ICANN Staff: Olof Nordling, Maria Farrell

SUMMARY

This is the final version of the GNSO IDN Working Group Outcomes Report. This report provides a written summary of areas of broad agreement, support and discussions of the GNSO IDN-WG on issues for consideration of the GNSO Council regarding further GNSO policy development activities on IDN issues for the generic top level domain (gTLD) space.

The report concludes the work of the GNSO IDN WG on the Terms of Reference as specified by the GNSO Council.

1 Contents.. 3

2 Introduction.. 4

3 Background.. 6

4 Outcomes.. 7

4.1 Areas of Agreement 7

4.2 Areas of Support 11

4.3 Agreement and Support Matrix, by Topic. 17

5 GNSO IDN WG Membership.. 23

6 Working definitions.. 25

Objective of the IDN-WG: The GNSO IDN Working Group (IDN-WG) was chartered to address policy issues that may arise from the impending introduction of Internationalized Domain Names at the top level (IDN TLDs). Specifically, the IDN-WG was chartered to provide a report to the ICANN GNSO Council with a view to assessing further steps to take, including the possible need for the creation of a Policy Development Process (PDP) on IDN issues for the top-level.

Methodology of the IDN-WG: The IDN-WG conducted its deliberations in a variety of ways: face-to-face meetings, teleconferences (transcripts and MP3 available here), an e-mail discussion list and a wiki.

The first IDN-WG meetings held in December 2006 in Sao Paulo brought up some fifteen issues for discussion. These were compiled in a draft issues list at: http://gnso.icann.org/issues/idn-tlds/draft-idn-issue-list-22dec06.htm . Following discussions during the first conference calls of the Working Group, the issues were regrouped into seven issue areas. The WG decided that its time and attention should be allocated in proportion to the relative priority of these issue areas. The IDN-WG made no qualitative decisions regarding the importance of each issue. The following issue areas were prioritized for discussion:

• Aspects on introduction of IDN gTLDs in relation to new non-IDN gTLDs
• IDN aspects on Geo-Political Details
• Aspects relating to existing gTLD strings and existing IDN SLDs
• Aspects relating to existing SLD Domain Name Holders
• Specific Techno-Policy Details relating to IDN gTLDs

The following topics were accorded a lower priority and were only discussed initially by the Working Group:

• Particular IDN aspects relating to Privacy & Whois Details
• IDN aspects on Legal Details

This report describes the outcomes of the discussions on issues brought up following the above steps. For the expression of views, the Working Group agreed on the following conventions:

- Agreement there is broad agreement within the Working Group (largely equivalent to rough consensus as used in the IETF)

- Support there is some gathering of positive opinion, but competing positions may exist and broad agreement has not been reached

- Alternative view a differing opinion that has been expressed, without garnering enough following within the WG to merit the notion of either Support or Agreement.

This report also provides some references to consultations with the GNSO Reserved Names Working Group, where IDN-related topics were discussed, and where the IDN-WG provided both liaison and expert advice.

The GNSO IDN Working Group was chartered at a meeting of the GNSO Council on 16 November, 2006, minutes at http://gnso.icann.org/meetings/minutes-gnso-16nov06.html , when the earlier proposed Terms of Reference, available at: http://gnso.icann.org/issues/idn-tlds/idn_tor_draft-12oct06.htm, were refined to a Charter for the Working Group, available at http://gnso.icann.org/issues/idn-tlds/idn_working_group-18nov06.htm

The Working Group was tasked to provide a report to the GNSO Council and conclude its work by the ICANN meeting in Lisbon, Portugal on 26-30 March 2007. Ram Mohan of the GNSO Registry Constituency was elected Chair by the Working Group members. Following a face to face meeting held during the ICANN meeting in Sao Paulo in December, 2006, as well as a joint meeting with the ccNSO IDN WG at the same location, the Working Group was convened 14 times in conference calls. Initially, weekly paired conference calls were organized to accommodate members in different time zones. The paired calls were eventually replaced by single calls each week, with alternating times to facilitate participation from different time zones. The members of the Working Group are listed in section 5. Observers were also invited to attend and contribute to the discussions.

The Working Group reviewed the following four key documents, in line with the Terms of Reference:

• Draft Recommendations from the New gTLD PDP Committee
• Draft IDN Issues Report
• RFC 4690 of the IETF
• ICANN IDN Guidelines

Pertinent excerpts of these documents were compiled in a document for the WG, available at: http://gnso.icann.org/issues/idn-tlds/idn_wg_readers_digest.pdf

The IDN-WG deliberated on the topics as outlined in Section 2. The outcomes of its discussions are detailed in this section. The IDN-WG suggests that the GNSO Council review all outcomes. Outcomes in Section 4.1 (Areas of Agreement) are especially pointed out for review. Outcomes that have Support, with or without Alternative Views, also provide the Council input for deliberations on the potential need for, feasibility of and scope of any future IDN focused Policy Development Process (PDP) or other future steps.

4.1 Areas of Agreement

Definition:

Agreement there is broad agreement within the Working Group (largely equivalent to rough consensus as used in the IETF).

The IDN-WG did not use the word consensus since that term has a particular meaning as used by the GNSO Council.

The IDN-WG reached Agreement on the following areas:

4.1.1 Avoidance of ASCII-Squatting:

Agreement to avoid ASCII-squatting situations where applications for new non-IDN gTLD strings, if accepted for insertion in the root at an earlier stage than IDN gTLDs, could pre-empt later applications for IDN gTLDs.

E.g. a new non-IDN gTLD .caxap, if accepted, would prohibit the acceptance of a later application for an IDN gTLD .caxap (in Cyrillic script and meaning sugar in Russian).

4.1.2. GAC Consultation on Geo-political Impact:

Agreement that, within the process for new gTLD consideration, the process for determining whether a string has a geo-political impact is a challenge, and that GAC consultation may be necessary but may not provide comprehensive responses.

4.1.3. Language Community Input for Evaluation of new IDN gTLD Strings:

Agreement that a suitable process for consultation, including with relevant language communities, is needed when considering new IDN gTLD strings.

4.1.4. One String per new IDN gTLD:

Agreement that the approach of the New gTLD PDP with one string for each new IDN gTLD application is relevant, except in the rare cases when there is a need to cover script-specific character variants of an IDN gTLD string.

4.1.5. Limit Variant Confusion and Collision:

Agreement that measures must be taken to limit confusion and collisions due to variants (i.e. substitutable characters/symbols within a script/language) while reviewing and awarding new IDN gTLDs.

4.1.6. Limit Confusingly Similar Strings:

Agreement that measures be taken to ensure that an IDN gTLD string with variants (see 4.1.4 and 4.1.5 above) be treated in analogy with current practice for IDN SLD labels, i.e. strings that only differ from an IDN gTLD string by variants (see above) are not available for registration by others.

Note: This is equivalent in effect to the provisions against confusingly similar strings foreseen in the New gTLD recommendations.

4.1.7. Priority Rights for new gTLD strings and new domain names:

4.1.7a. Agreement that priority rights for new strings on the top-level do not derive from existing strings.

4.1.7b. Agreement that applications for IDN gTLDs may face challenges/objections, for instance based on claims of intellectual property rights (IPR).

4.1.7c. Agreement that priority rights for new domain names do not derive from existing domain name strings as such, but may, for instance, derive from established IPR.

4.1.8. Suggested Approach towards Aliasing:

Agreement to address aliasing as a policy issue, rather than in terms of any specific technical mode for implementation of such a feature.

4.1.9. Single Script Adherence:

4.1.9a. Agreement to not require single script adherence across all levels in an IDN gTLD. Single script adherence across all levels in an IDN gTLD is not a technical requirement, only a potential policy requirement, especially since it would be difficult to enforce uniformly beyond the second level.

Note: Single script adherence across levels is not a requirement in existing gTLDs. Second-level IDNs have been introduced in those gTLDs in accordance with ICANN Guidelines.

4.1.9b. Agreement that there should be single script adherence within a label at the levels where registries maintain control. Where script mixing occurs or is necessary across multiple levels, registries must implement clear procedures to prevent spoofing and visual confusion for users. New gTLD registries must conform to the ICANN IDN Guidelines, and must publish their language tables in the IANA Registry. Registries should be required to limit the number of scripts across labels.

4.1.9c. Agreement that new gTLDs should observe the following guidelines:

1. Mix-in of ASCII characters in other scripts should be allowed as a special case, when justified.

2. Where the accepted orthographic practice for a language requires script mixing, such mixing must be allowed.

Note: Only scripts that have Unicode support are available for gTLDs.

4.1.9d. Agreement that other considerations in limiting scripts are:

1. Official/significant languages in a country exist.

2. An IDN gTLD registry should limit the degree of script mixing and have a limit for the number of scripts allowed for its domain names. Such limits, with justifications, should be proposed by the IDN gTLD applicant and be evaluated for reasonableness.

3. In all IDN gTLD applications, the applicant should adequately document its consultations with local language authorities and/or communities. See also 4.1.3.

4. The way to define language communities is not in the purview of the IDN-WG, but CNDC and INFITT (representing Chinese and Tamil language communities, respectively) are some models to consider.

5. ICANN should consult with the relevant language communities if in doubt whether an IDN gTLD string is in compliance with relevant tables.

4.1.10. Dispute Resolution for Domain Names in new IDN gTLDs:

Agreement that UDRP proceedings regarding IDN SLDs show no deficiencies to date and that a review of the current UDRP would not be a prerequisite for accepting IDN gTLD applications.

4.2 Areas of Support

Definitions:

Support there is some gathering of positive opinion, but competing positions may exist and broad agreement has not been reached

Alternative view a differing opinion that has been expressed, without getting enough following within the WG to merit the notion of either Support or Agreement.

4.2.1

Support for a first application round open to both non-IDN gTLDs and IDN gTLDs, if possible.

4.2.2

Support for avoiding hostage situations in planning a new non-IDN gTLD application round; neither non-IDN gTLDs nor IDN gTLDs should be delayed due to the other.

4.2.3

Support for promoting public awareness of IDN gTLD application opportunities at an early stage.

4.2.4

Support for prioritizing languages/scripts for the IDN gTLD launch according to demand/need, possibly using a notion of distance to ASCII (for example, by giving priority to right-to-left scripts).

4.2.5

Support for preferential treatment of applications for particular communities in need of IDN gTLDs, for example through lower entry barriers, while safeguarding adequate levels of service to the relevant communities.

Alternative view; prioritize according to number of potential users. Alternative view; resolve policy before developing priority criteria. Alternative view; follow the approach of the new gTLD Recommendations, i.e. no priority provisions.

4.2.6

Support for resolving IDN policy issues before launch of application round.

Alternative view; prioritize launch of IDN gTLD over non-IDN gTLDs.

Alternative view; provide opportunities to reserve IDN gTLD strings in case the first application round can only address non-IDN gTLD applications fully.

Note: Whether there will be a timing issue or not depends on the progress of the new gTLD policy, including IDN policy aspects, as well as on the progress of the protocol revisions and technical tests regarding IDN at the top-level. They all need to have advanced sufficiently before a decision can be made to go ahead with IDN TLD deployment.

4.2.7

Support for avoiding further entrenchment of the usage of keyword[1] solutions.

4.2.8

Support for the view to consider input from local/regional pre-existing developments regarding IDN at the top-level, for example the experimental IDN systems supported by the Arab league and other countries, when considering introduction of new IDN gTLDs.

4.2.9

Support for a countrys rights to define/reserve IDN strings for the country name.

Alternative view; to also accept a countrys responsibility/right to approve any IDN gTLD strings featuring its particular script, if unique for that country.
Alternative view; to also acknowledge a countrys right to influence the definitions/tables of its scripts/languages.

Alternative view; to require a countrys support for an IDN gTLD string in its script, in analogy with the considerations for geo-political names.

Alternative view: recognition that countries rights are limited to their respective jurisdictions.

Note: There are potential political issues in the use of scripts, as some countries/regions claim rights to the standards for their scripts. This has also been expressed as a need to prove the support of the respective community for accepting a TLD in its particular script.

4.2.10

In reference to the development of a suitable process for consultation (See previous section on Agreement that a suitable process for consultation, including with relevant language communities, is needed when considering new IDN gTLD strings); Support for a suitably convened language committee, fairly representing the geographic distribution of the respective language community worldwide, to review the selection/adoption of an IDN gTLD string in that particular language.

4.2.11

Support for developing policy of general applicability regarding geo-political aspects.

Alternative view; to develop a set of circumstance-dependent policies, with input from relevant language communities on a case by case basis.

4.2.12

Support for review of migration/exemption possibilities for existing IDN SLDs when reducing the number of allowed code points in the IDN protocol revision, while weeding out non-script/non-language characters, if possible.

Alternative view; to afford latitude for gTLDs to set policy for IDN SLDs within the limits of desirable consistency.

Note: The IDN protocol revision with an inclusion-based approach that is more restrictive regarding allowed code points, may affect some of todays around 2 million IDN SLDs.

4.2.13

Support for addressing the topic of potential specific provisions regarding applications for IDN top-level strings from legacy gTLDs.

4.2.14

Support for treating existing gTLD registries equally in cases when they apply for IDN gTLD strings.

Alternative view; to consider preferential rules for existing sponsored gTLD registries in the above context.

4.2.15

Support for deferring the question of particular treatment of sponsored gTLDs to the New gTLD Committee, while recognizing that sponsored gTLDs differ with regard to the geographical and language scope of their sponsoring organizations.

4.2.16

Support for not offering new IDN gTLDs the option to have a single extra LDH label for aliasing purposes.
Alternative view; to offer such an option for new IDN gTLDs..

Note: Such an extra LDH label would be different from, and in addition to, the standard (punycode) A-label for the IDN gTLD.

4.2.17

Support for measures to protect the rights of others, for example through sunrise periods.

4.2.19

Support for the view that aliasing provides protection of and reduce confusion for existing domain name holders, while recognizing that there may also be disadvantages.

Support for the view that aliasing does not alleviate confusion and should be struck from a list of potential solutions.

Note: The same result for domain name holders as aliasing provides could be achieved by normal DNS means. Aliasing per se is not an IDN specific feature, even if aliasing has raised much interest in the IDN context.

4.2.20

Support for enabling a choice for an IDN gTLD registry with a string that has variants (i.e. substitutable characters/symbols within a script/language) to use variants for aliasing purposes.

4.2.21

Support for elimination of non-language characters, as foreseen in the IDN protocol revision.

Alternative view: to signal concerns about symbols that may be

eliminated but would potentially be needed for human communications.

4.2.22

Support for regarding confusingly similar as visually confusingly similar or typographically confusingly similar.

Alternative view: to give confusingly similar a wider interpretation, including phonetic similarity.

4.2.23

Support for IDN considerations for extension of reserved names list, possibly by introducing a notion of reserved concepts (for example; the concept of example as expressed in other languages/scripts).

Note: This was part of the input from the IDN WG to the RN WG for its considerations.

4.2.24

Support for recognizing a current practice to display the registrant in local script and at least one of the contacts in ASCII.

Alternative view; to prescribe that both local script and ASCII versions of Whois should be available.

Alternative view; to recognize that there may be further IDN aspects on Whois issue to investigate, including but not limited to the debate on open Whois access versus privacy concerns.

Note: There are multiple solutions already in use today for Whois regarding IDNs. There have not been many complaints on Whois for IDNs yet, but that may change with increased IDN use and improved IDN support in browsers and other software.

4.3 Agreement and Support Matrix, by Topic

4.3.1 Aspects on introduction of IDN gTLDs in relation to new non-IDN gTLDs

4.3.2 IDN aspects on Geo-Political Details

4.3.3 Aspects relating to existing gTLD strings and existing IDN SLDs

4.3.4 Aspects relating to existing SLD Domain Name Holders

4.3.5 Specific Techno-Policy Details relating to IDN gTLDs

4.3.6 Particular IDN Aspects relating to Privacy & Whois Details

4.3.7 IDN Aspects on Legal Details

Ram Mohan RyC GNSO IDN WG Chair

Bruce Tonkin RrC GNSO Council Chair

Werner Staub RrC Liaison to ccNSO/GAC IDN WG

Paul Diaz RrC

Yoav Kheren RrC

Sophia Bekele NomC Liaison to RN WG

Avri Doria NomC

Mawaki Chango NCUC

Charles Shaban IPC

Marilyn Cade CBUC

Alistair Dixon CBUC

Cary Karp RyC

June Seo RyC

Mark McFadden ISPCP

Tony Holmes ISPCP

Greg Ruth ISPCP

Maggie Mansourkia ISPCP

Norbert Klein NCUC

Chun Eung Hwi NCUC

Mike Rodenbaugh CBUC

Jonathan Cohen IPC

Tin Wee Tan NCUC

Caroline Greer RyC

William Tan RyC

Susan Estrada RyC

Eva Frhlich RyC

Will Rodger CBUC

Edmon Chung RyC

Sadik Chandiwala RyC

Daniel Dougherty IPC

Hong Xue ALAC liaison

Steve Crocker SSAC liaison

Shahram Soboutipour Observer

Sergei Sharikov Observer

S. Maniam Observer

S. Subbiah Observer

Alexei Sozonov Observer

Glen de Saint Gry ICANN Staff

Tina Dam ICANN Staff

Maria Farrell ICANN Staff

Olof Nordling ICANN Staff

In order to get a common understanding of terminology during the WG discussions, the following glossary [with sources in square brackets] was developed jointly by ICANN staff and the WG members on a dedicated wiki page for the WG.

A-label

An "A-label" is the ASCII-Compatible (ACE) form of an IDNA-valid string. It must be valid as output of ToASCII, regardless of how it is actually produced. This means, by definition, that every A-label will begin with the IDNA ACE prefix, "xn--", followed by a string that is a valid output of the Punycode algorithm and hence a maximum of 59 ASCII characters in length. The prefix and string together must conform to all requirements for an IDN that can be stored in the DNS including conformance to the LDH rule. [IDNAbis, Klensin, Internet draft 23 Feb 2007]

Alias

- An alias is a pseudonym and may refer to multiple names for the same data location. [Wikipedia] (Review needed; Aliasing in the context of our discussions refers to the practice of making multiple domains effectively identical by means of using DNAME records or other policy / operational means.)

Character

- A member of a set of elements used for the organization, control, or representation of data. [The tables for all known languages are maintained by ISO/IEC 10646. See also Unicode.]

DNAME records

- DNAME is a DNS Resource Record type. DNAME provides redirection from a part of the DNS name tree to another part of the DNS name tree. [RFC2672]

Existing gTLD

- A gTLD that has been approved to be added to the root. [proposal]

gTLD

- A generic top-level domain, directly under the top-level root of the domain name hierarchy. Most TLDs with three or more characters are referred to as "generic" TLDs, or "gTLDs". They can be subdivided into two types, "sponsored" and "unsponsored, (as well as into restricted and unrestricted). [ICANN Glossary (addition)]

IDN ccTLD (or icTLD)

- A ccTLD (country code top-level domain, corresponding to a country, territory, or other geographic location) with a label that contains at least one character not appearing in LDH set. The lists of alpha-2 and alpha-3 codes allocated to countries and territories are maintained by the ISO 3166/MA. The ISO 3166-1:2006 document provides names of countries and territories in corresponding administrative languages.

IDN gTLD

- A gTLD with a label that contains at least one character not appearing in the "LDH" set.

Keyword

A keyword in an Internet search is one of the words used to find matching web pages. It was popularized during the early days of search engine development, as it was not possible to ask natural language questions and find the desired sites. Searches gave the best results if only a few keywords were chosen and searched for. These "keywords" captured the essence of the topic in question and were likely to be present on all sites listed by the search engine. [Wikipedia] In the IDN context, keywords usually refer to ISP-specific look-up functions in a local environment with a non-Latin script.[proposal]

Label string

- A generic term referring to a string of characters that is a candidate for registration in the DNS or such a string, once registered. A label string may or may not be valid according to the rules of this specification and may even be invalid for IDNA use. The term "label", by itself, refers to a string that has been validated and may be formatted to appear in a DNS zone file. [RFC3743]

Label

- A label is an individual part of a domain name. Labels are usually shown separated by dots; for example, the domain name "www.example.com" is composed of three labels: "www", "example", and "com". [RFC3490]

Language

- A language is a way that humans interact. The use of language occurs in many forms, including speech, writing, and signing. [RFC 4690]. The lists of alpha-2 and alpha3 codes allocated to languages are maintained by the ISO 639-2/RA.

LDH

- Letters-Digits-Hyphen, with 26 possible Latin Letters, upper and lower case alike, [a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z], 10 possible Digits [0,1,2,3,4,5,6,7,8,9], and Hyphen "-" (minus).

new gTLD (in GNSO parlance;)

- A gTLD that will ensue as a consequence of the implementation of the results of the New gTLD PDP. [proposal] (In practice, the WG increasingly used the expressions new non-IDN gTLDs and new IDN gTLDs to make clear distinctions.)

Normal delegation records (or NS records, name server records)

- An NS record or name server record maps a domain name to a list of DNS servers authoritative for that domain. Delegations depend on NS records. [Wikipedia]

Punycode

Punycode is a bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). [RFC3492]

Punycode, defined in RFC 3492, is the self-proclaimed "bootstring encoding" of Unicode strings into the limited character set permitted in host names. The encoding is used as part of IDNA, which is a system enabling the use of internationalized domain names in all languages that are supported by Unicode, where the burden of translation lies entirely with the user application (a web browser for example). The encoding is applied separately to each component of a domain name which is not represented solely within the ASCII character set, and a reserved prefix 'xn--' is added to the translated Punycode string. For example, bcher becomes bcher-kva in Punycode, and therefore the domain name bcher.ch would be represented as xn--bcher-kva.ch in IDNA. [Wikipedia]

Script

- A script is a set of graphic characters used for the written form of one or more languages. [RFC 4690 and ISO/IEC 10646]

Source script label

A source script label is the form of a label that is displayed to the end user. [proposal] This expression can be used in the IDN context to distinguish a label that the end user sees in a local script from the other forms of this label, notably A-label and U-label, which are for system internal use by software applications and the DNS.

TLD: Top Level Domain

- A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy. [RFC3375]

- TLDs are the names at the top of the DNS naming hierarchy. They appear in domain names as the string of letters following the last (rightmost) ".", such as "net" in "www.example.net". The administrator for a TLD controls what second-level names are recognized in that TLD. The administrators of the "root domain" or "root zone" control what TLDs are recognized by the DNS. Commonly used TLDs include .com, .net, .edu, .jp, .de, etc. [ICANN Glossary]

Transcription

- Transcription maps the sounds of one language to the script of another language. [Wikipedia]

Transliteration

- Transliteration is the practice of transcribing a word or text written in one writing system into another writing system. It is also the system of rules for that practice. Technically, from a linguistic point of view, it is a mapping from one system of writing into another. Transliteration attempts to be exact, so that an informed reader should be able to reconstruct the original spelling of unknown transliterated words. To achieve this objective transliteration may define complex conventions for dealing with letters in a source script which do not correspond with letters in a goal script. Romaji is an example of a transliterating method. [Wikipedia]

U-label

A "U-label" is an IDNA-valid string of Unicode-coded characters that is a valid output of performing ToUnicode on an A-label, again regardless of how the label is actually produced. A Unicode string that cannot be generated by decoding a valid A-label is not a valid U-label. [IDNAbis, Klensin, Internet draft 23 Feb 2007]

Unicode

- Unicode is a coded character set containing tens of thousands of characters. A single Unicode code point is denoted by "U+" followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by two hexadecimal numbers separated by "..", with no prefixes. [Unicode Character Code Charts and RFC3490].

Variants

- Characters that can substitute for each other in a given language without changing the meaning of a word. [proposal, drawing on RFC3743]