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, . [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", June 2000, . [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]