1 What is contact information and What Taxonomies are Available

Comments on what is contact information

---

 

The following taxonomies provide definitions of terminology relating to the translation and transliteration of contact information and to registration data directory services in general.

Contact Information as Defined in the Final Issue Report on the Translation and Transliteration of Contact Information based on the definition in the Registrar Accreditation Agreement (RAA), http://gnso.icann.org/en/issues/gtlds/transliteration-contact-final-21mar13-en.pdf: 

"In the context of these issues, “contact information” is a subset of Domain Name Registration Data.  It is the information that enables someone using a Domain Name Registration Data Directory Service (such as WHOIS) to contact the domain name registration holder.  It includes the name, organization, and postal address of the registered name holder, technical contact, as well as administrative contact.  Domain Name Registration Data is accessible to the public via a Directory Service (also known as the WHOIS service). The Registrar Accreditation Agreement (RAA 3.3.1) specifies the data elements that must be provided by registrars (via Port 43 and via web-based services) in response to a query, but it does not require that data elements, such as contact information, must be translated or transliterated."

Contact Information as Defined by the Expert Working Group on gTLD Directory Services in its Status Update Report (page 11), published on 11 November 2013 at: https://community.icann.org/download/attachments/43983053/status-update-11nov13-en.pdf?version=1&modificationDate=1384213897000&api=v2.

To meet basic domain control needs, it should be mandatory for Registries and Registrars to collect and Registrants to provide the following data elements when a domain name is registered; this data would not necessarily all be sent to the RDS:

a. Domain Name

b. DNS Servers

c. Registrant Name

d. Registrant Type: Indicates the kind of entity identified by Registrant Name:  natural person, legal person, proxy service provider, trusted  agent

e. Registrant Contact ID: A unique ID assigned to each Registrant Contact [Name+Address] during validation (refer to Section IV.b., for a more detailed definition of Contact ID and how it is created and used)

f. Registrant Postal Address: Includes the following data elements: Street, City,

State/Province, Postal Code, Country (as applicable)

g. Registrant Email Address, Registrant Telephone Number: Includes the following data elements: Number, Extension (when applicable)

From the Final Report of the Internationalized Registration Data Working Group 07 May 2012 at http://gnso.icann.org/en/issues/ird/final-report-ird-wg-07may12-en.pdf:

2.2     Terminology

The term “WHOIS” in the ICANN environment could refer to various components of the WHOIS system. To avoid confusion and bring precision to the discussion, we use the following terms as proposed in SAC 051.[1]

Domain Name Registration Data (DNRD) – refers to the information that registrants provide when registering a domain name and that registrars or registries collect. Some of this information is made available to the public. For interactions between ICANN Accredited Generic Top Level Domain (gTLD) registrars and registrants, the data elements are specified in the current Registrar Accreditation Agreement (RAA). For Country Code Top Level Domains (ccTLDs), the operators of these TLDs set their own or follow their government’s policy regarding the request and display of registration information.

 Domain Name Registration Data Access Protocol (DNRD-AP) – refers to the elements of a (standard) communications exchange—queries and responses—that make access to registration data possible. For example, the WHOIS protocol (RFC 3912) and HTTP (RFC 2616 and its updates) are commonly used to provide public access to DNRD.

Domain Name Registration Data Directory Service (DNRD-DS) – refers to the service(s) offered by registries and registrars to provide access to (potentially a subset of) the DNRD. ICANN Accredited gTLD registries and registrars are required by contracts to provide the DNRD Directory Services via both port 43 and over the web interface. For ccTLDs the TLD registries (or governments) determine which service(s) they offer.

 To ensure that discussions regarding internationalized registration data take place in a consistent manner, the IRD-WG uses the following definitions of IDN-related terms. Some of these terms are from the ICANN’s IDN glossary,[2] and others are from related RFCs from the Internet Engineering Task Force (IETF) (RFC 6365[3] and RFC 5890[4]). We note that these definitions are informal ones.  Both Unicode and Internationalizing Domain Names in Applications (IDNA) require and use very precise definitions to differentiate among types of objects; these informal ones are not a substitute for those more precise ones, which are given by the referenced documents.

 ASCII: a character-encoding scheme based on the ordering of the English alphabet. When mentioned in relation to domain names or strings, ASCII refers to the fact that before internationalization, only the letters a-z, digits 0-9, and the hyphen "-" were allowed in domain names. US-ASCII is the Internet Assigned Numbers Authority (IANA) preferred character set name for ASCII.

 Internationalized domain names (IDNs): IDNs are domain names that include characters used in local scripts that are not written with the twenty-six letters of the basic Latin alphabet. 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.

 Internationalized Registration Data (IRD): Where DNRD can be represented in different languages and scripts it is referred to as Internationalized Registration Data. Where DNRD contains data other than US-ASCII (not just the capacity for it), it is referred to as Localized Registration Data.

