Skip to main content

Updates to New gTLD Program Implementation

This page is available in:

Economic Case for Auctions in New gTLDs Paper Released -- During the ICANN meeting in Paris, France, ICANN staff made a commitment to release a paper describing the economic case for auctions as a tiebreaking mechanism for resolving contention among identical or confusingly similar applications for new gTLDs. ICANN is today making the Economic Case for Auctions in New gTLDs paper available so that the community can provide feedback on this element of the forthcoming implementation plan.

The paper [PDF, 52K] was prepared by ICANN's auction design consultant PowerAuctions LLC with support from ICANN staff. The paper notes that auctions as a tiebreaking mechanism accomplish a goal of allocative efficiency through a transparent, objective and scalable process for the resolution of gTLD applications.

This paper does not address specific details on how an auction process to resolve string contention may be conducted. These details will be provided as part of the larger information on new gTLD implementation to be presented to the community in the near future.

A public forum has been established at at Comments submitted to will be considered until 7 September 2008 23:59 UTC (8 Aug 2008).

String Similarity Algorithm Update -- ICANN staff recently completed a workshop with SWORD, the partner who is assisting ICANN with the creation of an algorithm that will help automate the process for assessing similarity among proposed and existing TLD strings. SWORD's verbal search algorithms are used by various patent and trademark offices throughout the world. SWORD has completed a beta algorithm and reviewed several test cases with ICANN staff. This is being done in order to refine the parameters and discuss how the algorithm could be successfully integrated as a tool to help implement the GNSO's recommendation that new gTLD strings should not result in user confusion with existing TLDs. (8 August 2008)

Backend Registry Certification Not Available in First Round -- On 31 January 2008, ICANN posted an announcement ( to inform the community that it was exploring a potential initiative for the certification of backend registry operators for new gTLDs. ICANN staff has determined not to proceed with this initiative in the first round of the new gTLD process. The initiative was suggested as a possible means to streamline the application process for new gTLDs and to create a pool of pre-qualified registry operators who could provide assistance in the event of a registry failure. Exploration of the initiative was also prompted by inquiries from community members who expressed the potential positive aspects that creation of the certification might promote.

During the exploration of the initiative, ICANN consulted with the community including technical experts and gTLD and ccTLD registries and registry service providers. Potential operational benefits and risks of implementing the initiative were assessed. Ultimately, a decision was made to not proceed with certification as part of the initial new gTLD application round based upon a number of factors. Some of these are: additional assessment as to effects certification might have on the marketplace, e.g., whether the implementation might cause expansion or contraction; additional collaboration with the community as to the terms of such a certification; and weighing the potential post-certification activities including ongoing testing, re-certification and the introduction of new compliance activities. It was also deemed important to be able to assess the positive and negative aspects of the new gTLD implementation without possible crossover effects of this additional certification. This independence of interactions can be better assured by introducing the certification (if it is deemed appropriate after additional analysis) at a later date.

Both ccTLD and gTLD backend registry operators can still offer to provide registry services to new gTLDs. The Request for Proposals for new gTLDs, when published, will detail the minimum technical criteria and pre-delegation check requirements that must be met by every applicant prior to the approval of their TLD for insertion into the root. New gTLD applicants might choose to build their own registry infrastructure and systems, retain the services of an existing gTLD or ccTLD registry services provider, or contract with another technical services provider. (8 August 2008)

More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."