Internet DRAFT - draft-kong-dnrd-ap-response-json
draft-kong-dnrd-ap-response-json
Internet Engineering Task Force N. Kong
Internet-Draft L. Zhou
Intended status: Standards Track J. Xie
Expires: December 5, 2012 S. Shen
CNNIC
June 3, 2012
Domain Name Registration Data Access Protocol Response Format defined in
JSON
draft-kong-dnrd-ap-response-json-00
Abstract
This document describes a response format for registration data
(Whois data) through RESTful Web-based Service. This response format
is defined in JavaScript Object Notation (JSON).
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 December 5, 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
Kong, et al. Expires December 5, 2012 [Page 1]
Internet-Draft DNRD JSON Response Format June 2012
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Convention Used in This Document . . . . . . . . . . . . . . . 3
2.1. Abbreviations and Terminology . . . . . . . . . . . . . . 3
3. Response Format Specification . . . . . . . . . . . . . . . . 4
3.1. Domain Name Response Specification . . . . . . . . . . . . 4
3.1.1. Objects in the Domain Name Response . . . . . . . . . 5
3.1.2. Extension Interface . . . . . . . . . . . . . . . . . 7
3.1.3. JSON Format . . . . . . . . . . . . . . . . . . . . . 7
3.2. Nameserver Response Specification . . . . . . . . . . . . 9
3.2.1. Objects in the Nameserver Response . . . . . . . . . . 9
3.2.2. Extension Interface . . . . . . . . . . . . . . . . . 10
3.2.3. JSON Format . . . . . . . . . . . . . . . . . . . . . 10
3.3. Contact Response Specification . . . . . . . . . . . . . . 11
3.3.1. Objects in the Contact Response . . . . . . . . . . . 12
3.3.2. Extension Interface . . . . . . . . . . . . . . . . . 13
3.3.3. JSON Format . . . . . . . . . . . . . . . . . . . . . 13
3.4. Registrar Response Specification . . . . . . . . . . . . . 14
3.4.1. Objects in the Registrar Response . . . . . . . . . . 15
3.4.2. Extension Interface . . . . . . . . . . . . . . . . . 16
3.4.3. JSON Format . . . . . . . . . . . . . . . . . . . . . 17
4. Accept Header . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . . 19
5.1. Encoding Specification . . . . . . . . . . . . . . . . . . 19
5.2. IDN Variants . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Kong, et al. Expires December 5, 2012 [Page 2]
Internet-Draft DNRD JSON Response Format June 2012
1. Introduction
Internet registries for both number resources and names have
historically maintained a lookup service to permit public access to
some portion of the registry database. Most registries offer the
service via the WHOIS protocol [RFC3912], with additional services
being offered via world wide web pages, bulk downloads, and other
services, such as RPSL [RFC2622].
Although the WHOIS protocol specified in [RFC3912] is widely adopted
and supported, it has several shortcomings that limits its usefulness
to the evolving needs of the Internet community. For example, the
WHOIS protocol has not been Internationalized, it does not
consistently support Internationalized Domain Name (IDN, described in
[RFC5890]); WHOIS has no query and response format; and WHOIS
protocol does not support user authentication, access control for
differentiated access.
Recently, the Internet Engineering Task Force (IETF) chartered a new
working group to standardize a web-based (RESTful) Extensible
Registration Data Access Protocol. This document, to be read in
conjunction with the RESTful Query draft
[draft-hollenbeck-dnrd-ap-query-01], describes the response
specification for querying registration data through RESTful web
service.
The response formats for querying domain, contact, nameserver name
and registrar are defined in JSON, which is specified based on a
subset of the JavaScript Programming Language, Standard ECMA-262 3rd
Edition - December 1999 ([ECMA-262]) and [RFC4627].
2. Convention Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Abbreviations and Terminology
Domain Name Registration Data (DNRD) - refers to the information that
registrants provide when registering a domain name. Registrars and
registries collect this information and typically make a subset
available to the public via the Whois service.
JavaScript Object Notation (JSON) is a lightweight data-interchange
format. It is based on a subset of the JavaScript Programming
Language, Standard ECMA-262 3rd Edition - December 1999 ([ECMA-262])
Kong, et al. Expires December 5, 2012 [Page 3]
Internet-Draft DNRD JSON Response Format June 2012
and [RFC4627].
Representational state transfer (REST) is a software architecture
style for distributed systems such as the World Wide Web (Chapter 5
of Fielding's dissertation is [REST]).
RESTful web service is a web service implemented using HTTP and the
principles of REST. It is a collection of resources, with four
defined aspects:
o The base URI for the web service, such as
http://example.com/resources/.
o The Internet media type of the data supported by the web service.
This is often JSON, XML or YAML but can be any other valid
Internet media type.
o The set of operations supported by the web service using HTTP
methods (e.g., GET, PUT, POST, or DELETE).
o The API must be hypertext driven.
3. Response Format Specification
This section describes the response format specification for querying
domain name, nameserver, contact and registrar. The specific format
is defined in JSON. The basic querying URLs are described in the
draft-hollenbeck-dnrd-ap-query-01.
The following response objects defined MAY be supported optionally by
each registry. Clients processing JSON responses MUST be prepared
for values specified in this document to be absent from a response as
no JSON value listed in this document is required to appear in the
response. In other words, the server can remove the values as is
needed by the policy of the registries.
3.1. Domain Name Response Specification
This section gives the set of required information and format that
SHOULD be included in the domain name responses. An extension
interface MAY also be defined for customized response information.
The corresponding querying URI example is:
http://example.com/dnrd-ap/domain/example.com/ or
http://example.com/dnrd-ap/example.com/
Kong, et al. Expires December 5, 2012 [Page 4]
Internet-Draft DNRD JSON Response Format June 2012
The following is an elided example of a JSON response for a domain
query:
{
"domain": {
...
},
"nameserver": [
...
],
"contact": [
...
],
"registrar": {
...
},
"extension": {
...
}
}
3.1.1. Objects in the Domain Name Response
There are "domain", "nameserver", "contact", "registrar" and
"extension" objects included in the domain response. The followings
are description and explanation of objects members.
domain -- contains the information about the domain. The members of
domain object are defined as below.
o domainName -- contains the fully qualified name of the registered
domain.
o roid -- the identifier assigned to the domain name when the object
was created.
o domainStatus -- an array contains the current status values
defined in [RFC5731].
o clientID -- element that contains the identifier of the sponsoring
client.
o createID -- contains the identifier of the client that created the
domain.
Kong, et al. Expires December 5, 2012 [Page 5]
Internet-Draft DNRD JSON Response Format June 2012
o creationDate -- the date and time when the domain name is
registered. The date and time values MUST be represented in
Universal Coordinated Time (UTC).
o expirationDate -- the date and time when the domain name is
expiry. The date and time values MUST be represented in Universal
Coordinated Time (UTC).
o updateID -- contains the identifier of the client that updated the
domain.
o updateDate -- the date and time when the domain name is updated.
The date and time values MUST be represented in Universal
Coordinated Time (UTC).
o transferDate -- the date and time of the most recent successful
transfer. The date and time values MUST be represented in
Universal Coordinated Time (UTC). If no tranfer occurs, this key
MUST not be provided.
o dnssec -- the status of DNSSEC deployment. A value of "Signed" or
"Yes" means that DNSSEC has been deployed. A value of "Unsigned"
or "No" means that DNSSEC has not been deployed yet.
nameserver -- an array that contains the information about the
nameserver or host. If the array object is a nameserver,
"namerserverName" and "nameserverUri" SHOULD be the members of the
array object. If the array object is a host, "host" and "hostUri"
SHOULD be the members of the array object. Nameserver information is
specified before host information. The members of nameserver object
are defined as below.
o nameserverName -- the fully qualified names of the delegated host
objects.
o nameserverUri -- the access address for detailed information about
nameserver.
o host -- contains the fully qualified names of the subordinate host
objects that exist under this superordinate domain object.
o hostUri -- the access address for detailed information about
hosts.
contact -- an array that contains the information about the contacts.
There are 4 types of contacts, including "registrant", "admin",
"tech" and "billing" JSON objects. The members of contact object are
defined as below.
Kong, et al. Expires December 5, 2012 [Page 6]
Internet-Draft DNRD JSON Response Format June 2012
o type -- the type of contact. They are "registrant", "admin",
"tech" and "billing".
o contactID -- the identifier of registrant, administrative contact,
technical contact or billing contact.
o contactUri -- the access address for detailed information about
registrant, administrative contact, technical contact or billing
contact.
registrar -- contains the information about the registrar. The
members of registrar object are defined as below.
o sponsoringRegistrar -- the name of the corresponding registrar.
o registrarUri - the access address for detailed information about
registrar.
3.1.2. Extension Interface
A "Extension" key SHOULD be included in the JSON format for
customized extension information of each registry.
3.1.3. JSON Format
{
"domain": {
"domainName": "example.com",
"roid": "20030310s10001s00012956",
"domainStatus": [
"serverDeleteProhibited",
"serverUpdateProhibited",
"serverTransferProhibited"
],
"clientID": "ClientX",
"createID": "ClientY",
"creationDate": "2003-03-10T19:06:00Z",
"expirationDate": "2018-03-10T19:06:00Z",
"updateID": "ClientX",
"updateDate": "2006-03-10T19:06:00Z",
"transferDate": "",
"dnssec": "Unsigned"
},
"nameserver": [
{
"nameserverName": "ns1.example.com",
Kong, et al. Expires December 5, 2012 [Page 7]
Internet-Draft DNRD JSON Response Format June 2012
"nameserverUri":
"http://example.com/dnrd-ap/nameserver/ns1.example.com/"
},
{
"nameserverName": "ns2.example.com",
"nameserverUri":
"http://example.com/dnrd-ap/nameserver/ns2.example.com/"
},
{
"nameserverName": "ns3.example.com",
"nameserverUri":
"http://example.com/dnrd-ap/nameserver/ns3.example.com/"
},
{
"host": "ns1.example.com",
"hostUri":
"http://example.com/dnrd-ap/nameserver/ns1.example.com/"
},
{
"host": "ns2.example.com",
"hostUri":
"http://example.com/dnrd-ap/nameserver/ns2.example.com/"
},
{
"host": "ns3.example.com",
"hostUri":
"http://example.com/dnrd-ap/nameserver/ns3.example.com/"
}
],
"contact": [
{
"type": "registrant",
"contactID": "xyz",
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
},
{
"type": "admin",
"contactID": "xyz",
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
},
{
"type": "tech",
"contactID": "xyz",
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
},
{
"type": "billing",
"contactID": "xyz",
Kong, et al. Expires December 5, 2012 [Page 8]
Internet-Draft DNRD JSON Response Format June 2012
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
}
],
"registrar": {
"sponsoringRegistrar": "ABCRegistrar",
"registrarUri": "http://example.com/dnrd-ap/registrar/ABCRegistrar/"
},
"extension": {
...
}
}
3.2. Nameserver Response Specification
This section gives the set of required information and format that
SHOULD be included in the nameserver responses. An extension
interface MAY also be defined for customized response information.
The corresponding querying URL is:
http://example.com/dnrd-ap/nameserver/ns1.example.com/
The following is an elided example of a JSON response for a
nameserver query:
{
"nameserver": {
...
},
"extension": {
...
}
}
3.2.1. Objects in the Nameserver Response
nameserver -- contains the information about the domain. The members
of nameserver object are defined as below.
o roid -- the identifier assigned to the host object.
o nameserverName -- contains the fully qualified names of the
delegated host objects.
Kong, et al. Expires December 5, 2012 [Page 9]
Internet-Draft DNRD JSON Response Format June 2012
o nameserverStatus -- the status of host object.
o ipAddress -- contains the IPv4, IPv6, or both addresses.
o clientID -- element that contains the identifier of the sponsoring
client.
o createID -- contains the identifier of the client that created the
nameserver.
o creationDate -- the date and time when the nameserver is
registered. The date and time values MUST be represented in
Universal Coordinated Time (UTC).
o updateID -- contains the identifier of the client that updated the
domain.
o updateDate -- the date and time when the nameserver is updated.
The date and time values MUST be represented in Universal
Coordinated Time (UTC).
o transferDate -- the date and time of the most recent successful
transfer. The date and time values MUST be represented in
Universal Coordinated Time (UTC). If no tranfer occurs, this key
MUST not be provided.
3.2.2. Extension Interface
A "Extension" key SHOULD be included in the JSON format for
customized extension information of each registry.
3.2.3. JSON Format
Kong, et al. Expires December 5, 2012 [Page 10]
Internet-Draft DNRD JSON Response Format June 2012
{
"nameserver": {
"roid": "host397232",
"nameserverName": "ns1.example.com",
"nameserverStatus": [
"serverDeleteProhibited",
"serverUpdateProhibited"
],
"ipAddress":[
"192.0.2.123",
"2001:0DB8::1"
],
"clientID": "ClientX",
"createID": "ClientY",
"creationDate": "2006-09-27T09:27:00Z",
"updateID": "ClientX",
"updateDate": "2007-10-27T09:27:00Z",
"transferDate": ""
},
"extension": {
...
}
}
3.3. Contact Response Specification
This section gives the set of required information and format that
SHOULD be included in the contact responses. An extension interface
MAY also be defined for customized response information.
The corresponding querying URL is:
http://example.com/dnrd-ap/contact/CID-4005/
The following is an elided example of a JSON response for a contact
query:
{
"contact": {
...
},
"extension": {
...
}
}
Kong, et al. Expires December 5, 2012 [Page 11]
Internet-Draft DNRD JSON Response Format June 2012
3.3.1. Objects in the Contact Response
contact -- contains the information about the contacts. The members
of contact object are defined as below.
o contactID -- contains the identifier of the contact.
o roid -- contains the repository object identifier assigned to the
contact.
o contactStatus -- gives the status of the contact.
o postalInfo -- contains the post and address information. Both
internationalized and local addresses can be provided in this
object. A "type" member is defined with the value of "int" to
indicate internationalize address, and "loc" to indicate local
address.
* type -- contains the type of address, "int" is
internationalized adrress, "loc" is local address.
* contactName -- the name of the individual represented by the
contact.
* organization -- the group or company that the contact works
for.
* address -- contains the detailed address information.
+ street -- the street of the contact's address.
+ stateOrProvince -- the state or province of the contact's
address.
+ postalCode -- the postal code of the contact's address.
+ countryCode -- the contact's contry code.
o phoneNumber -- contains the contact's phone number.
o faxNumber -- contains the contact's fax number.
o email -- the email adress of the contact.
o clientID -- element that contains the identifier of the sponsoring
client.
Kong, et al. Expires December 5, 2012 [Page 12]
Internet-Draft DNRD JSON Response Format June 2012
o createID -- contains the identifier of the client that created the
contact.
o creationDate -- the date and time when the contact is created.
The date and time values MUST be represented in Universal
Coordinated Time (UTC).
o updateID -- contains the identifier of the client that updated the
contact.
o updateDate -- the date and time when the contact is updated. The
date and time values MUST be represented in Universal Coordinated
Time (UTC).
o transferDate -- the date and time of the most recent successful
transfer. The date and time values MUST be represented in
Universal Coordinated Time (UTC). If no tranfer occurs, this key
MUST not be provided.
3.3.2. Extension Interface
A "Extension" key SHOULD be included in the JSON format for
customized extension information of each registry.
3.3.3. JSON Format
Kong, et al. Expires December 5, 2012 [Page 13]
Internet-Draft DNRD JSON Response Format June 2012
{
"contact": {
"contactID": "CID-4005",
"roid": "CID-4005-REP",
"contactStatus": [
"ok",
"linked"
],
"postalInfo": [
{
"type": "int",
"contactName": "Smith",
"organization": "ABC Corp.",
"address": {
"street": "South 4th Street",
"stateOrProvince": "CN",
"postalCode": "100000",
"countryCode": "CN"
}
}
],
"phoneNumber": "+001.8002250180",
"faxNumber": "+001.8002250180",
"email": "domainadmin@example.com",
"clientID": "ClientX",
"createID": "ClientY",
"creationDate": "2006-09-27T09:27:00Z",
"updateID": "ClientX",
"updateDate": "2007-10-27T09:27:00Z",
"transferDate": ""
},
"extension":{
...
}
}
3.4. Registrar Response Specification
This section gives the set of required information and format that
SHOULD be included in the contact responses. An extension interface
MAY also be defined for customized response information.
The corresponding querying URL is:
http://example.com/dnrd-ap/registrar/Example Registrar, Inc./
The following is an elided example of a JSON response for a registrar
Kong, et al. Expires December 5, 2012 [Page 14]
Internet-Draft DNRD JSON Response Format June 2012
query:
{
"registrar": {
...
},
"registrarContact": [
...
],
"extension": {
...
}
}
3.4.1. Objects in the Registrar Response
registrar -- contains the information about the registrar. The
members of registrar object are defined as below.
o registrarIANAID -- contains the registrar ID specified by IANA.
o postalInfo -- contains the post and address information. Both
internationalized and local addresses can be provided in this
object. A "type" member is defined with the value of "int" to
indicate internationalize address, and "loc" to indicate local
address.
* type -- contains the type of address, "int" is
internationalized adrress, "loc" is local address.
* registrarName -- the name of the group or company represented
by the registrar.
* organization - the group or company that the contact works for.
* address -- contains the detailed address information.
+ street -- the street of the registrar's address.
+ stateOrProvince -- the state or province of the registrar's
address.
+ postalCode -- the postal code of the registrar's address.
Kong, et al. Expires December 5, 2012 [Page 15]
Internet-Draft DNRD JSON Response Format June 2012
+ countryCode -- the registrar's country code.
o phoneNumber -- contains the contact's phone registrar.
o faxNumber -- contains the contact's fax registrar.
o email -- the email address of the registrar.
o clientID -- element that contains the identifier of the sponsoring
client.
o createID -- contains the identifier of the client that created the
registrar.
o creationDate -- the date and time when the registrar is created.
The date and time values MUST be represented in Universal
Coordinated Time (UTC).
o updateID -- contains the identifier of the client that updated the
registrar.
o updateDate -- the date and time when the registrar is updated.
The date and time values MUST be represented in Universal
Coordinated Time (UTC).
o transferDate -- the date and time of the most recent successful
transfer. The date and time values MUST be represented in
Universal Coordinated Time (UTC). If no tranfer occurs, this key
MUST not be provided.
registrarContact -- an array contains the information of contacts
associated with the registrar.
o type -- the type of contact. They are "admin", "tech" and
"billing".
o contactID -- the identifier of administrative contact, technical
contact or billing contact.
o contactUri -- the access address for detailed information about
administrative contact, technical contact or billing contact.
3.4.2. Extension Interface
A "Extension" key SHOULD be included in the JSON format for
customized extension information of each registry.
Kong, et al. Expires December 5, 2012 [Page 16]
Internet-Draft DNRD JSON Response Format June 2012
3.4.3. JSON Format
Kong, et al. Expires December 5, 2012 [Page 17]
Internet-Draft DNRD JSON Response Format June 2012
{
"registrar": {
"registrarIANAID": "registrar1234",
"postalInfo": [
{
"type": "int",
"registrarName": "Example Registrar, Inc.",
"organization": "Example Corp.",
"address": {
"street": "South 4th Street",
"stateOrProvince": "CN",
"postalCode": "100000",
"countryCode": "CN"
}
}
],
"phoneNumber": "+001.8002250180",
"faxNumber": "+001.8002250180",
"email": "domainadmin@example.com",
"clientID": "ClientX",
"createID": "ClientY",
"creationDate": "2006-09-27T09:27:00Z",
"updateID": "ClientX",
"updateDate": "2007-10-27T09:27:00Z",
"transferDate": ""
},
"registrarContact": [
{
"type": "admin",
"contactID": "xyz",
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
},
{
"type": "tech",
"contactID": "xyz",
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
},
{
"type": "billing",
"contactID": "xyz",
"contactUri": "http://example.com/dnrd-ap/contact/xyz/"
}
],
"extension":{
...
}
}
Kong, et al. Expires December 5, 2012 [Page 18]
Internet-Draft DNRD JSON Response Format June 2012
4. Accept Header
Clients MAY use a MIME type, such as "application/json" to desire the
JSON format of response. The server SHOULD respond the client with
the proper MIME type in the accept header, and give the above
response in JSON format.
5. Internationalization Considerations
5.1. Encoding Specification
The response format MUST has a key for defining encoding format, such
as "encoding", to explicitly demonstrate the character encoding that
the server can support. Both the U-label and A-label domain names
can be included in the response.
5.2. IDN Variants
Internationalized Domain Names (IDNs), particularly variants, brought
about the need for multiple domain names to be registered and managed
as a single package, or registration bundle. The bundle variant
domain names share some attributes, such as expiration date and the
registrar. So when users update any properties within a bundle, all
of the domains' attributes in the bundle will be changed.
The response SHOULD be able to be extended to support the IDN
variants to show the list of the bundle variant domain names.
6. IANA Considerations
This document does not specify any IANA actions.
7. Security considerations
TBD
8. Acknowledgements
This document has been reviewed and improved by the design team. The
authors especially thank the following individuals who gave their
suggestions and contributions to this document: Andy Newton and Steve
Sheng.
Kong, et al. Expires December 5, 2012 [Page 19]
Internet-Draft DNRD JSON Response Format June 2012
9. References
9.1. Normative References
[ECMA-262]
"ECMAScript Language Specification", June 2011, <http://
www.ecma-international.org/publications/files/ECMA-ST/
Ecma-262.pdf>.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", June 2000, <http://
www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
June 1999.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, August 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
9.2. Informative References
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009.
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, August 2009.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, August 2009.
Kong, et al. Expires December 5, 2012 [Page 20]
Internet-Draft DNRD JSON Response Format June 2012
Authors' Addresses
Ning Kong
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3147
Email: nkong@cnnic.cn
Linlin Zhou
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 2677
Email: zhoulinlin@cnnic.cn
Jiagui Xie
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 2639
Email: xiejiagui@cnnic.cn
Sean Shen
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3038
Email: shenshuo@cnnic.cn
Kong, et al. Expires December 5, 2012 [Page 21]
