Skip to main content

Letter from Rusty Lewis to Paul Twomey

October 13, 2003

Dr. Paul Twomey
President and CEO
International Corporation for Assigned Names and Numbers (ICANN)
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292-6601

Ref. Letter to Ben Turner dated July 30, 2003 re. IDN Program Authorization

Dear Paul:

We appreciate your staff taking the time to review with us on August 25, 2003 our implementation plans regarding our IDN program. As we have stated before, we compliment ICANN in the role it played in facilitating the development of the Guidelines for the Implementation of Internationalized Domain Names (“Guidelines). We strongly believe that the process demonstrates how ICANN can make significant contributions regarding the creation of best practices in the domain name industry. The creation of these Guidelines is an important step forward in the advancement of IDNs. VeriSign’s active participation in the formation of the IDN Guidelines and the below summary of our plans for implementing the Guidelines, much of which we covered during our August 25 meeting, illustrates our active support for the Guidelines.

To help place the below information in context and to respond to questions from ICANN in the past, it is useful to understand the registrations for the current IDN program that VeriSign is offering. Of the registered names 84% are either in Chinese, Japanese or Korean, and 0.45% are either symbols or punctuations. To address the mixed use of scripts it is helpful to understand that this is rare. For example, 0.01% of registrations inappropriately combine scripts, 0.005% are Latin and Cyrillic combined registrations which are ambiguous in nature, 0% of Latin and Greek registrations appear to be ambiguous, and there are no Cherokee or Armenian registrations that are combined with Latin characters.

Guideline 1. - Top-level domain registries that implement internationalized domain name capabilities will do so in strict compliance with the technical requirements described in RFCs 3490, 3491, and 3492 (collectively, the "IDN standards"). As you know, we opened our IDN test bed in November 2000 for the primary purpose of contributing to the Internet Engineering Task Force’s (“IETF”) development of the IDN standards. Since that time, we have consistently expressed our commitment to ensure current and future compliance with evolving IDN standards developed within the IETF and adherence to the Internet Architecture Board (“IAB”) principle of a single DNS root. Since the IDN technical standards were established, we have invested considerable time and resources in bringing our IDN program into compliance with those standards, as contemplated by the .com and .net registry agreements. Accordingly, VeriSign currently has plans to deploy systems that accept registrations according to the above-mentioned RFCs and IDN guidelines. For a few months, VeriSign will permit registrars to continue to send registrations to the registry in the old format to accommodate their development schedules. However, no RACE registrations will be submitted to the SRS. VeriSign, as a service to those registrars who cannot make the migration to the new standards in September, will convert these RACE registrations to the IDN standard prior to committing a registration to the SRS. This migration window will end in the first quarter of 2004 when all registrars will be required to submit registrations in the identified RFC format.

Guideline 2. - In implementing the IDN standards, top-level domain registries will employ an "inclusion-based" approach (meaning that code points that are not explicitly permitted by the registry are prohibited) for identifying permissible code points from among the full Unicode repertoire. To date, the community has developed variant tables for three languages, Chinese, Japanese and Korean. The Japanese language table has no variant mappings, but does identify the characters for a valid Japanese registration. These characters are listed in a table such that when a registration is tagged as Japanese, all of the code points within that registration must come from that table. These code points are identified in an IETF internet-draft. Any additional languages that go this route will be treated in the same manner.

Guideline 3. In implementing the IDN standards, top-level domain registries will (a) associate each registered internationalized domain name with one language or set of languages, (b) employ language-specific registration and administration rules that are documented and publicly available, such as the reservation of all domain names with equivalent character variants in the languages associated with the registered domain name, and, (c) where the registry finds that the registration and administration rules for a given language would benefit from a character variants table, allow registrations in that language only when an appropriate table is available.

