Content Comparison

Generally speaking, responses today are commonly unstructured USASCII7 or unstructured UTF-8 for gTLD registry and registrars. Some ccTLDs respond using a Latin-1 format, rather than answering in UTF-8, and many more have no regard to charsets. Lack of standard format or data structure for responses makes it difficult for humans to interpret the result and also for programs to parse the results.

Currently, most structured data formats are based on XML format. Therefore, SSAC, along with others, have proposed that the community define an XML or similar formal, extensible data structure and schema. The structured data would contain and uniquely identify the data elements that must be returned in a manner that assures that there is no ambiguity across elements, and that the data elements are syntactically and semantically correct.

Today, there is considerable variability across various DNRD-DS in data labels, representation, and data format. For example:

1. Data labels: Currently there is no consistent labeling system for identifying particular DNRDe's across directory services offered by different entities.

2. Representation format: Representation format differs from service to service. For gTLD registries, most use a <label>: <data> format [9]; however, most registrars do not use similar representation formats.2 Note that ICANN has proposed a data format for the new gTLD registries and registrars to escrow their DNRD [1].

3. Data format: Currently there is no common format for many of the DNRDe.

For example, a data element can be presented in any of the following ways by Various Domain Name Registration Data Directory Services: 04-May-2008 00:00:00

UTC, 04-May-08, 2008-05-04, or Sun, May 4, 2008. Similarly, a telephone or fax number can be presented as (123) 456-7890, +1.1234567890, 123-456-7890, or +1 123

4567890.

The SSAC thinks that the above variability should be addressed through the specification and implementation of a standards-based, structured, and extensible data model. Such a model would also improve the end user experience when it comes to both internationalized and noninternationalized DNRD. For example:

A standard data model with consistent data labels would enable end user applications to better localize the output.

A structured data model that includes additional meta-information (e.g., language, script, etc.) would provide relevant information for translation and/or transliteration tools for Localized DNRD.

An extensible data model would provide flexibility for registries/registrars who may wish to provide the information in more than one language or script.