idnits 2.17.1 draft-ietf-weirds-using-http-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations: n/a' ) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 172: '... Clients SHOULD put the media type o...' RFC 2119 keyword, line 173: '...eader field, and SHOULD use the Accept...' RFC 2119 keyword, line 180: '... Servers SHOULD respond with an appr...' RFC 2119 keyword, line 182: '... header in HTTP [RFC2616]. Servers SHOULD affix a media type...' RFC 2119 keyword, line 190: '... Clients MAY use a generic media typ...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2012) is 4234 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4034' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC5396' is defined on line 730, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SAC-051' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft ARIN 4 Intended status: Standards Track B. Ellacott 5 Expires: March 25, 2013 APNIC 6 N. Kong 7 CNNIC 8 September 21, 2012 10 Using the Registration Data Access Protocol (RDAP) with HTTP 11 draft-ietf-weirds-using-http-00 13 Abstract 15 This document describes the usage of the Registration Data Access 16 Protocol (RDAP) using HTTP. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 25, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . . 6 58 5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . . 7 60 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . . 7 62 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7 63 6. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Use of XML . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 7.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.2. Naming and Structure . . . . . . . . . . . . . . . . . . . 11 69 8. Common Error Response Body . . . . . . . . . . . . . . . . . . 13 70 9. Common Data Structures . . . . . . . . . . . . . . . . . . . . 14 71 10. Common Datatypes . . . . . . . . . . . . . . . . . . . . . . . 16 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 11.1. IANA Registry for RDAP Extensions . . . . . . . . . . . . 17 74 11.2. Registration of RDAP Media Type for JSON . . . . . . . . . 18 75 11.3. Registration of RDAP Media Type for XML . . . . . . . . . 18 76 12. Internationalization Considerations . . . . . . . . . . . . . 20 77 12.1. URIs vs IRIs . . . . . . . . . . . . . . . . . . . . . . . 20 78 12.2. Character Encoding . . . . . . . . . . . . . . . . . . . . 20 79 13. Normative References . . . . . . . . . . . . . . . . . . . . . 21 80 Appendix A. Cache Busting . . . . . . . . . . . . . . . . . . . . 23 81 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 24 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 This document describes the usage of HTTP for Registration Data 87 Directory Services running on RESTful web servers. The goal of this 88 document is to tie together the usage patterns of HTTP into a common 89 profile applicable to the various types of Directory Services serving 90 Registration Data using RESTful styling. By giving the various 91 Directory Services common behavior, a single client is better able to 92 retrieve data from Directory Services adhering to this behavior. 94 In designing these common usage patterns, this draft endeavours to 95 satisfy requirements for a Registration Data Access Protocol (RDAP) 96 that is documented in [draft-kucherawy-weirds-requirements]. This 97 draft also introduces an additional design consideration to define a 98 simple use of HTTP. Where complexity may reside, it is the goal of 99 this specification to place it upon the server and to keep the client 100 as simple as possible. A client should be possible using common 101 operating system scripting tools. 103 This is the basic usage pattern for this protocol: 105 1. A client issues an HTTP query using GET. As an example, a query 106 for the network registration 192.168.0.0 might be 107 http://example.com/ip/192.168.0.0. 109 2. If the receiving server has the information for the query, it 110 examines the Accept header field of the query and returns a 200 111 response with a response entity appropriate for the requested 112 format. 114 3. If the receiving server does not have the information for the 115 query but does have knowledge of where the information can be 116 found, it will return a redirection response (3xx) with the 117 Redirect header containing an HTTP URL pointing to the 118 information. The client is expected to re-query using that HTTP 119 URL. 121 4. If the receiving server does not have the information being 122 requested and does not have knowledge of where the information 123 can be found, it should return a 404 response. 125 It is important to note that it is not the intent of this document to 126 redefine the meaning and semantics of HTTP. The purpose of this 127 document is to clarify the use of standard HTTP mechanisms for this 128 application. 130 2. Terminology 132 As is noted in SSAC Report on WHOIS Terminology and Structure 133 [SAC-051], the term "Whois" is overloaded, often referring to a 134 protocol, a service and data. In accordance with [SAC-051], this 135 document describes the base behavior for a Registration Data Access 136 Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for 137 Doman Name Registries (DNRs), DNRD-AP. This document and others from 138 the IETF WEIRDS working group describe a single protocol, RDAP, for 139 access to the data of both DNRs and Regional Internet Registries 140 (RIRs). RIRs are also often refered to as number resource registries 141 and are responsible for the registration of IP address networks and 142 autonomous system numbers. 144 3. Design Intents 146 There are a few design criteria this document attempts to support. 148 First, each query is meant to return either zero or one result. With 149 the maximum upper bound being set to one, the issuance of redirects 150 is simplified to the known query/respone model used by HTTP 151 [RFC2616]. Should a result contain more than one result, some of 152 which are better served by other servers, the redirection model 153 becomes much more complicated. 155 Second, multiple response formats are supported by this protocol. 156 This document outlines the base usage of JSON and XML, but server 157 operators may support other formats as they desire if appropriate. 159 Third, HTTP offers a number of transport protocol mechanisms not 160 described further in this document. Operators are able to make use 161 of these mechanisms according to their local policy, including cache 162 control, authorization, compression, and redirection. HTTP also 163 benefits from widespread investment in scalability, reliability, and 164 performance, and widespread programmer understanding of client 165 behaviours for RESTful web services, reducing the cost to deploy 166 Registration Data Directory Services and clients. 168 4. Queries 170 4.1. Accept Header 172 Clients SHOULD put the media type of the format they desire in the 173 Accept header field, and SHOULD use the Accept header parameter 174 "level" to indicate the version of the format acceptable [RFC2616]. 176 Accept: applicaiton/rdap+json;level=0 178 Figure 1 180 Servers SHOULD respond with an appropriate media type in the Content- 181 Type header in accordance with the preference rules for the Accept 182 header in HTTP [RFC2616]. Servers SHOULD affix a media type 183 parameter of "level" appropriate to the version of the format being 184 sent. 186 Content-Type: application/rdap+json;level=0 188 Figure 2 190 Clients MAY use a generic media type for the desired data format of 191 the response (e.g. "application/json"), but servers SHOULD respond 192 with the most appropriate media type and corresponding level (e.g. 193 "application/rdap+json;level=0"). In other words, a client may use 194 "application/json" to express that it desires JSON or "application/ 195 weirds_blah+json" to express that it desires WEIRDS BLAH in JSON. 196 The server MUST respond with "application/rdap+json;level=0". 198 4.2. Query Parameters 200 Servers SHOULD ignore unknown query parameters. Use of unknown query 201 parameters for cache-busting is described in Appendix A. 203 5. Types of HTTP Response 205 This section describes the various types of responses a server may 206 send to a client. While no standard HTTP response code is forbidden 207 in usage, at a minimum clients should understand the response codes 208 described in this section. It is expected that usage of response 209 codes and types for this application not defined here will be 210 described in subsequent documents. 212 5.1. Positive Answers 214 If a server has the information requested by the client and wishes to 215 respond to the client with the information according to its policies, 216 it should encode the answer in the format most appropriate according 217 to the standard and defined rules for processing the HTTP Accept 218 header, and return that answer in the body of a 200 response. 220 5.2. Redirects 222 If a server wishes to inform a client that the answer to a given 223 query can be found elsewhere, it SHOULD return either a 301 or a 307 224 response code and an HTTP URL in the Redirect header. The client is 225 expected to issue a subsequent query using the given URL without any 226 processing of the URL. In other words, the server is to hand back a 227 complete URL and the client should not have to transform the URL to 228 follow it. 230 A server should use a 301 response to inform the client of a 231 permanent move and a 307 response otherwise. For this application, 232 such an example of a permanent move might be a TLD operator informing 233 a client the information being sought can be found with another TLD 234 operator (i.e. a query for the domain bar in foo.example is found at 235 http://foo.example/domain/bar). 237 5.3. Negative Answers 239 If a server wishes to respond that it has no information regarding 240 the query, it SHOULD return a 404 response code. Optionally, it may 241 include additional information regarding the lack of information as 242 defined by Section 8. 244 5.4. Malformed Queries 246 If a server receives a query which it cannot understand, it SHOULD 247 return a 400 response code. Optionally, it may include additional 248 information about why it does not understand the query as defined by 249 Section 8. 251 6. Use of JSON 253 6.1. Signaling 255 Clients may signal their desire for JSON using the "application/json" 256 media type or a more application specific JSON media type. 258 6.2. Naming 260 Clients processing JSON [RFC4627] responses SHOULD ignore values 261 associated with unrecognized names. Servers MAY insert values 262 signified by names into the JSON responses which are not specified in 263 this document. Insertion of unspecified values into JSON responses 264 SHOULD have names prefixed with a short identifier followed by an 265 underscore followed by a meaningful name. 267 For example, a JSON object may have "handle" and "remarks" formally 268 documented in a specification. Clients adhering to that 269 specification will have appropriate knowledge of the meaning of 270 "handle" and "remarks". 272 Consider the following JSON response with JSON names. 274 { 275 "handle" : "ABC123", 276 "remarks" : [ 277 "she sells seas shells", 278 "down by the seashore" 279 ] 280 } 282 Figure 3 284 If The Registry of the Moon desires to express information not found 285 in the specification, it might select "lunarNic" as its identifying 286 prefix and insert, as an example, the name 287 "lunarNic_beforeOneSmallStep" to signify registrations occuring 288 before the first moon landing and the name 289 "lunarNic_harshMistressNotes" containing other descriptive text. 291 Consider the following JSON response with JSON names, some of which 292 should be ignored by clients without knowledge of their meaning. 294 { 295 "handle" : "ABC123", 296 "lunarNic_beforeOneSmallStep" : "TRUE THAT!", 297 "remarks" : [ 298 "she sells seas shells", 299 "down by the seashore" 300 ], 301 "lunarNic_harshMistressNotes" : [ 302 "In space,", 303 "nobody can hear you scream." 304 ] 305 } 307 Figure 4 309 Insertion of unrecognized names ignored by clients may also be used 310 for future revisions to specifications and specifications deriving 311 extensions from a base specification. 313 JSON names SHOULD only consist of the alphabetic ASCII characters A 314 through Z in both uppercase and lowercase, the numerical digits 0 315 through 9, underscore characters, and SHOULD NOT begin with an 316 underscore character, numerical digit or the characters "xml". The 317 following describes the produciton of JSON names in ABNF [RFC5234]. 319 ABNF for JSON names 321 name = ALPHA *( ALPHA / DIGIT / "_" ) 323 Figure 5 325 This restriction is a union of the Ruby programming language 326 identifier syntax and the XML element name syntax and has two 327 purposes. First, client implementers using modern programming 328 languages such as Ruby or Java may use libraries that automatically 329 promote JSON names to first order object attributes or members (e.g. 330 using the example above, the values may be referenced as 331 network.handle or network.lunarNic_beforeOneSmallStep). Second, a 332 clean mapping between JSON and XML is easy to accomplish using the 333 JSON representation. 335 Clients processing JSON responses MUST be prepared for values 336 specified in the registry response documents to be absent from a 337 response as no JSON value listed is required to appear in the 338 response. In other words, servers MAY remove values as is needed by 339 the policies of the server operator. 341 7. Use of XML 343 7.1. Signaling 345 Clients may signal their desire for XML using the "application/xml" 346 media type or a more application specific XML media type. 348 7.2. Naming and Structure 350 Well-formed XML may be programmatically produced using the JSON 351 encodings due to the JSON naming rules outlined in Section 6.2 and 352 the following simple rules: 354 1. Where a JSON name is given, the corresponding XML element has the 355 same name. 357 2. Where a JSON value is found, it is the content of the 358 corresponding XML element. 360 3. Where a JSON value is an array, the XML element is to be repeated 361 for each element of the array. 363 4. The root tag of the XML document is to be "response". 365 Consider the following JSON response. 367 { 368 "startAddress" : "10.0.0.0", 369 "endAddress" : "10.0.0.255", 370 "remarks" : [ 371 "she sells seas shells", 372 "down by the seashore" 373 ], 374 "uris" : [ 375 { 376 "type" : "source", 377 "uri" : "http://whois-rws.net/network/xxxx" 378 }, 379 { 380 "type" : "parent", 381 "uri" : "http://whois-rws.net/network/yyyy" 382 } 383 ] 384 } 386 Figure 6 388 The corresponding XML would look like this: 390 391 10.0.0.0 392 10.0.0.255 393 She sells sea shells 394 down by the seashore 395 396 source 397 http://whois-rws.net/network/xxxx 398 399 400 parent 401 http://whois-rws.net/network/yyyy 402 403 405 JSON values converted to XML element content MUST be properly 406 escaped. XML offers various means for escaping data, but such 407 escaping MUST account for the '<', '>', and '&' characters and MUST 408 redact all C0 control characters except tab, carriage return, and 409 new-line. (Redaction of disallowed control characters is a protocol 410 requirement, though in practice most Internet registries do not allow 411 this data in their data stores and therefore do not need to account 412 for this rule.) 414 The rules for clients processing XML responses are the same as those 415 with JSON: clients SHOULD ignore unrecognized XML elements, and 416 servers MAY insert XML elements with tag names according to the 417 naming rules in Section 6.2. And as with JSON, clients MUST be 418 prepared for XML elements specified in the registry response 419 documents to be absent from a response as no XML element listed is 420 required to appear in the response. 422 8. Common Error Response Body 424 As specified in Section 5, some non-answer responses may return 425 entity bodies with information that could be more descriptive. 427 The basic structure of that response is a data class containing an 428 error code number (corresponding to the HTTP response code) followed 429 by a string named "title" followed by an array of strings named 430 "description". 432 This is an example of the JSON version of the common response body. 434 { 435 "errorCode": 418 436 "title": "Your beverage choice is not available", 437 "description": [ 438 "I know coffee has more ummppphhh.", 439 "But I cannot provide." ] 440 } 442 Figure 7 444 This is an example of the XML version of the common response body. 446 447 418 448 Your beverage choice is not available 449 I know coffee has more ummppphhh. 450 But I cannot provide. 451 453 Figure 8 455 The media type for the JSON structure is "application/ 456 rdap_error+json" and the media type for the XML document is 457 "application/rdap_error+xml". Conformance to this specification is 458 considered to be level 0 for both media types. 460 A client MAY simply use the HTTP response code as the server is not 461 required to include error data in the response body. However, if a 462 client wishes to parse the error data, it SHOULD first check that the 463 Content-Type header contains the appropriate media type. 465 9. Common Data Structures 467 This section defines two common data structures to be used by 468 DNRD-AP, NRRD-AP, and other RD-AP protocols. As such, the names 469 identifying these data structures are not to be redefined by any 470 registry specific RD-AP specifications. Each of these datatypes MAY 471 appear within any other data object of a response, but the intended 472 purpose is that they will be mostly used in the top-most data object 473 of a response. 475 The first data structure is named "rdapConformance" and is simply an 476 array of strings, each providing a hint as to the specifications used 477 in the construction of the response. 479 An example rdapConformance data structure. 481 "rdapConformance" : [ 482 "nrrdap_level_0" 483 ] 485 Figure 9 487 The second data structure is named "notices" and is an array of 488 "notice" objects. Each "notice" object contains a "title" string 489 representing the title of the notice object, an array of strings 490 named "description" for the purposes of conveying any descriptive 491 text about the notice, and a "uri" string holding a URI referencing a 492 service that may provide additional information about the notice. 494 An exmaple of the notices data structure. 496 "notices" : [ 497 "notice" : { 498 "title" : "Terms of Use", 499 "description" : [ 500 "This service is subject to The Registry of the Moons", 501 "terms of service." 502 ], 503 "uri" : "http://example.com/our-terms-of-use" 504 } 505 ] 507 Figure 10 509 This is an example response with both rdapConformance and notices 510 embedded. 512 { 513 "rdapConformance" : [ 514 "nrrdap_level_0" 515 ] 516 "notices" : [ 517 "notice" : { 518 "title" : "Content Redacted", 519 "description" : [ 520 "Without full authorization, content has been redacted.", 521 "Sorry, dude!" 522 ], 523 "uri" : "http://example.com/our-redaction-policies" 524 } 525 ] 526 "startAddress" : "10.0.0.0", 527 "endAddress" : "10.0.0.255", 528 "remarks" : [ 529 "she sells seas shells", 530 "down by the seashore" 531 ], 532 "uris" : [ 533 { 534 "type" : "source", 535 "uri" : "http://whois-rws.net/network/xxxx" 536 }, 537 { 538 "type" : "parent", 539 "uri" : "http://whois-rws.net/network/yyyy" 540 } 541 ] 542 } 544 Figure 11 546 10. Common Datatypes 548 This section describes common data types found in Internet 549 registries, the purpose being a common and normalized list of 550 normative references to other specifications to be used by multiple 551 RD-AP applications. Unless otherwise stated by the response 552 specification of an Internet registry using this specification as a 553 basis, the data types can assume to be as follows: 555 1. IPv4 addresses - [RFC0791] 557 2. IPv6 addresses - [RFC5952] 559 3. country code - [ISO.3166.1988] 561 4. domain name - [RFC4343] 563 5. email address - [RFC5322] 565 6. date and time strings - [RFC3339] 567 11. IANA Considerations 569 11.1. IANA Registry for RDAP Extensions 571 This specification proposes an IANA registry for RDAP extensions. 572 The purpose of this registry is to ensure uniqueness of extension 573 identifier. The extension identifier is used as prefix in JSON names 574 and as a prefix of path segments in RDAP URLs. 576 The production rule for JSON names in response is specified in 577 Section 6.2. 579 In accordance with RFC5226, the IANA policy for assigning new values 580 shall be Specification Required: values and their meanings must be 581 documented in an RFC or in some other permanent and readily available 582 reference, in sufficient detail that interoperability between 583 independent implementations is possible. 585 The following is a preliminary template for an RDAP extension 586 registration: 588 Extension identifier: the identifier of the extension 590 Registry operator: the name of the registry operator 592 Published specification: RFC number, bibliographical reference or 593 URL to a permenant and readily available specification 595 Person & email address to contact for further information: The 596 names and email addresses of individuals for contact regarding 597 this registry entry 599 Intended usage: brief reasons for this registry entry 601 The following is an example of a regstration in the RDAP extension 602 registry: 604 Extension identifier: lunarNic 606 Registry operator: The Registry of the Moon, LLC 608 Published specification: http://www.example/moon_apis/rdap 610 Person & email address to contact for further information: 611 Professor Bernardo de la Paz 613 Intended usage: COMMON 615 11.2. Registration of RDAP Media Type for JSON 617 This specification registers the "application/rdap+json" media type. 619 Type name: application 621 Subtype name: rdap+json 623 Required parameters: n/a 625 Optional parameters: level 627 Encoding considerations: n/a 629 Security considerations: n/a 631 Interoperability considerations: n/a 633 Published specification: [[ this document ]] 635 Applications that use this media type: RDAP 637 Additional information: n/a 639 Person & email address to contact for further information: Andy 640 Newton &andy@hxr.us& 642 Intended usage: COMMON 644 Restrictions on usage: none 646 Author: Andy Newton 648 Change controller: IETF 650 11.3. Registration of RDAP Media Type for XML 652 This specification registers the "application/rdap+xml" media type. 654 Type name: application 656 Subtype name: rdap+xml 658 Required parameters: n/a 660 Optional parameters: level 661 Encoding considerations: n/a 663 Security considerations: n/a 665 Interoperability considerations: n/a 667 Published specification: [[ this document ]] 669 Applications that use this media type: RDAP 671 Additional information: n/a 673 Person & email address to contact for further information: Andy 674 Newton &andy@hxr.us& 676 Intended usage: COMMON 678 Restrictions on usage: none 680 Author: Andy Newton 682 Change controller: IETF 684 12. Internationalization Considerations 686 12.1. URIs vs IRIs 688 Clients MAY use IRIs as they see fit, but MUST transform them to URIs 689 [RFC3986] for interaction with RD-AP servers. RD-AP servers MUST use 690 URIs in all responses, and clients MAY transform these URIs to IRIs. 692 12.2. Character Encoding 694 The default text encoding for JSON and XML responses in RD-AP is 695 UTF-8, and all servers and clients MUST support UTF-8. Servers and 696 clients MAY optionally support other character encodings. 698 13. Normative References 700 [draft-kucherawy-weirds-requirements] 701 Kucherawy, M., "Requirements For Internet Registry 702 Services", Work in progress: Internet 703 Drafts draft-kucherawy-weirds-requirements-04.txt, 704 April 2011. 706 [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS 707 Terminology and Structure", September 2011. 709 [RFC4627] Crockford, D., "The application/json Media Type for 710 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 712 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 713 Internet: Timestamps", RFC 3339, July 2002. 715 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 716 Rose, "Resource Records for the DNS Security Extensions", 717 RFC 4034, March 2005. 719 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 720 September 1981. 722 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 723 Address Text Representation", RFC 5952, August 2010. 725 [ISO.3166.1988] 726 International Organization for Standardization, "Codes for 727 the representation of names of countries, 3rd edition", 728 ISO Standard 3166, August 1988. 730 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 731 Autonomous System (AS) Numbers", RFC 5396, December 2008. 733 [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 734 Clarification", RFC 4343, January 2006. 736 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 737 Resource Identifier (URI): Generic Syntax", STD 66, 738 RFC 3986, January 2005. 740 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 741 October 2008. 743 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 744 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 745 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 747 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 748 Specifications: ABNF", STD 68, RFC 5234, January 2008. 750 Appendix A. Cache Busting 752 To overcome issues with misbehaving HTTP [RFC2616] cache 753 infrastructure, clients may use the adhoc and improbably used query 754 parameter with a random value of their choosing. As Section 4.2 755 instructs servers to ignore unknown parameters, this is unlikely to 756 have any known side effects. 758 An example of using an unknown query parameter to bust caches: 760 http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123 762 Use of an unknown parameter to overcome misbehaving caches is not 763 part of any specification and is offered here for informational 764 purposes. 766 Appendix B. Changelog 768 Initial WG -00: Updated to working group document 2012-September-20 770 Authors' Addresses 772 Andrew Lee Newton 773 American Registry for Internet Numbers 774 3635 Concorde Parkway 775 Chantilly, VA 20151 776 US 778 Email: andy@arin.net 779 URI: http://www.arin.net 781 Byron J. Ellacott 782 Asia Pacific Network Information Center 783 6 Cordelia Street 784 South Brisbane QLD 4101 785 Australia 787 Email: bje@apnic.net 788 URI: http://www.apnic.net 790 Ning Kong 791 China Internet Network Information Center 792 4 South 4th Street, Zhongguancun, Haidian District 793 Beijing 100190 794 China 796 Phone: +86 10 5881 3147 797 Email: nkong@cnnic.cn