VeriSign will be associating each registration with only one language. Specifically, where: 1) the local authority has established a variant table, VeriSign will use a language tag with the corresponding variant table; 2) no variant table exists but the local authority is offering IDNs, VeriSign will use a language tag and follow the local practices; and 3) there is no variant table and the local authority is not offering IDNs, VeriSign will use a language tag only. Registrars must provide the registrant with the ability to select a specific language and the registrar must pass that tag to VeriSign. VeriSign will launch this language tag functionality on or before March 31, 2004.

Through a limited number of registrars that have elected to sell IDN registrations, VeriSign is pursuing markets where IDNs are presently being adopted. From September 27, 2003 up to the launch of full language tag capability, VeriSign will: 1) use language tags with the corresponding variant table where the local authority has established a table; 2) use no language tag but follow the local practices for those countries that offer IDNs but have no variant table; and 3) use no language tag only for those countries that do not offer IDNs and have no variant table.

We have mapping tables for those languages that have identified them. Currently we only do Chinese this way. (c) For all tables that are available and generally recognized as appropriate, VeriSign will be implementing them. VeriSign recognizes the need to work with the local communities within each country in the role out and marketing of IDNs to ensure we are addressing the appropriate local practices. As a result, our current plan is to follow the practices established by the local registries, to collaborate with local authorities to establish best practices appropriate for the relevant market, and to implement local standards where practicable. VeriSign is willing to have periodic dialog with ICANN and relevant stakeholders regarding ongoing implementation of this Guideline as well as all of the others for the purpose of improving the service to users and share lessons learned.

Guideline 4. Registries will work collaboratively with relevant and interested stakeholders to develop language-specific registration policies (including, where the registry determines appropriate, character variant tables), with the objective of achieving consistent approaches to IDN implementation for the benefit of DNS users worldwide. Registries will work collaboratively with each other to address common issues, through, for example, ad hoc groups, regional groups, and global fora, such as the ICANN IDN Registry Implementation Committee.
VeriSign has and will continue to work with the appropriate bodies. Additionally, at the suggestion of ICANN, VeriSign notified its Registrars via email communication on September 3, 2003 to alert existing Registrants of potential Unicode variations of registrations. VeriSign has offered its help in this Registrar process.

Guideline 5. In implementing the IDN standards, top-level domain registries should, at least initially, limit any given domain label (such as a second-level domain name) to the characters associated with one language or set of languages only.
VeriSign is actively working with the mapping and inclusion tables that are available. We have implemented these for Japanese. We will continue to work with the appropriate parties to implement mapping tables or inclusion tables as they are developed. VeriSign is committed to enhancing user adoption of IDNs through the reduction of user confusion in the market place. To this extent VeriSign will implement tables, which are made available by the appropriate government or regulatory body for each country. As new tables become available, legacy names will not be impact by variant table changes.

Guideline 6. Top-level domain registries (and registrars) should provide informational resources and services in all languages for which they offer internationalized domain name registrations.
VeriSign currently uses an AT&T service known as Language Line to support communications between parties who speak different languages.

Before the commercial launch of our standards compliant service, VeriSign would like to obtain, and hereby requests, ICANN’s authorization under the .com and .net Registry Agreements. See .com and .net Registry Agreements App. K, § C. In order to avoid a delay in our launch plans, we request that ICANN provide written authorization as soon as possible.

We believe that the information we’ve provided in the prior 3 submissions and this letter is sufficient to enable ICANN to grant such authorization and look forward to ICANN’s approval. If this letter is not sufficient, then please provide us as soon as possible with: (1) a written definition of any such conditions and evaluation criteria, so that we may properly consider them; and (2) a detailed explanation of how VeriSign’s planned implementation would not comply with those conditions. In addition, for each registry that has sought authorization from ICANN in connection with the implementation of an IDNA service, we request that ICANN provide in writing the criteria it is using or has used to evaluate whether to grant such authorization.

We look forward to receiving ICANN’s immediate authorization.


Russell Lewis
Executive Vice President and General Manager
VeriSign Naming and Directory Services

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."