idnits 2.17.1 draft-designteam-weirds-using-http-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security considerations?' ) == 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 182: '... Clients SHOULD put the media type o...' RFC 2119 keyword, line 183: '...eader field, and SHOULD use the Accept...' RFC 2119 keyword, line 190: '... Servers SHOULD respond with an appr...' RFC 2119 keyword, line 192: '... header in HTTP [RFC2616]. Servers SHOULD affix a media type...' RFC 2119 keyword, line 200: '... 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 (July 12, 2012) is 4304 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 681, but no explicit reference was found in the text == Unused Reference: 'RFC5396' is defined on line 696, 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 K. Ranjbar 5 Expires: January 13, 2013 RIPE NCC 6 A. Servin 7 LACNIC 8 B. Ellacott 9 APNIC 10 S. Hollenbeck 11 Verisign 12 S. Sheng 13 F. Arias 14 ICANN 15 N. Kong 16 CNNIC 17 F. Obispo 18 ISC 19 July 12, 2012 21 Using HTTP for RESTful Whois Services by Internet Registries 22 draft-designteam-weirds-using-http-01 24 Abstract 26 This document describes the use of HTTP in Whois services using 27 RESTful web methodologies. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 13, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . . 6 69 5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . . 7 70 5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . . 7 73 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7 74 6. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7. Use of XML . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.2. Naming and Structure . . . . . . . . . . . . . . . . . . . 11 80 8. Common Error Response Body . . . . . . . . . . . . . . . . . . 13 81 9. Common Data Structures . . . . . . . . . . . . . . . . . . . . 14 82 10. Common Datatypes . . . . . . . . . . . . . . . . . . . . . . . 16 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 11.1. Registration of RDAP Error Media Type for JSON . . . . . . 17 85 11.2. Registration of RDAP Error Media Type for XML . . . . . . 17 86 12. Internationalization Considerations . . . . . . . . . . . . . 19 87 12.1. URIs vs IRIs . . . . . . . . . . . . . . . . . . . . . . . 19 88 12.2. Character Encoding . . . . . . . . . . . . . . . . . . . . 19 89 13. Normative References . . . . . . . . . . . . . . . . . . . . . 20 90 Appendix A. Cache Busting . . . . . . . . . . . . . . . . . . . . 22 91 Appendix B. Areas of Improvement . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 96 This document describes the usage of HTTP for Registration Data 97 Directory Services running on RESTful web servers. The goal of this 98 document is to tie together the usage patterns of HTTP into a common 99 profile applicable to the various types of Directory Services serving 100 Registration Data using RESTful styling. By giving the various 101 Directory Services common behavior, a single client is better able to 102 retrieve data from Directory Services adhering to this behavior. 104 In designing these common usage patterns, this draft endeavours to 105 satisfy requirements for Registration Data Access Protocols that are 106 documented in [draft-kucherawy-weirds-requirements]. This draft also 107 introduces an additional design consideration to define a simple use 108 of HTTP. Where complexity may reside, it is the goal of this 109 specification to place it upon the server and to keep the client as 110 simple as possible. A client should be possible using common 111 operating system scripting tools. 113 This is the basic usage pattern for this protocol: 115 1. A client issues an HTTP query using GET. As an example, a query 116 for the network registration 192.168.0.0 might be 117 http://example.com/ip/192.168.0.0. 119 2. If the receiving server has the information for the query, it 120 examines the Accept header field of the query and returns a 200 121 response with a response entity appropriate for the requested 122 format. 124 3. If the receiving server does not have the information for the 125 query but does have knowledge of where the information can be 126 found, it will return a redirection response (3xx) with the 127 Redirect header containing an HTTP URL pointing to the 128 information. The client is expected to re-query using that HTTP 129 URL. 131 4. If the receiving server does not have the information being 132 requested and does not have knowledge of where the information 133 can be found, it should return a 404 response. 135 It is important to note that it is not the intent of this document to 136 redefine the meaning and semantics of HTTP. The purpose of this 137 document is to clarify the use of standard HTTP mechanisms for this 138 application. 140 2. Terminology 142 As is noted in SSAC Report on WHOIS Terminology and Structure 143 [SAC-051], the term "Whois" is overloaded, often referring to a 144 protocol, a service and data. In accordance with [SAC-051], this 145 document describes the base behavior for a Registration Data Access 146 Protocol (RD-AP). At present, there are two known types of RD-AP, a 147 Domain Name Registration Data Access Protocol (DNRD-AP) and a Number 148 Resource Registration Data Access Protocol (NRRD-AP). Both the 149 DNRD-AP and NRRD-AP are to be built upon this base behavior, the 150 RD-AP. 152 Note that other types of RD-AP may exist in the future. 154 3. Design Intents 156 There are a few design criteria this document attempts to support. 158 First, each query is meant to return either zero or one result. With 159 the maximum upper bound being set to one, the issuance of redirects 160 is simplified to the known query/respone model used by HTTP 161 [RFC2616]. Should a result contain more than one result, some of 162 which are better served by other servers, the redirection model 163 becomes much more complicated. 165 Second, multiple response formats are supported by this protocol. 166 This document outlines the base usage of JSON and XML, but server 167 operators may support other formats as they desire if appropriate. 169 Third, HTTP offers a number of transport protocol mechanisms not 170 described further in this document. Operators are able to make use 171 of these mechanisms according to their local policy, including cache 172 control, authorization, compression, and redirection. HTTP also 173 benefits from widespread investment in scalability, reliability, and 174 performance, and widespread programmer understanding of client 175 behaviours for RESTful web services, reducing the cost to deploy 176 Registration Data Directory Services and clients. 178 4. Queries 180 4.1. Accept Header 182 Clients SHOULD put the media type of the format they desire in the 183 Accept header field, and SHOULD use the Accept header parameter 184 "level" to indicate the version of the format acceptable [RFC2616]. 186 Accept: applicaiton/weirds_blah+json;level=0 188 Figure 1 190 Servers SHOULD respond with an appropriate media type in the Content- 191 Type header in accordance with the preference rules for the Accept 192 header in HTTP [RFC2616]. Servers SHOULD affix a media type 193 parameter of "level" appropriate to the version of the format being 194 sent. 196 Content-Type: application/weirds_blah+json;level=0 198 Figure 2 200 Clients MAY use a generic media type for the desired data format of 201 the response (e.g. "application/json"), but servers SHOULD respond 202 with the most appropriate media type and corresponding level (e.g. 203 "application/weirds+json;level=0"). In other words, a client may use 204 "application/json" to express that it desires JSON or "application/ 205 weirds_blah+json" to express that it desires WEIRDS BLAH in JSON. 206 The server MUST respond with "application/weirds_blah+json;level=0". 208 4.2. Query Parameters 210 Servers SHOULD ignore unknown query parameters. Use of unknown query 211 parameters for cache-busting is described in Appendix A. 213 5. Types of HTTP Response 215 This section describes the various types of responses a server may 216 send to a client. While no standard HTTP response code is forbidden 217 in usage, at a minimum clients should understand the response codes 218 described in this section. It is expected that usage of response 219 codes and types for this application not defined here will be 220 described in subsequent documents. 222 5.1. Positive Answers 224 If a server has the information requested by the client and wishes to 225 respond to the client with the information according to its policies, 226 it should encode the answer in the format most appropriate according 227 to the standard and defined rules for processing the HTTP Accept 228 header, and return that answer in the body of a 200 response. 230 5.2. Redirects 232 If a server wishes to inform a client that the answer to a given 233 query can be found elsewhere, it SHOULD return either a 301 or a 307 234 response code and an HTTP URL in the Redirect header. The client is 235 expected to issue a subsequent query using the given URL without any 236 processing of the URL. In other words, the server is to hand back a 237 complete URL and the client should not have to transform the URL to 238 follow it. 240 A server should use a 301 response to inform the client of a 241 permanent move and a 307 response otherwise. For this application, 242 such an example of a permanent move might be a TLD operator informing 243 a client the information being sought can be found with another TLD 244 operator (i.e. a query for the domain bar in foo.example is found at 245 http://foo.example/domain/bar). 247 5.3. Negative Answers 249 If a server wishes to respond that it has no information regarding 250 the query, it SHOULD return a 404 response code. Optionally, it may 251 include additional information regarding the lack of information as 252 defined by Section 8. 254 5.4. Malformed Queries 256 If a server receives a query which it cannot understand, it SHOULD 257 return a 400 response code. Optionally, it may include additional 258 information about why it does not understand the query as defined by 259 Section 8. 261 6. Use of JSON 263 6.1. Signaling 265 Clients may signal their desire for JSON using the "application/json" 266 media type or a more application specific JSON media type. 268 6.2. Naming 270 Clients processing JSON [RFC4627] responses SHOULD ignore values 271 associated with unrecognized names. Servers MAY insert values 272 signified by names into the JSON responses which are not specified in 273 this document. Insertion of unspecified values into JSON responses 274 SHOULD have names prefixed with a short identifier followed by an 275 underscore followed by a meaningful name. 277 For example, a JSON object may have "handle" and "remarks" formally 278 documented in a specification. Clients adhering to that 279 specification will have appropriate knowledge of the meaning of 280 "handle" and "remarks". 282 Consider the following JSON response with JSON names. 284 { 285 "handle" : "ABC123", 286 "remarks" : [ 287 "she sells seas shells", 288 "down by the seashore" 289 ] 290 } 292 Figure 3 294 If The Registry of the Moon desires to express information not found 295 in the specification, it might select "lunarNic" as its identifying 296 prefix and insert, as an example, the name 297 "lunarNic_beforeOneSmallStep" to signify registrations occuring 298 before the first moon landing and the name 299 "lunarNic_harshMistressNotes" containing other descriptive text. 301 Consider the following JSON response with JSON names, some of which 302 should be ignored by clients without knowledge of their meaning. 304 { 305 "handle" : "ABC123", 306 "lunarNic_beforeOneSmallStep" : "TRUE THAT!", 307 "remarks" : [ 308 "she sells seas shells", 309 "down by the seashore" 310 ], 311 "lunarNic_harshMistressNotes" : [ 312 "In space,", 313 "nobody can hear you scream." 314 ] 315 } 317 Figure 4 319 Insertion of unrecognized names ignored by clients may also be used 320 for future revisions to specifications and specifications deriving 321 extensions from a base specification. 323 JSON names SHOULD only consist of the alphabetic ASCII characters A 324 through Z in both uppercase and lowercase, the numerical digits 0 325 through 9, underscore characters, and SHOULD NOT begin with an 326 underscore character, numerical digit or the characters "xml". The 327 following describes the produciton of JSON names in ABNF [RFC5234]. 329 ABNF for JSON names 331 name = ALPHA *( ALPHA / DIGIT / "_" ) 333 Figure 5 335 This restriction is a union of the Ruby programming language 336 identifier syntax and the XML element name syntax and has two 337 purposes. First, client implementers using modern programming 338 languages such as Ruby or Java may use libraries that automatically 339 promote JSON names to first order object attributes or members (e.g. 340 using the example above, the values may be referenced as 341 network.handle or network.lunarNic_beforeOneSmallStep). Second, a 342 clean mapping between JSON and XML is easy to accomplish using the 343 JSON representation. 345 Clients processing JSON responses MUST be prepared for values 346 specified in the registry response documents to be absent from a 347 response as no JSON value listed is required to appear in the 348 response. In other words, servers MAY remove values as is needed by 349 the policies of the server operator. 351 7. Use of XML 353 7.1. Signaling 355 Clients may signal their desire for XML using the "application/xml" 356 media type or a more application specific XML media type. 358 7.2. Naming and Structure 360 Well-formed XML may be programmatically produced using the JSON 361 encodings due to the JSON naming rules outlined in Section 6.2 and 362 the following simple rules: 364 1. Where a JSON name is given, the corresponding XML element has the 365 same name. 367 2. Where a JSON value is found, it is the content of the 368 corresponding XML element. 370 3. Where a JSON value is an array, the XML element is to be repeated 371 for each element of the array. 373 4. The root tag of the XML document is to be "response". 375 Consider the following JSON response. 377 { 378 "startAddress" : "10.0.0.0", 379 "endAddress" : "10.0.0.255", 380 "remarks" : [ 381 "she sells seas shells", 382 "down by the seashore" 383 ], 384 "uris" : [ 385 { 386 "type" : "source", 387 "uri" : "http://whois-rws.net/network/xxxx" 388 }, 389 { 390 "type" : "parent", 391 "uri" : "http://whois-rws.net/network/yyyy" 392 } 393 ] 394 } 396 Figure 6 398 The corresponding XML would look like this: 400 401 10.0.0.0 402 10.0.0.255 403 She sells sea shells 404 down by the seashore 405 406 source 407 http://whois-rws.net/network/xxxx 408 409 410 parent 411 http://whois-rws.net/network/yyyy 412 413 415 JSON values converted to XML element content MUST be properly 416 escaped. XML offers various means for escaping data, but such 417 escaping MUST account for the '<', '>', and '&' characters and MUST 418 redact all C0 control characters except tab, carriage return, and 419 new-line. (Redaction of disallowed control characters is a protocol 420 requirement, though in practice most Internet registries do not allow 421 this data in their data stores and therefore do not need to account 422 for this rule.) 424 The rules for clients processing XML responses are the same as those 425 with JSON: clients SHOULD ignore unrecognized XML elements, and 426 servers MAY insert XML elements with tag names according to the 427 naming rules in Section 6.2. And as with JSON, clients MUST be 428 prepared for XML elements specified in the registry response 429 documents to be absent from a response as no XML element listed is 430 required to appear in the response. 432 8. Common Error Response Body 434 As specified in Section 5, some non-answer responses may return 435 entity bodies with information that could be more descriptive. 437 The basic structure of that response is a data class containing an 438 error code number (corresponding to the HTTP response code) followed 439 by a string named "title" followed by an array of strings named 440 "description". 442 This is an example of the JSON version of the common response body. 444 { 445 "errorCode": 418 446 "title": "Your beverage choice is not available", 447 "description": [ 448 "I know coffee has more ummppphhh.", 449 "But I cannot provide." ] 450 } 452 Figure 7 454 This is an example of the XML version of the common response body. 456 457 418 458 Your beverage choice is not available 459 I know coffee has more ummppphhh. 460 But I cannot provide. 461 463 Figure 8 465 The media type for the JSON structure is "application/ 466 rdap_error+json" and the media type for the XML document is 467 "application/rdap_error+xml". Conformance to this specification is 468 considered to be level 0 for both media types. 470 A client MAY simply use the HTTP response code as the server is not 471 required to include error data in the response body. However, if a 472 client wishes to parse the error data, it SHOULD first check that the 473 Content-Type header contains the appropriate media type. 475 9. Common Data Structures 477 This section defines two common data structures to be used by 478 DNRD-AP, NRRD-AP, and other RD-AP protocols. As such, the names 479 identifying these data structures are not to be redefined by any 480 registry specific RD-AP specifications. Each of these datatypes MAY 481 appear within any other data object of a response, but the intended 482 purpose is that they will be mostly used in the top-most data object 483 of a response. 485 The first data structure is named "rdapConformance" and is simply an 486 array of strings, each providing a hint as to the specifications used 487 in the construction of the response. 489 An example rdapConformance data structure. 491 "rdapConformance" : [ 492 "nrrdap_level_0" 493 ] 495 Figure 9 497 The second data structure is named "notices" and is an array of 498 "notice" objects. Each "notice" object contains a "title" string 499 representing the title of the notice object, an array of strings 500 named "description" for the purposes of conveying any descriptive 501 text about the notice, and a "uri" string holding a URI referencing a 502 service that may provide additional information about the notice. 504 An exmaple of the notices data structure. 506 "notices" : [ 507 "notice" : { 508 "title" : "Terms of Use", 509 "description" : [ 510 "This service is subject to The Registry of the Moons", 511 "terms of service." 512 ], 513 "uri" : "http://example.com/our-terms-of-use" 514 } 515 ] 517 Figure 10 519 This is an example response with both rdapConformance and notices 520 embedded. 522 { 523 "rdapConformance" : [ 524 "nrrdap_level_0" 525 ] 526 "notices" : [ 527 "notice" : { 528 "title" : "Content Redacted", 529 "description" : [ 530 "Without full authorization, content has been redacted.", 531 "Sorry, dude!" 532 ], 533 "uri" : "http://example.com/our-redaction-policies" 534 } 535 ] 536 "startAddress" : "10.0.0.0", 537 "endAddress" : "10.0.0.255", 538 "remarks" : [ 539 "she sells seas shells", 540 "down by the seashore" 541 ], 542 "uris" : [ 543 { 544 "type" : "source", 545 "uri" : "http://whois-rws.net/network/xxxx" 546 }, 547 { 548 "type" : "parent", 549 "uri" : "http://whois-rws.net/network/yyyy" 550 } 551 ] 552 } 554 Figure 11 556 10. Common Datatypes 558 This section describes common data types found in Internet 559 registries, the purpose being a common and normalized list of 560 normative references to other specifications to be used by multiple 561 RD-AP applications. Unless otherwise stated by the response 562 specification of an Internet registry using this specification as a 563 basis, the data types can assume to be as follows: 565 1. IPv4 addresses - [RFC0791] 567 2. IPv6 addresses - [RFC5952] 569 3. country code - [ISO.3166.1988] 571 4. domain name - [RFC4343] 573 5. email address - [RFC5322] 575 6. date and time strings - [RFC3339] 577 11. IANA Considerations 579 11.1. Registration of RDAP Error Media Type for JSON 581 This specification registers the "application/rdap_error+json" media 582 type. 584 Type name: application 586 Subtype name: rdap_error+json 588 Required parameters: n/a 590 Optional parameters: level 592 Encoding considerations: n/a 594 Security considerations: n/a 596 Interoperability considerations: n/a 598 Published specification: [[ this document ]] 600 Applications that use this media type: RESTful Whois applications 602 Additional information: n/a 604 Person & email address to contact for further information: Andy 605 Newton &andy@hxr.us& 607 Intended usage: COMMON 609 Restrictions on usage: none 611 Author: Andy Newton 613 Change controller: IETF 615 11.2. Registration of RDAP Error Media Type for XML 617 This specification registers the "application/rdap_error+xml" media 618 type. 620 Type name: application 622 Subtype name: rdap_error+xml 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: RESTful Whois applications 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 12. Internationalization Considerations 652 12.1. URIs vs IRIs 654 Clients MAY use IRIs as they see fit, but MUST transform them to URIs 655 [RFC3986] for interaction with RD-AP servers. RD-AP servers MUST use 656 URIs in all responses, and clients MAY transform these URIs to IRIs. 658 12.2. Character Encoding 660 The default text encoding for JSON and XML responses in RD-AP is 661 UTF-8, and all servers and clients MUST support UTF-8. Servers and 662 clients MAY optionally support other character encodings. 664 13. Normative References 666 [draft-kucherawy-weirds-requirements] 667 Kucherawy, M., "Requirements For Internet Registry 668 Services", Work in progress: Internet 669 Drafts draft-kucherawy-weirds-requirements-04.txt, 670 April 2011. 672 [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS 673 Terminology and Structure", September 2011. 675 [RFC4627] Crockford, D., "The application/json Media Type for 676 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 678 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 679 Internet: Timestamps", RFC 3339, July 2002. 681 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 682 Rose, "Resource Records for the DNS Security Extensions", 683 RFC 4034, March 2005. 685 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 686 September 1981. 688 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 689 Address Text Representation", RFC 5952, August 2010. 691 [ISO.3166.1988] 692 International Organization for Standardization, "Codes for 693 the representation of names of countries, 3rd edition", 694 ISO Standard 3166, August 1988. 696 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 697 Autonomous System (AS) Numbers", RFC 5396, December 2008. 699 [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 700 Clarification", RFC 4343, January 2006. 702 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 703 Resource Identifier (URI): Generic Syntax", STD 66, 704 RFC 3986, January 2005. 706 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 707 October 2008. 709 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 710 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 711 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 713 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 714 Specifications: ABNF", STD 68, RFC 5234, January 2008. 716 Appendix A. Cache Busting 718 To overcome issues with misbehaving HTTP [RFC2616] cache 719 infrastructure, clients may use the adhoc and improbably used query 720 parameter with a random value of their choosing. As Section 4.2 721 instructs servers to ignore unknown parameters, this is unlikely to 722 have any known side effects. 724 An example of using an unknown query parameter to bust caches: 726 http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123 728 Use of an unknown parameter to overcome misbehaving caches is not 729 part of any specification and is offered here for informational 730 purposes. 732 Appendix B. Areas of Improvement 734 Things that need to be done to this draft. 736 1. authentication what? 738 2. clean up must should, ref 2119? 740 3. better language on data formats... it was just a rough start 742 4. Security considerations? 744 5. Is there a privacy considerations things we have to do now? 746 Authors' Addresses 748 Andrew Lee Newton 749 American Registry for Internet Numbers 750 3635 Concorde Parkway 751 Chantilly, VA 20151 752 US 754 Email: andy@arin.net 755 URI: http://www.arin.net 757 Kaveh Ranjbar 758 RIPE Network Coordination Centre 759 Singel 258 760 Amsterdam 1016AB 761 NL 763 Email: kranjbar@ripe.net 764 URI: http://www.ripe.net 766 Arturo L. Servin 767 Latin American and Caribbean Internet Address Registry 768 Rambla Republica de Mexico 6125 769 Montevideo 11300 770 UY 772 Email: aservin@lacnic.net 773 URI: http://www.lacnic.net 775 Byron J. Ellacott 776 Asia Pacific Network Information Center 777 6 Cordelia Street 778 South Brisbane QLD 4101 779 Australia 781 Email: bje@apnic.net 782 URI: http://www.apnic.net 783 Scott Hollenbeck 784 Verisign Labs 785 12061 Bluemont Way 786 Reston, VA 20190 787 US 789 Email: shollenbeck@verisign.com 790 URI: http://www.verisignlabs.com/ 792 Steve Sheng 793 Internet Corporation for Assigned Names and Numbers 794 4676 Admiralty Way, Suite 330 795 Marina del Rey, CA 90292 796 United States of America 798 Phone: +1.310.823.9358 799 Email: steve.sheng@icann.org 801 Francisco Arias 802 Internet Corporation for Assigned Names and Numbers 803 4676 Admiralty Way, Suite 330 804 Marina del Rey, CA 90292 805 United States of America 807 Phone: +1.310.823.9358 808 Email: francisco.arias@icann.org 810 Ning Kong 811 China Internet Network Information Center 812 4 South 4th Street, Zhongguancun, Haidian District 813 Beijing 100190 814 China 816 Phone: +86 10 5881 3147 817 Email: nkong@cnnic.cn 818 Francisco Obispo 819 Internet Systems Consortium 820 950 Charter St 821 Redwood City, CA 94063 822 United States of America 824 Phone: +1.650.423.1374 825 Email: fobispo@isc.org