Skip to main content
Resources

Translation and Transliteration of Contact Information

Implementation Project Status

Updated 1 June 2020

Translation and Transliteration of Contact Information Implementation Project Status: Plan
  • Due to complexities emerging from the Implementation Review Team's (IRT's) discussions and work in other areas related to registration data directory services (RDDS)—in particular the Temporary Specification for gTLD Registration Data Expedited Policy Development Process (EPDP)—the implementation's projected announcement and effective dates are to be determined (TBD).
  • The Translation and Transliteration of Contact Information Working Group's policy recommendations have been slated for analysis as part of addressing Recommendation 27 from the EPDP Team's Phase 1 Final Report.
  • ICANN org has prepared a draft policy document that has been reviewed by the IRT, which is based on input received from the IRT during the course of the implementation.

Timeframe

  • IRT Kickoff: 19 July 2016
  • Board Approval: September 2015
  • [Projected] Announcement of Implementation: TBD
  • [Projected] Effective Date: TBD

Summary

This implementation project is addressing GNSO recommendations presented in the final report [PDF, 984 KB] on the Translation and Transliteration of Contact Information Policy Development Process (PDP). The goal of the PDP was to determine how to best facilitate the entry of contact information into domain name registration data and directory services by non-English speakers and users of non-ASCII scripts.

The recommendations from the final report are as follows:

  1. It is not desirable to make transformation of contact information mandatory. Any parties requiring transformation are free to do so on an ad hoc basis outside WHOIS or any replacement system, such as the Registration Data Access Protocol (RDAP). If not undertaken voluntarily by registrar/registry (see Recommendation #5), the burden of transformation lies with the requesting party.
  2. Whilst noting that a WHOIS replacement system should be capable of receiving input in the form of non-ASCII script contact information, its data fields should be stored and displayed in a way that allows for easy identification of what the different data entries represent and what language(s)/script(s) have been used by the registered name holder.
  3. The language(s) and script(s) supported for registrants to submit their contact information data may be chosen in accordance with gTLD-provider business models.
  4. Regardless of the language(s)/script(s) used, it is assured that the data fields are consistent to standards in the Registrar Accreditation Agreement (RAA), relevant Consensus Policy, Additional WHOIS Information Policy (AWIP) and any other applicable polices. Entered contact information data are validated, in accordance with the aforementioned Policies and Agreements and the language/script used must be easily identifiable.
  5. If the transformation of contact information is performed, and if the WHOIS replacement system is capable of displaying more than one data set per registered name holder entry, these data should be presented as: additional fields (in addition to the authoritative local script fields provided by the registrant) and that these fields be marked as transformed and their source(s) indicated.
  6. Any WHOIS replacement system, for example RDAP, should remain flexible so that contact information in new scripts/languages can be added and expand its linguistic/script capacity for receiving, storing and displaying contact information data.
  7. These recommendations should be coordinated with other WHOIS modifications where necessary and are implemented and/or applied as soon as a WHOIS replacement system that can receive, store and display non-ASCII characters, becomes operational.

Resources

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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""icann.org"" is not an IDN."