idnits 2.17.1 draft-sheng-weirds-icann-rws-dnrd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 292: '...nt following 'registrar' SHOULD be the...' RFC 2119 keyword, line 311: '... JSON [RFC4627] response, it SHOULD put the "application/json" MIME...' RFC 2119 keyword, line 312: '...header. Servers SHOULD respond with J...' RFC 2119 keyword, line 795: '... The identifiers SHALL be structured a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'REST' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'I-D.newton-et-al-weirds-rir-json-response' is defined on line 891, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-02) exists of draft-newton-et-al-weirds-rir-json-response-01 == Outdated reference: A later version (-02) exists of draft-newton-et-al-weirds-rir-query-01 -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sheng 3 Internet-Draft F. Arias 4 Intended status: Informational ICANN 5 Expires: September 13, 2012 F. Obispo 6 ISC 7 N. Kong 8 CNNIC 9 March 12, 2012 11 A RESTful Web Service for Domain Name Registration Data (RWS-DNRD) 12 draft-sheng-weirds-icann-rws-dnrd-01 14 Abstract 16 This document specifies a RESTful Web Service for querying Domain 17 Name Registration Data (WHOIS data). 19 The purpose of this document is to facilitate discussion and serve as 20 input into a standards process in this area, currently being 21 discussed on the Worthwhile Extensible Internet Registry Data Service 22 (WEIRDS) mailing list (https://www.ietf.org/mailman/listinfo/weirds). 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Domain Name Registration Data . . . . . . . . . . . . . . 3 60 1.2. REST and RESTful Web Service . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. The Request . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4. Registrars . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Signaling Response Formats . . . . . . . . . . . . . . . . 7 68 4. The Response . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3. Host Names . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.4. Registrars . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 16 75 6.1. Contact XML Schema . . . . . . . . . . . . . . . . . . . . 17 76 6.2. Domain Name XML Schema . . . . . . . . . . . . . . . . . . 17 77 6.3. Host XML Schema . . . . . . . . . . . . . . . . . . . . . 17 78 6.4. Registrar XML Schema . . . . . . . . . . . . . . . . . . . 17 79 6.5. RWS XML Schema . . . . . . . . . . . . . . . . . . . . . . 17 80 7. Internationalization Considerations . . . . . . . . . . . . . 17 81 7.1. Considerations for Querying IDNs . . . . . . . . . . . . . 17 82 7.2. Considerations for Display of Internationalized 83 Registration Data . . . . . . . . . . . . . . . . . . . . 18 84 7.3. Considerations for Indicating Language/scripts in 85 Responses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 19 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 90 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 19 91 11.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 19 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 94 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 This document describes a way for querying domain name registration 100 data through a RESTful Web-based Interface. This draft closely 101 follows the query patterns set by the Internet Draft on RESTful WHOIS 102 proposed by some Regional Internet Registries 103 ([I-D.newton-et-al-weirds-rir-query]). 105 1.1. Domain Name Registration Data 107 Domain Name Registration Data is the information that a registrant 108 provides when s/he acquires or is assigned a domain name. Many 109 domain registries and registrars ([RFC3707]) provide public access to 110 some of these data via the WHOIS protocol ([RFC3912]) or a web 111 interface. For example, for interactions between ICANN Accredited 112 Generic Top Level Domain (gTLD) registrars and registrants, the data 113 elements are specified in the current Registrar Accreditation 114 Agreement (RAA). For country code Top Level Domains (ccTLDs), the 115 operators of these TLDs set their own or follow their government's 116 policy regarding the request and display of these data. The Domain 117 Name Registration Data defined here is intended to satisfy such 118 public access services. 120 1.2. REST and RESTful Web Service 122 REST stands for Representational State Transfer. It is a set of 123 architectural constraints that is developed as an abstract model of 124 the Web architecture. These constraints include: client-server 125 model, stateless, cacheable, layered system, code on demand 126 (optional), and uniform interface. REST was used to guide the 127 redesign of the Hypertext Transfer Protocol (HTTP) and Uniform 128 Resource Identifiers (URI). It is widely regarded as the 129 architecture of the Web today. Principles of REST have been used to 130 design other protocols such as the ATOM publishing protocol. 132 A RESTful web service is a web service implemented using HTTP and the 133 principles of REST. It is a collection of resources, with three 134 defined aspects: 1) The "verbs" of the service are strictly those 135 defined by the HTTP methods HEAD, GET, PUT, POST, and DELETE, 2) The 136 "verbs" are used to act upon resources, and 3) resources are 137 addressable using URLs 139 Whois services, in general, are read-only services. Therefore URL 140 patterns [RFC3986] presented here are only applicable to the HTTP 141 [RFC2616] GET and HEAD methods. 143 2. Terminology 145 For convenience, this implementation can be referred to as the 146 "RESTful Web Service for Domain Name Registration Data" or "RWS - 147 DNRD". The following terminology is used by this specification: 149 Domain Name Registration Data (DNRD) - the information that 150 registrants provide when registering a domain name and that 151 registrars or registries supplement with registry or registrar 152 specific information. 154 URI - A Uniform Resource Identifier as defined in [RFC3986]. 156 IRI - An internationalized Resource Identifier as defined in 157 [RFC3987]. 159 Resource - A network-accessible data object or service identified 160 by an URI, as defined in [RFC2616]. In this context, resources 161 refers to the registration data objects. 163 Representation - An entity included with a request or response as 164 defined in [RFC2616]. 166 Additionally, we use ".tld" as a convention in this document to 167 represent, generically, any top level domain (TLD) in the Domain Name 168 System (DNS). 170 3. The Request 172 As its name implies RWS-DNRD is Web-based, i.e., uses HTTP [RFC2616] 173 as its transport. Given its RESTful nature it only uses the standard 174 HTTP methods. And given it is read-only, it only uses the GET and 175 HEAD methods. 177 The server accepts standard HTTP "GET" requests for the resources it 178 serves. The client sends its request with the following URI 179 structure. The URI structure start with a base URL specified by each 180 domain registry or any other service provider offering this service. 181 The base URL will be appended with resource type specific path 182 segments. The base URL may contain its own path segments (e.g. 183 http://whois.tld/... or http://whois.tld/restful-whois/...). 185 The resource type path segments are: 187 'domain' - information about the domain including registration 188 information, contact information, host information and possible 189 other details specified by registries' Whois policy. 191 'contact'- Contact record for a particular entity. This includes 192 contact name, organization, address, phone, email, etc. 194 'host' - information about an Internet Host. This includes server 195 name, ipv4 or ipv6 address, sponsoring registrar, etc. 197 'registrar' - information about an registrar, specifically the 198 sponsoring registrar. This includes registrar name, address, 199 contact information, etc. 201 3.1. Domain 203 Queries for information about domain names are of the form /domain/ 204 example.tld/... where the path segment following 'domain' is an 205 domain name, in this case example.tld. Path segments following the 206 domain name can target specific information associated with the 207 domain name in the following way: 209 'registration' - for the registration data associated with the 210 domain name including references to contacts and registrar, but 211 not the actual contact information. 213 'contacts' - contact information for the domain. 215 'registrar' - contact information of the sponsoring registrar of 216 the domain name. 218 Optionally, specific type of contact information may be further 219 targeted by following that path segment with a type. What types of 220 contacts a registry supports is for each registry policy to define. 221 Examples of types of contacts typically supported are: 223 registrant - contact information for the registrant 225 admin - administrative contact information 227 tech - technical contact information 229 billing - billing contact information 231 Finally, when no path segment follows the domain name, the semantics 232 of the query are that both registration, contact, and registrar 233 information are to be returned. 235 Here are some example queries: 237 base URL: http://whois.tld/somepath 238 /domain/example.tld/ - returns all of example.tld's information. 239 This includes registration, contact, host, and sponsoring 240 registrar information. 242 /domain/example.tld/registration - query for example.tld's 243 registration information. It will return the registration record 244 with references to the contacts, registrar, name servers, and 245 hosts. But it would not return the actual information for those 246 data objects. 248 /domain/example.tld/contacts - returns all the contact information 249 fordomain example.tld. 251 /domain/example.tld/contacts/registrant - returns only the 252 registrant information for domain example.tld. 254 /domain/example.tld/contacts/tech - returns only the technical 255 contact's information for domain example.tld. 257 /domain/example.tld/registrar - returns the sponsoring registrar's 258 contact information for domain example.tld. 260 3.2. Contacts 262 Queries for information about contacts are of the form /contact/ 263 contact-id/... where the contact-id is the id that the registry or 264 registrar, as the case may be, uses to uniquely identify the contact. 265 Path segments following the domain name can target specific 266 information associated with the domain name in the following way: 268 Here are some example queries: 270 Base URL: http://whois.tld/somepath 272 /contact/CNT-2222/ - queries the registrar or registry for contact 273 id CNT-2222. 275 3.3. Hosts 277 Queries for information about hosts (or nameservers) are of the form 278 /host/XXX/... where the path segment following 'host' is either a 279 hostname [RFC1123], IPv4 [RFC0791] or IPv6 [RFC5952] address of the 280 hostname. 282 Here are some example queries: 284 base URL: http://whois.tld/somepath 285 /host/192.0.2.0/ - queries for host name with IPv4 address. 287 /host/ns.example.tld/ - queries for host name ns.example.tld. 289 3.4. Registrars 291 Queries for information about registrars are of the form /registrar/ 292 XXX/... where the path segment following 'registrar' SHOULD be the 293 the full name of the registrar (including punctuation, "Inc.", etc.) 294 or its assigned ID. 296 Here are some example queries: 298 base URL: http://whois.tld/somepath 300 /registrar/"Network Solutions, LLC"/ - query the registrar names 301 "Network Solutions. LLC" 303 /registrar/123/ - queries the registrar whose ID is 123. 305 3.5. Signaling Response Formats 307 The default response format for the RWS-RDNRD server is XML. 308 However, additional formats such as JSON, HTML or plain text can be 309 provided. The client signals the preferred format using the standard 310 HTTP "Accept:" header. For example, if the client wishes to receive 311 JSON [RFC4627] response, it SHOULD put the "application/json" MIME 312 type in the Accept header. Servers SHOULD respond with JSON 313 responses when this MIME type is present in the Accept header in 314 accordance with the preference rules for the Accept header in HTTP 315 [RFC2616]. However the use of multiple MIME types in the Accept 316 header is not supported. 318 Possible response formats and their signaling methods include: 320 XML (default) - application/xml 322 JSON - application/json 324 HTML - text/html 326 plain text - text/plain 328 4. The Response 330 The root element for a RWS-DNRD response is . This element 331 contains one element, and one element, that are 332 explained in the following section. 334 Example of root element object: 336 337 340 ... 341 342 343 ... 344 345 ... 346 348 4.1. Domain Names 350 Example Query: http://whois.test/domain/example.test/ 352 Response: 354 355 356 357 360 example.test 361 9690-TEST 362 363 364 365 366 jd4447 367 368 369 jd4447 370 371 372 jd4447 373 374 375 376 ns1.example.test 378 379 380 ns2.example.test 381 382 383 ns3.example.test 384 385 386 387 reg-793 388 389 390 reg-1289 391 392 1992-07-26T09:10:56Z 393 2019-01-21T10:11:18Z 394 395 396 397 400 jd4447 401 402 403 John Doe 404 Example Inc. 405 406 123 Example Dr. 407 Suite 100 408 Redwood City 409 CA 410 94063 411 US 412 413 414 +1.7035555555 415 +1.7035555556 416 jdoe@example.com 417 418 reg-793 419 420 1999-04-03T22:00:00.0Z 421 ClientX 422 1999-12-03T09:00:00.0Z 423 424 426 ns1.example.test 427 428 192.168.12.13 429 192.14.15.16 430 2001::A:B:C:1 431 432 reg-793 433 434 435 437 ns2.example.test 438 439 172.16.10 440 172.17.12 441 2001::B:C:D:1 442 443 reg-793 444 445 446 448 ns3.example.test 449 450 10.1.2.3 451 10.4.5.6 452 2001::C:D:E:1 453 454 reg-793 455 456 457 460 reg-793 461 Example Registrar Inc. 462 463 466 reg-1289 467 XYZ Corporation 468 469 470 472 Example Query: http://whois.test/domain/example.test/registration/ 473 Response: 475 476 477 478 481 example.test 482 9690-TEST 483 484 485 486 487 jd4447 488 489 490 jd4447 491 492 493 jd4447 494 495 496 497 ns1.example.test 498 499 500 ns2.example.test 501 502 503 ns3.example.test 504 505 506 507 reg-793 508 509 510 reg-1289 511 512 1992-07-26T09:10:56Z 513 2019-01-21T10:11:18Z 514 515 516 517 Example Query: http://whois.test/domain/example.test/contacts/ 519 Response: 521 TBD. 523 Example Query: 524 http://whois.test/domain/example.test/contacts/registrant/ 526 Response: 528 TBD. 530 Example Query: http://whois.test/domain/example.test/registrar/ 532 Response: 534 TBD. 536 4.2. Contacts 538 Example Query: http://whois.test/contact/jd4447/ 540 Response: 542 543 544 545 548 jd4447 549 550 551 John Doe 552 Example Inc. 553 554 123 Example Dr. 555 Suite 100 556 Redwood City 557 CA 558 94063 559 US 560 561 562 +1.7035555555 563 +1.7035555556 564 jdoe@example.com 565 566 reg-793 567 568 1999-04-03T22:00:00.0Z 569 1999-12-03T09:00:00.0Z 570 571 572 573 576 reg-793 577 Example Registrar Inc. 578 579 580 582 Example Query: http://whois.test/contact/jd4447/registration/ 584 Response: 586 587 588 589 592 jd4447 593 594 595 John Doe 596 Example Inc. 597 598 123 Example Dr. 599 Suite 100 600 Redwood City 601 CA 602 94063 603 US 604 605 606 +1.7035555555 607 +1.7035555556 608 jdoe@example.com 609 610 reg-793 611 612 1999-04-03T22:00:00.0Z 613 1999-12-03T09:00:00.0Z 614 615 616 618 Example Query: http://whois.test/contact/jd4447/registrar/ 620 Response: 622 TBD. 624 4.3. Host Names 626 Example Query: http://whois.test/host/ns1.example.test/ 628 Response: 630 631 632 633 635 ns1.example.test 636 637 192.168.12.13 638 192.14.15.16 639 2001::A:B:C:1 640 641 reg-793 642 643 644 645 646 649 reg-793 650 Example Registrar Inc. 651 652 653 655 Example Query: http://whois.test/host/ns1.example.test/registration/ 657 Response: 659 660 661 662 664 ns1.example.test 665 666 192.168.12.13 667 192.14.15.16 668 2001::A:B:C:1 669 670 reg-793 671 672 673 674 675 Example Query: http://whois.test/host/ns1.example.test/registrar/ 677 Response: 679 TBD. 681 4.4. Registrars 683 TBD 685 5. Error Codes 687 In compliance with the REST paradigm any error information is 688 returned in the form of a standard HTTP response with an HTTP status 689 code describing the error and a text/plain body message describing 690 the exception causing the error response. In this version we are 691 using only standard HTTP codes 692 (http://www.iana.org/assignments/http-status-codes). 694 [[ Define specialized error codes. ]] 696 6. Formal XML Syntax 698 The formal syntax presented here is a complete schema representation 699 suitable for automated validation of an XML instance. It is based on 700 the object schemas from the Extension Provisioning Protocol (EPP), by 701 Scott Hollenbeck. It references and includes the following EPP 702 schemas: 704 [RFC5730] - Extensible Provisioning Protocol (EPP) 706 [RFC5731] - Extensible Provisioning Protocol (EPP) Domain Name 707 Mapping 709 [RFC5732] - Extensible Provisioning Protocol (EPP) Host Mapping 711 [RFC5733] - Extensible Provisioning Protocol (EPP) Contact Mapping 713 To represent objects, the section will contain exactly one 714 element, under a specific namespace that describes the 715 object type. The object element will also contain an "href" property 716 which can be used to verify it against the query. 718 Objects in the result element can refer to other objects, i.e.: a 719 domain object with multiple host object associations, contacts, etc. 720 In order for the client to obtain all the information needed about 721 the queried object, additional objects can be described within the 722 section. Only objects referenced in the 723 element from the section are allowed in the 724 section. 726 Server implementations can opt not to return the full object, but 727 instead define an empty element with an appropriate "href" 728 property. This enables the client to retrieve the additional objects 729 from the server if needed. 731 6.1. Contact XML Schema 733 TBD 735 6.2. Domain Name XML Schema 737 TBD 739 6.3. Host XML Schema 741 TBD 743 6.4. Registrar XML Schema 745 TBD 747 6.5. RWS XML Schema 749 TBD 751 7. Internationalization Considerations 753 7.1. Considerations for Querying IDNs 755 Three possibilities exist on how to query IDNs: 757 U-label only - in this case an U-label is entered as part of the 758 query. For example: /domain/"U+82F1""U+96C4".test 760 A-label only - in this case the U-label is first converted to its 761 corresponding A-label before submitted to the server. In the 762 example above, the U-label would be /domain/xn--dj1az91b.test 763 before it is submitted to the RWS-DNRD. 765 IRI -> URI conversion - in this case the IRI (which contains the 766 U-label) is converted to URI according to [[RFC3987]] before 767 submitted to the server. In the example above, the query becomes 768 /domain/%E8%8B%B1%E9%9B%84.test 770 7.2. Considerations for Display of Internationalized Registration Data 772 Information published in RWS-DNRD is represented in XML, which 773 provides native support for encoding information using the Unicode 774 character set and its more compact representations including UTF-8. 775 Conformant XML processors recognize both UTF-8 and UTF-16. Though 776 use of UTF-8 is preferred, XML includes provisions to identify and 777 use other character encodings through use of an "encoding" attribute 778 in an declaration. 780 7.3. Considerations for Indicating Language/scripts in Responses 782 The RWS-DNRD proposed by this document supports internationalized 783 registration data, responses of a RWS-DNRD server may contain data in 784 any languages/scripts. Although the internationalized registration 785 data of a RWS-DNRD response can be correctly displayed, users will 786 still be confused when reading the data in a language which t hey are 787 not familiar. So if the response of the RWS-DNRD need to contain 788 information to indicate the language/scripts the responses is in. 789 This is also one of the recommendations / requirements from the ICANN 790 Internationalized Registration Data Working Group Final Report 791 [IRD-WG]. 793 In order to meet the above requirement, one additional data element 794 needs to be added to allow for the association of the IRD response to 795 a language/script identifier. The identifiers SHALL be structured as 796 documented in [RFC5646]. 798 For example, 800 801 803 zh 804 805 806 ... 807 808 810 The above solution can only support one language within one response. 811 If multiple languages need to be supported by one response, one 812 additional attribute of data element might be considered to be added 813 to allow for association of the value of a data element to an 814 internationalized language identifier. 816 Further discussions is needed on this topic. 818 8. IANA Considerations 820 TBD 822 9. Security Considerations 824 TBD 826 9.1. URIs and IRIs 828 RWS-DNRD implementations use URIs and IRIs. See Section 7 of 829 [RFC3986] and Section 8 of [RFC3987] for security considerations 830 related to their handling and use. 832 10. Acknowledgments 834 Parts of this document are based on EPP [RFC5730] and related RFCs by 835 Scott Hollenbeck. 837 The authors would like to acknowledge the following individuals for 838 their input: Andy Newton, Andrew Sullivan, Dave Piscitello and James 839 Galvin. 841 11. Change History 843 11.1. Changes from version 00 to 01 845 1. Added two co-authors. 847 2. Modified the query structure to resemble RIR query structures 849 3. Added considerations for the query of Internationalized Domain 850 Names (IDNs) 852 4. Added considerations for the display of Internationalized 853 Registration Data. 855 5. Updated the data schema. 857 6. Fixed some typographical errors and omissions. 859 12. References 861 12.1. Normative References 863 [REST] Fielding, R. and R. Taylor, "Principled Design of the 864 Modern Web Architecture", ACM Transactions on Internet 865 Technology Vol. 2, No. 2, May 2002. 867 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 868 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 869 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 871 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 872 Languages", BCP 47, RFC 5646, September 2009. 874 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 875 STD 69, RFC 5730, August 2009. 877 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 878 Domain Name Mapping", STD 69, RFC 5731, August 2009. 880 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 881 Host Mapping", STD 69, RFC 5732, August 2009. 883 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 884 Contact Mapping", STD 69, RFC 5733, August 2009. 886 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 887 Address Text Representation", RFC 5952, August 2010. 889 12.2. Informative References 891 [I-D.newton-et-al-weirds-rir-json-response] 892 Newton, A., Ranjbar, K., Servin, A., and B. Ellacott, 893 "JSON Responses to RESTful URL Queries for RIRs", 894 draft-newton-et-al-weirds-rir-json-response-01 (work in 895 progress), March 2012. 897 [I-D.newton-et-al-weirds-rir-query] 898 Newton, A., Ranjbar, K., Servin, A., and B. Ellacott, "A 899 Uniform RESTful URL Query Pattern for RIRs", 900 draft-newton-et-al-weirds-rir-query-01 (work in progress), 901 March 2012. 903 [IRD-WG] ICANN, "The Final Report of the Internationalized 904 Registration Data Working Group", February 2012. 906 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 907 September 1981. 909 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 910 and Support", STD 3, RFC 1123, October 1989. 912 [RFC3707] Newton, A., "Cross Registry Internet Service Protocol 913 (CRISP) Requirements", RFC 3707, February 2004. 915 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 916 September 2004. 918 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 919 Resource Identifier (URI): Generic Syntax", STD 66, 920 RFC 3986, January 2005. 922 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 923 Identifiers (IRIs)", RFC 3987, January 2005. 925 [RFC4627] Crockford, D., "The application/json Media Type for 926 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 928 Authors' Addresses 930 Steve Sheng 931 Internet Corporation for Assigned Names and Numbers 932 4676 Admiralty Way, Suite 330 933 Marina del Rey, CA 90292 934 United States of America 936 Phone: +1.310.823.9358 937 Email: steve.sheng@icann.org 939 Francisco Arias 940 Internet Corporation for Assigned Names and Numbers 941 4676 Admiralty Way, Suite 330 942 Marina del Rey, CA 90292 943 United States of America 945 Phone: +1.310.823.9358 946 Email: francisco.arias@icann.org 947 Francisco Obispo 948 Internet Systems Consortium 949 950 Charter St 950 Redwood City, CA 94063 951 United States of America 953 Phone: +1.650.423.1374 954 Email: fobispo@isc.org 956 Ning Kong 957 China Internet Network Information Center 958 4 South 4th Street, Zhongguancun, Haidian District 959 Beijing 100190 960 China 962 Phone: +86 10 5881 3147 963 Email: nkong@cnnic.cn