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