Translation: The process of conveying the meaning of some passage of text in one language, so that it can be expressed equivalently in another language. <RFC6365>

Transliteration: The process of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet. <RFC6365>

Transcription: The process of systematically writing the sounds of some passage of spoken language, generally with the use of a technical phonetic alphabet (usually Latin-based) or other systematic transcriptional orthography.   <RFC6365>

 A-label | U-label: A domain name consists of a series of "labels" (separated by "dots"). The ASCII form of an IDN label is termed an "A-label." An A-label conforms to the Letter-Digit-Hyphen (LDH) constraint on labels as defined by the DNS standards. 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." A special form of "ASCII compatible encoding" (ACE) is applied to a U-label to produce a corresponding A-label. The transformation is symmetric: one can derive a U-label from an A-label for the purpose of displaying the domain name using characters from a local script so that a user sees a familiar script rather than a less recognizable A-label.

 Thin | Thick Registry: A thin registry only includes data sufficient to identify the sponsoring registrar, status of the registration, nameserver, creation, and expiration dates for a domain registration. Registrars maintain the complete set of registration data for those domains they sponsor. .COM and .NET are examples of thin registries. Thick registries maintain fields to store and display the registrant's contact information and designated administrative and technical information, in addition to sponsoring registrar and registration status information, with the DNRD usually provided by the sponsoring registrar..INFO and .BIZ are examples of thick registries.

From SAC051: SSAC Report on Domain Name WHOIS Terminology and Structure, 19 September 2011, http://www.icann.org/en/groups/ssac/documents/sac-051-en.pdf:

2.      Taxonomy of Terms

The term “WHOIS” is overloaded, referring to protocols, services, and data types associated with Internet naming and numbering resources, i.e., domain names, Internet Protocol (IP) addresses, and Autonomous System Numbers (ASNs). The ambiguity in terminology further burdens an already challenging set of discussions intended to resolve conflicts related to the evolution of meta-data for Internet naming and numbering.  For example, WHOIS can refer to any of the following:

1. The information that is collected at the time of registration of a domain name or IP numbering resource and subsequently made available via the WHOIS Service, and potentially updated throughout the life of the resource;
2. The WHOIS Protocol itself, which is defined in RFC 3912 [2] (which obsoletes RFCs 812 and 954); or
3. The WHOIS Services that provide public access to domain name registration information typically via applications that implement the WHOIS protocol or a web-based interface.

To support on-going efforts at improving the WHOIS framework for DNS-related data, the SSAC proposes the following terms to better distinguish the components of the WHOIS system related to domain names: 

Domain Name Registration Data (DNRD) – refers to the information that registrants provide when registering a domain name and that registrars or registries collect. Some of this information is made available to the public. For interactions between ICANN Accredited Generic Top Level Domain (gTLD) registrars and registrants, the data elements are specified in the current Registrar Accreditation Agreement [8]. For country code Top Level Domains (ccTLDs), the operators of these TLDs set their own or follow their government’s policy regarding the request and display of registration information. for all domain namesion data”nd here for anyone to make sense of the new terminology.

