Internationalized Domain Names (IDN) Committee
Discussion Paper on
Registry Selection Considerations for non-ASCII Top-Level Domains
13 June 2002
This paper summarizes some preliminary thinking among the members of the ICANN Internationalized Domain Name (IDN) Committee about relevantconsiderations in the selection of registry operators for non-ASCII top-level domains (TLDs). As ever, the committee emphasizes that this document is preliminary in nature; non-ASCII TLDs can become a reality only when the IETF completes work on a technical standard allowing the use of non-ASCII characters as part of the DNS protocols.
In our previous discussion paper on Non-ASCII Top-Level Domain Policy Issues, the committee described a taxonomy for classifying potential new non-ASCII TLDs on the basis of the semantic meanings associated with the TLD string itself. In general, the committee suggested that non-ASCII TLDs should, to the extent feasible, be treated like ASCII TLDs. Thus, proposals for non-ASCII TLDs that match the names of recognized geographic units should be handled just like ASCII ccTLD proposals. Likewise, proposals for non-ASCII generic strings should be subjected to the same process as proposals for ASCII new TLDs.
In this paper, the committee addresses the problem of selecting registry operators for non-ASCII TLDs. Continuing with our general view that procedures for ASCII and non-ASCII TLD should be harmonized, we examine the question of whether any special policies or considerations for the selection of registry operators will be required in the context of non-ASCII TLDs. (We continue our use of the taxonomy developed in the prior discussion paper, and employ the same definitions given in it).
ICANN has two existing sets of procedures for creating new TLDs (and selecting registry operators). To understand the thinking behind these sets of procedures, it is helpful to understand the existing categories of ASCII top-level domains: country-code TLDs (ccTLDs), sponsored generic TLDs, and unsponsored generic TLDs. In the ASCII namespace, ccTLDs are designated by two-letter codes and are reserved for the use of local Internet communities as defined by the geographic units recognized on the ISO 3166-1 table. A sponsored gTLD is a specialized TLD whose sponsoring orgnanization represents the particular defined community that is most affected by the TLD. The sponsor thus carries out delegated policy-formulation responsibilities over many matters concerning the TLD. An unsponsored generic TLD operates under policies established by the global Internet community directly through the ICANN process. Examples of sponsored gTLDs are .museum, .coop, .aero, and .edu; examples of unsponsored gTLDs are .com, .net, .org, .info, and .biz. In a certain sense, ccTLDs and sponsored gTLDs are quite similar, in that each is defined by its commitment to serve the interests of a particular community -- in the case of ccTLDs, a community defined by geographic boundaries; in the case of sponsored gTLDs, a community defined by the TLD proposal and related to the TLD string itself (i.e., museums, cooperatives, the air travel industry, universities).
ICANN's procedures for the selection of ccTLD registry operators are documented in ICP-1 and RFC 1591 . The key steps in the selection of ccTLD registry operators include:
- identifying a designated "TLD manager with the requisite skills and authority to operate the TLD appropriately";
- giving serious weight to the "of the government of a country with regard to delegation of a ccTLD ";
- seeking the agreement of "significantly interested parties in the domain";
- ensuring the commitment of the proposed manager to serve the local and global Internet communities, to treat all groups equitably and fairly, to document and post all policies and procedures, etc.; and
- verifying the capability of the proposed manager to perform the operational and technical tasks associated with managing the ccTLD registry.
In sum, the selection of a registry operator for a new ccTLD revolves around technical competence, support from the local Internet community, and a willingness to accept and perform the service responsibilities of a ccTLD manager.
ICANN's second existing set of procedures for the selection of registry operators is for new ASCII generic TLDs (gTLDs). In 2000, ICANN selected an initial group of seven new gTLDs, including both unsponsored and sponsored.
The procedures from the 2000 gTLD selection process are documented at <http://www.icann.org/tlds>. Procedurally, the selection process involved an open call for proposals; the posting of application documents and criteria; the receipt and public posting of all proposals and all Q&A interactions with the staff; the posting of all public comments on individual proposals; the posting of an independent expert report and evaluation of each proposal on the basis of the technical, financial, and policy criteria; the posting of any applicant responses to the expert report; and the selection of proposals by the ICANN Board at an open, public meeting. The criteria for selection are posted at <http://www.icann.org/tlds/tld-criteria-15aug00.htm>. Information on the mechanics of the application process is posted at <http://www.icann.org/tlds/tld-application-process.htm>.
More recently, ICANN has undertaken the selection of a new registry operator for the .org gTLD registry. The proposal materials have been posted at <http://www.icann.org/tlds/org>, representing an attempt to learn some lessons from the 2000 new gTLD process, and to tailor the process to the redelegation of an existing large global registry.
In reviewing these procedures, the committee believes that they are compatible with a sensible process for selecting non-ASCII TLDs.[1] Of course, changes and adjustments will be made in future rounds of new TLD selections to reflect both lessons learned and the need for greater objectivity and regularity. But the basic elements remain perfectly valid: (1) technical competence, (2) support from the relevant community of interest, (3) a showing that the proposed sponsoring organization (if any) is appropriate in the context of the proposed TLD string and the community to be served, and (4) a commitment to meet the service and trusteeship obligations of a TLD manager. In the committee's view, proposals for non-ASCII TLDs should be required to demonstrate those elements as well.
In the following sections, we analyze several areas of particular concern for non-ASCII TLDs.
Assuming that the currently pending IDNA standard under consideration by the IETF (or some variant of it) is finalized and becomes deployable, the Internet will eventually support an application-layer translation mechanism that will allow non-ASCII characters from the Unicode repertoire to be converted into unique ASCII LDH strings fully compliant with the prevailing DNS specifications for domain names. Proposals for non-ASCII TLDs should be required to make a specific showing of competence in the area of ASCII-compatible encoding requirements, as specified by the IETF standards. Specifically, the proposal should detail the intended implementation of the IDNA standards. Technical plans should demonstrate capability relating to DNS zone file generation and publication, and registration interfaces with a view to contributing to overall Internet stability.
A commonly-heard complaint about the prospect of non-ASCII TLDs is that they will vastly increase customer service demands upon ISPs, who will be forced to deal with customers struggling to understand the mechanics of non-ASCII domain names, and/or to install and operate application-level IDNA-compliant software. Proposers should be encouraged to address their willingness and capability to educate Internet users within their intended community of interest, and to field customer service inquiries.
SUPPORT FROM THE RELEVENT COMMUNITY OF INTEREST
A key principle guiding ICANN policy for the creation of new ccTLDs and sponsored gTLDs is the notion of support from the relevant community of interest. In the case of ccTLDs, this translates to a requirement that those seeking delegation of a ccTLD registry demonstrate support from the local Internet community in the country or territory to be served. In the case of sponsored gTLDs (such as .museum, .coop, and .aero), this translates to a requirement that the proposer first define the nature and scope of the community to be served, and then demonstrate support from across its key stakeholders. ICANN policy has not required unanimous support, but rather something closer to a consensus -- a showing of strong support from across the community.
The committee believes that this principle is a useful and valid one, and should be adapted to the area of non-ASCII TLDs. In general, the committee believes, a proposal for a non-ASCII TLD should identify the TLD string, define the community it intends to serve (i.e., the Greek-speaking Internet community, or the Thai museum community), and then demonstrate strong support from that community.
In the case of non-ASCII TLDs that are semantically associated with geography units (the non-ASCII equivalent of ASCII ccTLDs), this requirement is identical to that for ASCII ccTLDs, and within the same geographic boundaries. As with ASCII ccTLDs, the committee believes that the views of the government should be given strong weight; indeed, absent an acceptable non-ASCII equivalent for the ISO 3166-1 chart, governments should be arguably be given decisive weight on the question of the exact string to to be used in connection with its territory.
For all other non-ASCII TLDs, however, there is a language element that must be addressed. The typical support requirements imposed on ASCII TLDs must be supplemented with an expectation of demonstrated support from speakers of the language(s) of the proposed string. This expectation should apply to both sponsored and unsponsored non-ASCII TLDs, though in different ways. Unsponsored non-ASCII TLD proposals should, in the committee's view, be required to demonstrate support within the community of speakers of the language(s) represented in the TLD string itself, or at least to demonstrate a clear market and need for the TLD. (For a proposed commercial, globally unrestricted non-ASCII TLD, it would be an impossible burden to require consensus support from across the community of language speakers -- that would effectively give veto power to well-organized commercial competitors). Sponsored non-ASCII TLD proposals should be expected to define the community they intend to serve, with the understanding that the scope should logically fit the semantic meaning of the TLD string itself. Thus, a TLD equivalent to the Thai word for "museum" should reasonably define Thai museums as its relevant community of interest.
Because the same characters can be used in different languages, this presents some perplexing problems. Most of these problems, however, can be addressed through the application of good judgment and a requirement of consensus-like support for the proposal. Thus, a non-ASCII TLD associated with a language should be expected to demonstrate strong support (and a lack of substantial opposition) from across the community of speakers of that language, including any relevant governments.
Floating above the foregoing conclusions is the problem of quantifying support from relevant communities of interest. The committee believes that this is a very important area for further work and consideration. In order to make the process of creating non-ASCII TLDs credible and reliable, ICANN's procedures and criteria must be as objective as possible. It is, of course, extremely difficult to specify with any precision the exact measurement of support that a new non-ASCII TLD proposal should be expected to establish, given the size and reach of the Internet's many global communities.
One way to achieve greater legitimacy in evaluating non-ASCII TLD proposals against the stated criterion of support from the relevant community of interest is to use independent experts. ICANN's current use of independent experts to assess the technical and financial aspects of new TLD proposals could be enhanced in the area of non-ASCII TLDs by chartering a team of experts (including academic, commercial, non-profit, user, and governmental representatives) to assess the extent to which non-ASCII TLD proposals have demonstrated support. Such a review mechanism would relieve the ICANN Board and staff from making judgments about, for example, language communities whose language they do not speak.
The use of independent experts may involve some trade-offs in, for example, efficiency. Compared to ICANN's permanent staff, independent expert panels typically require more time to assemble, review, and deliberate on proposals. In order to minimize efficiency losses, the committee believes that the use of language-specific or community-specific experts should be enhanced by the creation of a dedicated panel of non-specific, global experts, in order to ensure that the criteria are applied and evaluated in a uniform way across all TLD proposals. As to any given non-ASCII TLD proposal, the dedicated panel of experts would be joined by a group of language- or community-specific experts, who will ensure that the community's interests are heard and incorporated into the independent review.
As is so often the case in the ICANN universe, there is no immediately obvious answer to the question: Who should appoint the experts? Three obvious candidates are: (1) an existing international organization like the United Nations, perhaps through its UNESCO agency; (2) the ICANN Board; or (3) an independent advisory body within the ICANN structure, such as the DNSO or Governmental Advisory Committee. Though it would be optimal for ICANN to be able to delegate the entirety of this responsibility to a single outside body, the committee is not confident that any one of the foregoing would generate a broad consensus in favor. If no such single outside body can be found, the committee believes that the best answer probably involves a combination of all three.
The committee does not believe that any existing TLD registry should be given automatic rights to any non-ASCII TLD string. Rather, any existing registry that seeks to operate a non-ASCII TLD registry that is equivalent in meaning to its current TLD string should be required to make the same demonstration of support as any other non-ASCII TLD proposal. The same principle applies already in the ASCII namespace, and the committee sees no reason to treat non-ASCII TLDs differently.
One area in which the committee invites further input is the question of how proposals for coordinated ASCII/non-ASCII TLDs should be handled, particularly in the area of sponsored gTLDs. It is conceivable, for example, that the .museum registry would seek to operate essentially identical, coordinated registries consisting of non-ASCII terms for "museum" in other languages. Registrants might benefit from the ability to deal with a single registry operator to secure registrations in multiple non-ASCII character sets, affording equivalent meanings in different languages. The believes that such proposals should certainly be permitted, and invites input on the issue of whether preference should be given to existing sponsoring organizations for TLD strings of equivalent meaning in other non-ASCII characters.
In addition and further to comments made in the committee's discussion paper on Non-ASCII Top Level Domain Policy Issues the following policy issues are noted for consideration in the future:
Nothing within any future non-ASCII TLD space constrains names or labels to be in any language at all. 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.
Even if non-ASCII domain names compatible with a given language at the second level of the TLD are permitted, enforcement of a restriction at the third or fourth level or beyond is likely to prove challenging.
If a non-ASCII TLD is approved, based on representations made within any given registry proposal (regarding, for example, names used to populate it, communities to be served), then procedures for holding the registry to such representations will need to be developed.
In order to avoid an unmanageable expansion of TLDs within the DNS, consideration needs to be given to formulating rules regarding the translations 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.
These issues will be dealt with in greater detail in the committee's final report to the ICANN Board.
[1] The Committee notes that top level non-ASCII TLDs are the focus of this paper, but recognizes that significant policy issues may manifest themselves at the secondary and tertiary non-ASCII TLD levels that might require appropriate policies forthwith.
Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org .
Page Updated
14-Jun-2002
©2002 The Internet Corporation for Assigned Names and Numbers.
All rights reserved.