A RESTful Web Service for Domain Name Registration Data (RWS-DNRD)
draft-sheng-weirds-icann-rws-dnrd-01

Abstract

This document specifies a RESTful Web Service for querying Domain Name Registration Data (WHOIS data).

The purpose of this document is to facilitate discussion and serve as input into a standards process in this area, currently being discussed on the Worthwhile Extensible Internet Registry Data Service (WEIRDS) mailing list (https://www.ietf.org/mailman/listinfo/weirds).

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 31, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Domain Name Registration Data
• 1.2. REST and RESTful Web Service
• 2. Terminology
• 3. The Request
• 3.1. Domain
• 3.2. Contacts
• 3.3. Hosts
• 3.4. Registrars
• 3.5. Signaling Response Formats
• 4. The Response
• 4.1. Domain Names
• 4.2. Contacts
• 4.3. Host Names
• 4.4. Registrars
• 5. Error Codes
• 6. Formal XML Syntax
• 6.1. Contact XML Schema
• 6.2. Domain Name XML Schema
• 6.3. Host XML Schema
• 6.4. Registrar XML Schema
• 6.5. RWS XML Schema
• 7. Internationalization Considerations
• 7.1. Considerations for Querying IDNs
• 7.2. Considerations for Display of Internationalized Registration Data
• 7.3. Considerations for Indicating Language/scripts in Responses
• 8. IANA Considerations
• 9. Security Considerations
• 9.1. URIs and IRIs
• 10. Acknowledgments
• 11. Change History
• 11.1. Changes from version 00 to 01
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Authors' Addresses

1. Introduction

This document describes a way for querying domain name registration data through a RESTful Web-based Interface. This draft closely follows the query patterns set by the Internet Draft on RESTful WHOIS proposed by some Regional Internet Registries ([I-D.newton-et-al-weirds-rir-query]).

1.1. Domain Name Registration Data

Domain Name Registration Data is the information that a registrant provides when s/he acquires or is assigned a domain name. Many domain registries and registrars ([RFC3707]) provide public access to some of these data via the WHOIS protocol ([RFC3912]) or a web interface. For example, 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 these data. The Domain Name Registration Data defined here is intended to satisfy such public access services.

1.2. REST and RESTful Web Service

REST stands for Representational State Transfer. It is a set of architectural constraints that is developed as an abstract model of the Web architecture. These constraints include: client-server model, stateless, cacheable, layered system, code on demand (optional), and uniform interface. REST was used to guide the redesign of the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI). It is widely regarded as the architecture of the Web today. Principles of REST have been used to design other protocols such as the ATOM publishing protocol.

A RESTful web service is a web service implemented using HTTP and the principles of REST. It is a collection of resources, with three defined aspects: 1) The "verbs" of the service are strictly those defined by the HTTP methods HEAD, GET, PUT, POST, and DELETE, 2) The "verbs" are used to act upon resources, and 3) resources are addressable using URLs

Whois services, in general, are read-only services. Therefore URL patterns [RFC3986] presented here are only applicable to the HTTP [RFC2616] GET and HEAD methods.

2. Terminology

For convenience, this implementation can be referred to as the "RESTful Web Service for Domain Name Registration Data" or "RWS - DNRD". The following terminology is used by this specification:

• Domain Name Registration Data (DNRD) - the information that registrants provide when registering a domain name and that registrars or registries supplement with registry or registrar specific information.
• URI - A Uniform Resource Identifier as defined in [RFC3986].
• IRI - An internationalized Resource Identifier as defined in [RFC3987].
• Resource - A network-accessible data object or service identified by an URI, as defined in [RFC2616]. In this context, resources refers to the registration data objects.
• Representation - An entity included with a request or response as defined in [RFC2616].

Additionally, we use ".tld" as a convention in this document to represent, generically, any top level domain (TLD) in the Domain Name System (DNS).

3. The Request

As its name implies RWS-DNRD is Web-based, i.e., uses HTTP [RFC2616] as its transport. Given its RESTful nature it only uses the standard HTTP methods. And given it is read-only, it only uses the GET and HEAD methods.

