A. Introduction
The purpose of the IDN ccPDP Working Group 1 is to is to report on and identify a feasible policy for the selection and delegation of IDN ccTLDs associated with the territories listed in the ISO 3166-1 (IDN ccTLDs) within the framework of the IDN ccPDP.
The scope of the IDNC WG is to focus on, without limitation, examination of the topics raised in joint GAC-ccNSO Issues paper and comments received on that document. It shall also take into account the proposals and recommendations of the IDNC Working Group and the Implementation Plan based on the work of the IDNC WG.
As this WG will undertake its activities within the framework of the IDN ccPDP, the limitations on the scope of a ccPDP, in particular by Article IX of and Annex C to the Bylaws, shall limit the scope of the WG’s work in a similar manner.
If issues outside this scope become apparent to the WG, the Chair of the WG should inform the ccNSO Council of the issue so that it can be taken into account and dealt with more appropriately.
As a first step the shall publish for public consultation a Topic Paper on the topics and issues, which in the view of the WG need to be taken into consideration to propose a feasible policy for the selection and delegation of IDN ccTLDs (the Issues).
Building on the Topic Paper and the comments received on that paper, the working group will draft a proposal for policy for the selection and delegation of IDN ccTLDs (Draft Recommended Policy), and any documentation necessitated by the Draft Recommended Policy.
B. Scope of the Topic Paper
The purpose of this paper is to inform and report to the community on the topics and issues as identified by the IDN WG 1 that need to be considered in developing an overall policy and to seek input and comments on them.
This document has (not) been signed off by the IDN ccPDP Working Group. Note that the WG will continue to provide their own comments and input during this consultation period.
This report and the comments received will be used to structure and propose potential directions in the next phase of this process.
Most of the issues/topics raised in this paper are based on the joint ccNSO GAC Issues Paper, draft initial report from the IDNC working Group, and the draft Implementation Plans for the Fast Track.
C. Topics and Issues relating to the introduction of IDN ccTLD
1. Which ‘territories’ are eligible for an IDN ccTLD?
The existence of IDNs as ccTLDs assumes a direct relationship between an IDN TLD string and a ‘territory’ as in ASCII ccTLDs.
a) Should this relationship be maintained?
b) If so, should the ‘territories’ which are potentially eligible for IDN ccTLDs be exactly the same as the ‘territories’ that are listed in the ISO-3166-1 list?
c) If not, should another list be used or should another mechanism be developed?
2. Should an IDN ccTLD string be ‘meaningful’?
An ASCII ccTLD string for a ccTLD is based on the ASCII two-letter entry into the ISO 3166-1 list for that territory.
An IDN ccTLD string introduced under the ‘Fast Track’ process must be a unique and meaningful representation of the name of the corresponding country or territory. A string is deemed to be meaningful if it is in the official language of the country or territory and if it is:
* The name of the country or territory; or
* A part of the name of the country or territory denoting the country or territory; or
* A short-form designation for the name of the country or territory that is recognizable and denotes the country or territory in the selected language.
a) Should under the overall policy the IDN ccTLD string be ‘meaningful’ in its representation of the name of a ‘territory’? For example, whereas .uk is ‘meaningful’ because it is a commonly used abbreviation for United Kingdom, .au is not ‘meaningful’ because the commonly used abbreviations for Australia are Oz or Aus.
b) If so, what is considered to be ‘meaningful’ how is it determined and by whom?
c) If not, should there be another criteria for determining to demarcate a string as a ccTLD?
3. How many IDN ccTLDs per ‘territory’?
Apart from some exceptions, there is one single ASCII ccTLD per listed ‘territory’.
According to the methodology for the selection of a string under the Fast Track process the number of IDN strings per territory is limited to one string per official language or script per country or territory. For purposes of the Fast Track an official language is defined as a language that has a legal status in the country or territory, or serve as a language of administration in that country or territory.
A second condition relating to the language and the ccTLD string under the Fast Track process is that it is representation in writing is not based on the Latin script nor that the requested string contains the characters (a,É,z), either in their basic forms or with diacritics.
For example in Japan more than one script is used to represent the Japanese language. In the context of this paper each individual combination of the Japanese language and a script is considered a language/script combination.
a) Should there similarly be only a single IDN ccTLD for a given language/script combination for each ‘territory’ or can there be multiple IDN ccTLD strings? For example, should there be only one equivalent in each of the Chinese language/script combinations and one in Russian/Cyrillic for Russia?
b) Should under the overall policy the language and string only be limited to non-Latin scripts either in its basic form or with diacritics?
c) Can a ‘territory’ apply for an IDN ccTLD string even if the language/script combination does not have any ‘official status’ in that ‘territory’? For example, should Australia be enabled to apply for a ccTLD in the Japanese/Kanji combination even though this language/script combination has no ‘official’ status in Australia?
d) If ‘official status’ is required who will define it and who will determine it in each case?
e) According to the Fast Track methodology there can be several IDN strings for a ‘territory’ in a script (one per official language, see also question a. under this section). If this remains to be the case under the overall policy, who would determine the number and what are the criteria?
f) If an IDN ccTLD string is not applied for, for whatever reason, should an IDN ccTLD string that could be associated with a particular ‘territory’ be reserved or protected in some way? If so, what is the mechanism, and who should maintain the mechanism (see also section 6).
During the preparation of the Fast Track process some countries and territories have expressed the concern that limitation to one string per language/script combination may cause issues relating to the allocations and delegation of variant TLDs allocated in the DNS. The topic of delegation of variant TLDs and management thereof of variant has been discussed broadly in the technical and policy community.
g) Should the overall policy address the allocation and delegation of variants of a TLD string?
h) If so, how should they be treated in the context of questions a), as one individual string or otherwise?
i) In what circumstances would it be appropriate to seek to introduce a limit on the number of language/script combination a ‘territory’ may choose to introduce for a ccTLD or any TLD with a national connection?
4. Number of characters in the string?
Currently, ccTLD strings are limited to 2 US-ASCII characters and gTLDs to 3 or more. It is understood that abbreviations can be problematic for internationalized TLDs as abbreviations used in US-ASCII are not used on a global basis in all scripts. The underlying nature of IDN makes the actual string inserted in the DNS always longer than two characters when expressed in Unicode (due to the IDNA requirement to prefix internationalized labels with ‘xnÑ’).
Under the Fast Track process the following criteria apply:
1. the string must be a minimum of two characters long,
2. characters are counted as basic Unicode components,
3. the string does not need to be the entire country or territory name, nor does it need to be an acronym, as long as the string fulfills the meaningfulness criteria described further below, and
4. the string must not be longer than 63 characters.
In this context:
a) Should all IDN ccTLD strings be of a fixed length, for example by retaining the two-character limitation that applies to ASCII ccTLD labels, or can they be of variable length? If a variable string length is introduced for IDN ccTLDs, should it also be introduced for ASCII ccTLDs?
b) Does moving outside the current 2-symbol limitation create any security, stability or integrity issues?
c) Who determines the appropriate label used to represent a new IDN ccTLD string, and how are the set of characters used to represent this label selected?
5. Are technical requirements for the IDN ccTLD string needed?
To ensure the stability and security of the DNS an IDN ccTLD string as requested under the Fast Track process must meet certain technical requirements.
a) Should similar technical requirements apply under the overall policy? If not, are other criteria needed or none?
b) If yes, should there be a mechanism to update these criteria? And if so, what is the mechanism? And who should update the criteria and maintain that mechanism?
6. Should a list of IDN ccTLD strings be mandated?
In the US-ASCII case, ccTLD strings are currently primarily based on the ISO 3166-1 Alpha 2 list. If a similar mechanism were adopted for IDN ccTLDs, this could mean that to every country or territory listed a ‘code’ would be assigned that would serve as a representation, and would be used as an IDN ccTLD string(s) to represent it.
a) Is such a list or other list necessary and required to introduce and delegate IDN ccTLDs under the overall policy?
b) Who would develop the criteria and relevant policies for such a list?
c) Under what policy or authority would the list be created?
d) Who would develop such a list?
e) Should such a list be mandated? If yes, by whom? Should this be done prior to delegation of IDN ccTLDs under the overall policy?
f) If additional criteria and or policies are required, who is responsible for formulating that policy? For example, assuming that the IDN ccTLD string must need certain technical criteria, which is responsible and ensures that, the entries in the list when used as an IDN ccTLD meet the technical criteria.
6.Who selects the IDN ccTLD string in the absence of a list?
Under the Fast Track process IDN ccTLDs string are not selected on the basis of exhaustive list.
a) If under the overall policy IDN ccTLD strings would not going to be derived from a list (see previous section) then, how does an IDN ccTLD string will be selected as the string for a particular ‘territory’?
b) What are the criteria and policies to determine who can submit a request for the designation of an IDN ccTLD?
c) Who will develop the criteria and policies for determining the designation of an IDN ccTLD?
d) How will such issues as competing requests (both domestic and international) be dealt with?
e) What will happen if 2 ‘territories’ are eligible for the same or confusingly similar strings for IDN ccTLD?
Under the Fast Track process there is no objection procedure regarding the proposed IDN ccTLD string.
f) Once a string has been selected in accordance with the requirements and any criteria, should objections be allowed?
g) If so, who can object and on what grounds?
h) If an objection is lodged, what is the impact?
7. Are there any ‘rights’ attached to a given script?
In purely technical terms, a script is a collection of symbols. However, each of those collections of symbols when put together in particular ways produce the ‘languages’ of groups of people sometimes defined by borders, although very often not. These groups are often referred to as language communities.
a) Should such groups (or their governments) have special rights regarding those scripts? For example, should the Korean language community be entitled to restrict the use of the Hangul script? If special rights exist what is the procedure to exert these rights and resolve conflicts?
b) Can anyone get acceptance of a script under the IDNA protocol or are there restrictions? For example, can a gTLD registry get the Kanji script accepted under the IDNA protocol? Should that use be vetted/approved by Japan? If yes, would the same requirement apply if a script were used in more then one ‘territory’?
c) Should it be possible to adopt two or more ‘versions’ of a script with only minor differences for use under the IDNA protocol and are there issues or concerns should this occur?
8. What precedence should be given to ccTLDs under the Fast Track process?
9. Delegation, Re-delegation and retirement of IDN ccTLDs
Under the Fast Track process, at the direction of the ICANN Board of directors, IDN ccTLDs are delegated on the basis of the current practices for delegation of (ASCII) ccTLDs . Under the Fast Track process it is also assumed that the current practices for re-delegation and retirement apply.
a) Should the same practices for delegation, re-delegation and retirement apply to both (ASCII) ccTLDs and IDN ccTLDs?
b) Are there additional requirements relating to the delegation of an IDN ccTLD? If so, what are these requirements? Does the IDN ccTLD manager need to be evaluated against the requirements and if so by whom?
10. What coordination should exist between the different actors?
The deployment of IDN ccTLDs will require coordination among various actors, at various stages of the process within territories and ICANN, comparable to the coordination needed under the current delegation, re-delegation and retirement processes. Irrespective of the methodology employed, some coordination questions must be addressed, such as:
a) Who are the appropriate actors?
b) What are their roles?
11. Operation of IDN ccTLDs
Is the operation and management of an IDN ccTLD different to that of an existing US-ASCII ccTLD such that there are specific global technical requirements, in addition to the general IDN standards, needed for the operation of an IDN ccTLD? If so, how are those requirements developed and who would develop them?
D. Background (To be completed)
5
Version 01 18 September 2009