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