The server accepts standard HTTP "GET" requests for the resources it serves. The client sends its request with the following URI structure. The URI structure start with a base URL specified by each domain registry or any other service provider offering this service. The base URL will be appended with resource type specific path segments. The base URL may contain its own path segments (e.g. http://whois.tld/... or http://whois.tld/restful-whois/...).

The resource type path segments are:

• 'domain' - information about the domain including registration information, contact information, host information and possible other details specified by registries' Whois policy.
• 'contact'- Contact record for a particular entity. This includes contact name, organization, address, phone, email, etc.
• 'host' - information about an Internet Host. This includes server name, ipv4 or ipv6 address, sponsoring registrar, etc.
• 'registrar' - information about an registrar, specifically the sponsoring registrar. This includes registrar name, address, contact information, etc.

3.1. Domain

Queries for information about domain names are of the form /domain/example.tld/... where the path segment following 'domain' is an domain name, in this case example.tld. Path segments following the domain name can target specific information associated with the domain name in the following way:

• 'registration' - for the registration data associated with the domain name including references to contacts and registrar, but not the actual contact information.
• 'contacts' - contact information for the domain.
• 'registrar' - contact information of the sponsoring registrar of the domain name.

Optionally, specific type of contact information may be further targeted by following that path segment with a type. What types of contacts a registry supports is for each registry policy to define. Examples of types of contacts typically supported are:

• registrant - contact information for the registrant
• admin - administrative contact information
• tech - technical contact information
• billing - billing contact information

Finally, when no path segment follows the domain name, the semantics of the query are that both registration, contact, and registrar information are to be returned.

Here are some example queries:

base URL: http://whois.tld/somepath

• /domain/example.tld/ - returns all of example.tld's information. This includes registration, contact, host, and sponsoring registrar information.
• /domain/example.tld/registration - query for example.tld's registration information. It will return the registration record with references to the contacts, registrar, name servers, and hosts. But it would not return the actual information for those data objects.
• /domain/example.tld/contacts - returns all the contact information fordomain example.tld.
• /domain/example.tld/contacts/registrant - returns only the registrant information for domain example.tld.
• /domain/example.tld/contacts/tech - returns only the technical contact's information for domain example.tld.
• /domain/example.tld/registrar - returns the sponsoring registrar's contact information for domain example.tld.

3.2. Contacts

Queries for information about contacts are of the form /contact/contact-id/... where the contact-id is the id that the registry or registrar, as the case may be, uses to uniquely identify the contact. Path segments following the domain name can target specific information associated with the domain name in the following way:

Here are some example queries:

Base URL: http://whois.tld/somepath

• /contact/CNT-2222/ - queries the registrar or registry for contact id CNT-2222.

3.3. Hosts

Queries for information about hosts (or nameservers) are of the form /host/XXX/... where the path segment following 'host' is either a hostname [RFC1123], IPv4 [RFC0791] or IPv6 [RFC5952] address of the hostname.

Here are some example queries:

base URL: http://whois.tld/somepath

• /host/192.0.2.0/ - queries for host name with IPv4 address.
• /host/ns.example.tld/ - queries for host name ns.example.tld.

3.4. Registrars

Queries for information about registrars are of the form /registrar/XXX/... where the path segment following 'registrar' SHOULD be the the full name of the registrar (including punctuation, "Inc.", etc.) or its assigned ID.

Here are some example queries:

base URL: http://whois.tld/somepath

• /registrar/"Network Solutions, LLC"/ - query the registrar names "Network Solutions. LLC"
• /registrar/123/ - queries the registrar whose ID is 123.

3.5. Signaling Response Formats

The default response format for the RWS-RDNRD server is XML. However, additional formats such as JSON, HTML or plain text can be provided. The client signals the preferred format using the standard HTTP "Accept:" header. For example, if the client wishes to receive JSON [RFC4627] response, it SHOULD put the "application/json" MIME type in the Accept header. Servers SHOULD respond with JSON responses when this MIME type is present in the Accept header in accordance with the preference rules for the Accept header in HTTP [RFC2616]. However the use of multiple MIME types in the Accept header is not supported.

Possible response formats and their signaling methods include:

• XML (default) - application/xml
• JSON - application/json
• HTML - text/html
• plain text - text/plain

4. The Response

The root element for a RWS-DNRD response is <rws>. This element contains one <result> element, and one <addtional> element, that are explained in the following section.

Example of root element object:

<?xml version="1.0" encoding="UTF-8"?>
<rws:rws xmlns:rws="urn:ietf:params:xml:ns:rws-1.0"
    ...
    <rws:result>
    ...
    </rws:result>
    <rws:additional>
    ...
    </rws:additional>
    ...
</rws:rws>
                

4.1. Domain Names

Example Query: http://whois.test/domain/example.test/

Response:

                        
<?xml version="1.0" encoding="UTF-8"?>
<rws xmlns="urn:ietf:params:xml:ns:rws-1.0">
    <result>
        <domain:object 
            xmlns:domain="urn:ietf:params:xml:ns:rwsDomain-1.0" 
            href="/domain/example.test">
            <domain:name>example.test</domain:name>
            <domain:roid>9690-TEST</domain:roid>
            <domain:status s="clientHold"/>
            <domain:status s="clientRenewProhibited"/>
            <domain:status s="clientUpdateProhibited"/>
            <domain:registrant href="/contact/jd4447">
                jd4447
            </domain:registrant>
            <domain:contact type="admin" href="/contact/jd4447">
                jd4447
            </domain:contact>
            <domain:contact type="tech" href="/contact/jd4447">
                jd4447
            </domain:contact>
            <domain:ns>
                <domain:hostObj href="/host/ns1.example.test">
                    ns1.example.test
                </domain:hostObj>
                <domain:hostObj href="/host/ns2.example.test">
                    ns2.example.test
                </domain:hostObj>
                <domain:hostObj href="/host/ns3.example.test">
                    ns3.example.test
                </domain:hostObj>
            </domain:ns>
            <domain:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </domain:registrar>
            <domain:registrar type="created" href="/registrar/reg-1289">
                reg-1289
            </domain:registrar>
            <domain:crDate>1992-07-26T09:10:56Z</domain:crDate>
            <domain:exDate>2019-01-21T10:11:18Z</domain:exDate>
        </domain:object>
    </result>
    <additional>
        <contact:object 
            xmlns:contact="urn:ietf:params:xml:ns:rwsContact-1.0"
            href="/contact/jd4447">
            <contact:id>jd4447</contact:id>
            <contact:status s="clientDeleteProhibited"/>
            <contact:postalInfo type="int">
                <contact:name>John Doe</contact:name>
                <contact:org>Example Inc.</contact:org>
                <contact:addr>
                    <contact:street>123 Example Dr.</contact:street>
                    <contact:street>Suite 100</contact:street>
                    <contact:city>Redwood City</contact:city>
                    <contact:sp>CA</contact:sp>
                    <contact:pc>94063</contact:pc>
                    <contact:cc>US</contact:cc>
                </contact:addr>
            </contact:postalInfo>
            <contact:voice x="1234">+1.7035555555</contact:voice>
            <contact:fax>+1.7035555556</contact:fax>
            <contact:email>jdoe@example.com</contact:email>
            <contact:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </contact:registrar>
            <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
            <contact:upID>ClientX</contact:upID>
            <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        </contact:object>
        <host:object xmlns:host="urn:ietf:params:xml:ns:rwsHost-1.0"
            href="/host/ns1.example.test">
            <host:name>ns1.example.test</host:name>
            <host:status s="clientUpdateProhibited"/>
            <host:addr ip="v4">192.168.12.13</host:addr>
            <host:addr ip="v4">192.14.15.16</host:addr>
            <host:addr ip="v6">2001::A:B:C:1</host:addr>
            <host:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </host:registrar>
        </host:object>
        <host:object xmlns:host="urn:ietf:params:xml:ns:rwsHost-1.0"
            href="/host/ns2.example.test">
            <host:name>ns2.example.test</host:name>
            <host:status s="clientUpdateProhibited"/>
            <host:addr ip="v4">172.16.10</host:addr>
            <host:addr ip="v4">172.17.12</host:addr>
            <host:addr ip="v6">2001::B:C:D:1</host:addr>
            <host:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </host:registrar>
        </host:object>
        <host:object xmlns:host="urn:ietf:params:xml:ns:rwsHost-1.0"
            href="/host/ns3.example.test">
            <host:name>ns3.example.test</host:name>
            <host:status s="clientUpdateProhibited"/>
            <host:addr ip="v4">10.1.2.3</host:addr>
            <host:addr ip="v4">10.4.5.6</host:addr>
            <host:addr ip="v6">2001::C:D:E:1</host:addr>
            <host:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </host:registrar>
        </host:object>
        <registrar:object 
            xmlns:registrar="urn:ietf:params:xml:ns:rwsRegistrar-1.0" 
            href="/registrar/reg-793">
            <registrar:id>reg-793</registrar:id>
            <registrar:name>Example Registrar Inc.</registrar:name>
        </registrar:object>
        <registrar:object 
            xmlns:registrar="urn:ietf:params:xml:ns:rwsRegistrar-1.0"
            href="/registrar/reg-1289">
            <registrar:id>reg-1289</registrar:id>
            <registrar:name>XYZ Corporation</registrar:name>
        </registrar:object>
    </additional>
</rws>

                    

Example Query: http://whois.test/domain/example.test/registration/

Response:

                        
<?xml version="1.0" encoding="UTF-8"?>
<rws xmlns="urn:ietf:params:xml:ns:rws-1.0">
    <result>
        <domain:object 
            xmlns:domain="urn:ietf:params:xml:ns:rwsDomain-1.0" 
            href="/domain/example.test">
            <domain:name>example.test</domain:name>
            <domain:roid>9690-TEST</domain:roid>
            <domain:status s="clientHold"/>
            <domain:status s="clientRenewProhibited"/>
            <domain:status s="clientUpdateProhibited"/>
            <domain:registrant href="/contact/jd4447">
                jd4447
            </domain:registrant>
            <domain:contact type="admin" href="/contact/jd4447">
                jd4447
            </domain:contact>
            <domain:contact type="tech" href="/contact/jd4447">
                jd4447
            </domain:contact>
            <domain:ns>
                <domain:hostObj href="/host/ns1.example.test">
                    ns1.example.test
                </domain:hostObj>
                <domain:hostObj href="/host/ns2.example.test">
                    ns2.example.test
                </domain:hostObj>
                <domain:hostObj href="/host/ns3.example.test">
                    ns3.example.test
                </domain:hostObj>
            </domain:ns>
            <domain:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </domain:registrar>
            <domain:registrar type="created" href="/registrar/reg-1289">
                reg-1289
            </domain:registrar>
            <domain:crDate>1992-07-26T09:10:56Z</domain:crDate>
            <domain:exDate>2019-01-21T10:11:18Z</domain:exDate>
        </domain:object>
    </result>
</rws>

                    

Example Query: http://whois.test/domain/example.test/contacts/

Response:

TBD.

Example Query: http://whois.test/domain/example.test/contacts/registrant/

Response:

TBD.

Example Query: http://whois.test/domain/example.test/registrar/

Response:

TBD.

4.2. Contacts

Example Query: http://whois.test/contact/jd4447/

Response:

                        
<?xml version="1.0" encoding="UTF-8"?>
<rws xmlns="urn:ietf:params:xml:ns:rws-1.0">
    <result>
        <contact:object 
            xmlns:contact="urn:ietf:params:xml:ns:rwsContact-1.0"
            href="/contact/jd4447">
            <contact:id>jd4447</contact:id>
            <contact:status s="clientDeleteProhibited"/>
            <contact:postalInfo type="int">
                <contact:name>John Doe</contact:name>
                <contact:org>Example Inc.</contact:org>
                <contact:addr>
                    <contact:street>123 Example Dr.</contact:street>
                    <contact:street>Suite 100</contact:street>
                    <contact:city>Redwood City</contact:city>
                    <contact:sp>CA</contact:sp>
                    <contact:pc>94063</contact:pc>
                    <contact:cc>US</contact:cc>
                </contact:addr>
            </contact:postalInfo>
            <contact:voice x="1234">+1.7035555555</contact:voice>
            <contact:fax>+1.7035555556</contact:fax>
            <contact:email>jdoe@example.com</contact:email>
            <contact:registrar href="/registrar/reg-793">
                reg-793
            </contact:registrar>
            <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
            <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        </contact:object>
    </result>
    <additional> 
        <registrar:object 
            xmlns:registrar="urn:ietf:params:xml:ns:rwsRegistrar-1.0" 
            href="/registrar/reg-793">
            <registrar:id>reg-793</registrar:id>
            <registrar:name>Example Registrar Inc.</registrar:name>
        </registrar:object>
    </additional>
</rws>
                     
                    

Example Query: http://whois.test/contact/jd4447/registration/

Response:

                        
<?xml version="1.0" encoding="UTF-8"?>
<rws xmlns="urn:ietf:params:xml:ns:rws-1.0">
    <result>
        <contact:object 
            xmlns:contact="urn:ietf:params:xml:ns:rwsContact-1.0"
            href="/contact/jd4447">
            <contact:id>jd4447</contact:id>
            <contact:status s="clientDeleteProhibited"/>
            <contact:postalInfo type="int">
                <contact:name>John Doe</contact:name>
                <contact:org>Example Inc.</contact:org>
                <contact:addr>
                    <contact:street>123 Example Dr.</contact:street>
                    <contact:street>Suite 100</contact:street>
                    <contact:city>Redwood City</contact:city>
                    <contact:sp>CA</contact:sp>
                    <contact:pc>94063</contact:pc>
                    <contact:cc>US</contact:cc>
                </contact:addr>
            </contact:postalInfo>
            <contact:voice x="1234">+1.7035555555</contact:voice>
            <contact:fax>+1.7035555556</contact:fax>
            <contact:email>jdoe@example.com</contact:email>
            <contact:registrar href="/registrar/reg-793">
                reg-793
            </contact:registrar>
            <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
            <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        </contact:object>
    </result>
</rws>
                     
                    

Example Query: http://whois.test/contact/jd4447/registrar/

Response:

TBD.

4.3. Host Names

Example Query: http://whois.test/host/ns1.example.test/

Response:

                        
<?xml version="1.0" encoding="UTF-8"?>
<rws xmlns="urn:ietf:params:xml:ns:rws-1.0">
    <result>
        <host:object xmlns:host="urn:ietf:params:xml:ns:rwsHost-1.0"
            href="/host/ns1.example.test">
            <host:name>ns1.example.test</host:name>
            <host:status s="clientUpdateProhibited"/>
            <host:addr ip="v4">192.168.12.13</host:addr>
            <host:addr ip="v4">192.14.15.16</host:addr>
            <host:addr ip="v6">2001::A:B:C:1</host:addr>
            <host:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </host:registrar>
        </host:object>
    </result>
    <additional>
        <registrar:object 
            xmlns:registrar="urn:ietf:params:xml:ns:rwsRegistrar-1.0" 
            href="/registrar/reg-793">
            <registrar:id>reg-793</registrar:id>
            <registrar:name>Example Registrar Inc.</registrar:name>
        </registrar:object>
    </additional>
</rws>
                     
                    

Example Query: http://whois.test/host/ns1.example.test/registration/

Response:

                        
<?xml version="1.0" encoding="UTF-8"?>
<rws xmlns="urn:ietf:params:xml:ns:rws-1.0">
    <result>
        <host:object xmlns:host="urn:ietf:params:xml:ns:rwsHost-1.0"
            href="/host/ns1.example.test">
            <host:name>ns1.example.test</host:name>
            <host:status s="clientUpdateProhibited"/>
            <host:addr ip="v4">192.168.12.13</host:addr>
            <host:addr ip="v4">192.14.15.16</host:addr>
            <host:addr ip="v6">2001::A:B:C:1</host:addr>
            <host:registrar type="sponsor" href="/registrar/reg-793">
                reg-793
            </host:registrar>
        </host:object>
    </result>
</rws>
                     
                    

Example Query: http://whois.test/host/ns1.example.test/registrar/

Response:

TBD.

4.4. Registrars

TBD

5. Error Codes

In compliance with the REST paradigm any error information is returned in the form of a standard HTTP response with an HTTP status code describing the error and a text/plain body message describing the exception causing the error response. In this version we are using only standard HTTP codes (http://www.iana.org/assignments/http-status-codes).

[[ Define specialized error codes. ]]

6. Formal XML Syntax

The formal syntax presented here is a complete schema representation suitable for automated validation of an XML instance. It is based on the object schemas from the Extension Provisioning Protocol (EPP), by Scott Hollenbeck. It references and includes the following EPP schemas:

• [RFC5730] - Extensible Provisioning Protocol (EPP)
• [RFC5731] - Extensible Provisioning Protocol (EPP) Domain Name Mapping
• [RFC5732] - Extensible Provisioning Protocol (EPP) Host Mapping
• [RFC5733] - Extensible Provisioning Protocol (EPP) Contact Mapping

To represent objects, the <result> section will contain exactly one <object> element, under a specific namespace that describes the object type. The object element will also contain an "href" property which can be used to verify it against the query.

Objects in the result element can refer to other objects, i.e.: a domain object with multiple host object associations, contacts, etc. In order for the client to obtain all the information needed about the queried object, additional objects can be described within the <additional> section. Only objects referenced in the <object> element from the <result> section are allowed in the <additional> section.

Server implementations can opt not to return the full object, but instead define an empty <object> element with an appropriate "href" property. This enables the client to retrieve the additional objects from the server if needed.

6.1. Contact XML Schema

TBD

6.2. Domain Name XML Schema

TBD

6.3. Host XML Schema

TBD

6.4. Registrar XML Schema

TBD

6.5. RWS XML Schema

TBD

7. Internationalization Considerations

7.1. Considerations for Querying IDNs

Three possibilities exist on how to query IDNs:

• U-label only - in this case an U-label is entered as part of the query. For example: /domain/"U+82F1""U+96C4".test
• A-label only - in this case the U-label is first converted to its corresponding A-label before submitted to the server. In the example above, the U-label would be /domain/xn--dj1az91b.test before it is submitted to the RWS-DNRD.
• IRI -> URI conversion - in this case the IRI (which contains the U-label) is converted to URI according to [[RFC3987]] before submitted to the server. In the example above, the query becomes /domain/%E8%8B%B1%E9%9B%84.test

7.2. Considerations for Display of Internationalized Registration Data

Information published in RWS-DNRD is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though use of UTF-8 is preferred, XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration.

7.3. Considerations for Indicating Language/scripts in Responses

The RWS-DNRD proposed by this document supports internationalized registration data, responses of a RWS-DNRD server may contain data in any languages/scripts. Although the internationalized registration data of a RWS-DNRD response can be correctly displayed, users will still be confused when reading the data in a language which t hey are not familiar. So if the response of the RWS-DNRD need to contain information to indicate the language/scripts the responses is in. This is also one of the recommendations / requirements from the ICANN Internationalized Registration Data Working Group Final Report [IRD-WG].

In order to meet the above requirement, one additional data element needs to be added to allow for the association of the IRD response to a language/script identifier. The identifiers SHALL be structured as documented in [RFC5646].

<?xml version="1.0" encoding="UTF-8"?>
<rws:rws xmlns:rws="urn:ietf:params:xml:ns:rws-1.0"
    <rws:language>
    zh
    </rws:language>
    <rws:result>
    ...
    </rws:result>
</rws:rws>
                    

For example,

The above solution can only support one language within one response. If multiple languages need to be supported by one response, one additional attribute of data element might be considered to be added to allow for association of the value of a data element to an internationalized language identifier.

Further discussions is needed on this topic.

8. IANA Considerations

TBD

9. Security Considerations

TBD

9.1. URIs and IRIs

RWS-DNRD implementations use URIs and IRIs. See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use.

10. Acknowledgments

Parts of this document are based on EPP [RFC5730] and related RFCs by Scott Hollenbeck.

The authors would like to acknowledge the following individuals for their input: Andy Newton, Andrew Sullivan, Dave Piscitello and James Galvin.

11. Change History

11.1. Changes from version 00 to 01

1. Added two co-authors.
2. Modified the query structure to resemble RIR query structures
3. Added considerations for the query of Internationalized Domain Names (IDNs)
4. Added considerations for the display of Internationalized Registration Data.
5. Updated the data schema.
6. Fixed some typographical errors and omissions.

12. References

12.1. Normative References

12.2. Informative References

Authors' Addresses