Domain Name Registration Data Access Protocol (DNRD-AP) – refers to the elements of a (standard) communications exchange—queries and responses—that make access to registration data possible. For example, the WHOIS protocol (RFC 3912) and Hypertext Transfer Protocol (HTTP) (RFC 2616 and its updates) are commonly used to provide public access to DNRD. for all domain namesion data”nd here for anyone to make sense of the new terminology.

Domain Name Registration Data Directory Service (DNRD-DS) – refers to the service(s) offered by registries and registrars to provide access to (potentially a subset of) the DNRD. ICANN Accredited gTLD registries and registrars are required by contracts to provide the DNRD Directory Services via both port 43 and over the web interface [8,9]. For ccTLDs, the TLD registries determine which service(s) they offer.

Using these terms defined above, we offer the following additional terminology, some already commonly used: 

• Domain Name Registration Data (DNRD) is composed of different elements. We refer to them as Domain Name Registration Data Elements (DNRDe).

• Where DNRD can be represented in different languages and scripts, it is referred to as Internationalized DNRD. 

• Where DNRD contains data other than US-American Standard Code for Information Interchange (US-ASCII) (not just the capacity for it), it is referred to as Localized DNRD. 

• DNRD refers to the entire data collected from the registrant, but potentially only a subset of this data is made available through the Domain Name Registration Data Directory Service (DNRD-DS). This subset of DNRD is referred to as DNRD-DS Data (DNRD-DSD).

• Policies that apply to the domain name WHOIS service could be related to the WHOIS data itself (DNRD Policy) or to the directory service (DNRD-DS Policy). Policies related to DRND would include 1) data to be included in the DNRD-DS output, 2) annual WHOIS data reminder policy, and 3) policy that requires Registrars to investigate reports of inaccuracy. Policies applicable to the DNRD-DS (DNRD-DS Policy) might include: 1) acceptable terms of use, 2) service levels (e.g., availability, update frequency, response time), 3) query rate limits, 4) data formats, 5) search capabilities, and 6) pricing models for different service levels.

In the remainder of this report the SSAC will use the terminology proposed above, and use the term WHOIS to refer only to the WHOIS protocol as defined by RFC 3912.

From SAC058: SSAC report on Domain Name Registration Data, 27 March 2013, http://www.icann.org/en/groups/ssac/documents/sac-058-en.pdf

3. Taxonomy of Validation
Verification, validation and resolution have been used interchangeably in various literature on this topic. We choose “validation” to refer to the assessment of data as described by this document. Verification in this document refers to the process of validating. Resolution has an entirely different technical meaning that is out of scope for this document. The SSAC asserts there are three types of validation for elements of the registration data.

1. Syntactic Validation refers to the assessment of data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use. For example, if the data element is expected to be an email address is it formatted as an email address? In general, it is expected that syntactic validation checks would be entirely automated and could be executed inline with a registration process, follow up information reviews, and whenever registration data changes.

2. Operational Validation refers to the assessment of data for their intended use in their routine functions. Examples of operational validation include 1) checking that an email address or phone number can receive email or phone calls; 2) checking that a postal address can receive postal mail; 3) checking that the data entered are self-consistent, i.e. that all data are logically consistent with all other data. It is expected that many operational validation checks would be automated and some could be executed inline with a registration process.

3. Identity validation refers to the assessment that the data corresponds to the real world identity of the entity. It involves checking that a data item correctly represents the real world identity for the registrant. In general, identity validation checks are expected to require some manual intervention.

The United Nation Group of Experts on Geographic Names (UNGEGN) suggests the following relevant terminology: 

Exonym is the name used in a specific language for a geographical feature situated outside the area where that language has official status, and differing in its form from the name used in the official language or languages of the area where the geographical feature is situated. Examples: Warsaw is the English exonym for Warszawa; Londres is French for London; Mailand is German for Milano. The officially romanized endonym Moskva for Москва is not an exonym, nor is the Pinyin form Beijing, while Peking is an exonym. 

Endonym is the name of a geographical feature in one of the languages occurring in that area where the feature is situated. Examples: Vārānasī (not Benares); Aachen (not Aix-la-Chapelle); Krung Thep (not Bangkok); al-Uqşur (not Luxor); Teverya (not Tiberias).