doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7480.txt b/doc/rfc/rfc7480.txt
new file mode 100644
index 0000000..3af24c5
--- /dev/null
+++ b/doc/rfc/rfc7480.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Newton
+Request for Comments: 7480                                          ARIN
+Category: Standards Track                                    B. Ellacott
+ISSN: 2070-1721                                                    APNIC
+                                                                 N. Kong
+                                                                   CNNIC
+                                                              March 2015
+
+
+       HTTP Usage in the Registration Data Access Protocol (RDAP)
+
+Abstract
+
+   This document is one of a collection that together describes the
+   Registration Data Access Protocol (RDAP).  It describes how RDAP is
+   transported using the Hypertext Transfer Protocol (HTTP).  RDAP is a
+   successor protocol to the very old WHOIS protocol.  The purpose of
+   this document is to clarify the use of standard HTTP mechanisms for
+   this application.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7480.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Newton, et al.               Standards Track                    [Page 1]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Design Intents  . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Queries . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.1.  HTTP Methods  . . . . . . . . . . . . . . . . . . . . . .   5
+     4.2.  Accept Header . . . . . . . . . . . . . . . . . . . . . .   5
+     4.3.  Query Parameters  . . . . . . . . . . . . . . . . . . . .   6
+   5.  Types of HTTP Response  . . . . . . . . . . . . . . . . . . .   6
+     5.1.  Positive Answers  . . . . . . . . . . . . . . . . . . . .   6
+     5.2.  Redirects . . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.3.  Negative Answers  . . . . . . . . . . . . . . . . . . . .   7
+     5.4.  Malformed Queries . . . . . . . . . . . . . . . . . . . .   7
+     5.5.  Rate Limits . . . . . . . . . . . . . . . . . . . . . . .   7
+     5.6.  Cross-Origin Resource Sharing (CORS)  . . . . . . . . . .   8
+   6.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .   8
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+     8.1.  RDAP Extensions Registry  . . . . . . . . . . . . . . . .   9
+   9.  Internationalization Considerations . . . . . . . . . . . . .  10
+     9.1.  URIs and IRIs . . . . . . . . . . . . . . . . . . . . . .  10
+     9.2.  Language Identifiers in Queries and Responses . . . . . .  10
+     9.3.  Language Identifiers in HTTP Headers  . . . . . . . . . .  10
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
+   Appendix A.  Protocol Example . . . . . . . . . . . . . . . . . .  13
+   Appendix B.  Cache Busting  . . . . . . . . . . . . . . . . . . .  13
+   Appendix C.  Bootstrapping and Redirection  . . . . . . . . . . .  14
+   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton, et al.               Standards Track                    [Page 2]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+1.  Introduction
+
+   This document describes the usage of the Hypertext Transfer Protocol
+   (HTTP) [RFC7230] for the Registration Data Access Protocol (RDAP).
+   The goal of this document is to tie together usage patterns of HTTP
+   into a common profile applicable to the various types of directory
+   services serving registration data using practices informed by the
+   Representational State Transfer (REST) [REST] architectural style.
+   By giving the various directory services common behavior, a single
+   client is better able to retrieve data from directory services
+   adhering to this behavior.
+
+   Registration data expected to be presented by this service is
+   Internet resource registration data -- registration of domain names
+   and Internet number resources.  This data is typically provided by
+   WHOIS [RFC3912] services, but the WHOIS protocol is insufficient to
+   modern registration data service requirements.  A replacement
+   protocol is expected to retain the simple transactional nature of
+   WHOIS, while providing a specification for queries and responses,
+   redirection to authoritative sources, support for Internationalized
+   Domain Names (IDNs) [RFC5890], and support for localized registration
+   data such as addresses and organization or person names.
+
+   In designing these common usage patterns, this document introduces
+   considerations for a simple use of HTTP.  Where complexity may
+   reside, it is the goal of this document to place it upon the server
+   and to keep the client as simple as possible.  A client
+   implementation should be possible using common operating system
+   scripting tools (e.g., bash and wget).
+
+   This is the basic usage pattern for this protocol:
+
+   1.  A client determines an appropriate server to query along with the
+       appropriate base Uniform Resource Locator (URL) to use in such
+       queries.  [RFC7484] describes one method to determine the server
+       and the base URL.  See Appendix C for more information.
+
+   2.  A client issues an HTTP (or HTTPS) query using GET [RFC7231].  As
+       an example, a query URL for the network registration 192.0.2.0
+       might be
+
+          http://example.com/rdap/ip/192.0.2.0
+
+       [RFC7482] details the various queries used in RDAP.
+
+
+
+
+
+
+
+Newton, et al.               Standards Track                    [Page 3]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   3.  If the receiving server has the information for the query, it
+       examines the Accept header field of the query and returns a 200
+       response with a response entity appropriate for the requested
+       format.  [RFC7483] details a response in JavaScript Object
+       Notation (JSON).
+
+   4.  If the receiving server does not have the information for the
+       query but does have knowledge of where the information can be
+       found, it will return a redirection response (3xx) with the
+       Location header field containing an HTTP(S) URL pointing to the
+       information or another server known to have knowledge of the
+       location of the information.  The client is expected to requery
+       using that HTTP URL.
+
+   5.  If the receiving server does not have the information being
+       requested and does not have knowledge of where the information
+       can be found, it returns a 404 response.
+
+   6.  If the receiving server will not answer a request for policy
+       reasons, it will return an error response (4xx) indicating the
+       reason for giving no answer.
+
+   It is not the intent of this document to redefine the meaning and
+   semantics of HTTP.  The purpose of this document is to clarify the
+   use of standard HTTP mechanisms for this application.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   As is noted in "Security and Stability Advisory Committee (SSAC)
+   Report on WHOIS Terminology and Structure" [SAC-051], the term
+   "WHOIS" is overloaded, often referring to a protocol, a service, and
+   data.  In accordance with [SAC-051], this document describes the base
+   behavior for an RDAP.  [SAC-051] describes a protocol profile of RDAP
+   for Domain Name Registries (DNRs), the Domain Name Registration Data
+   Access Protocol (DNRD-AP).
+
+   In this document, an RDAP client is an HTTP user agent performing an
+   RDAP query, and an RDAP server is an HTTP server providing an RDAP
+   response.  RDAP query and response formats are described in [RFC7482]
+   and [RFC7483], while this document describes how RDAP clients and
+   servers use HTTP to exchange queries and responses.  [RFC7481]
+   describes security considerations for RDAP.
+
+
+
+
+
+Newton, et al.               Standards Track                    [Page 4]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+3.  Design Intents
+
+   There are a few design criteria this document attempts to meet.
+
+   First, each query is meant to require only one path of execution to
+   obtain an answer.  A response may contain an answer, no answer, or a
+   redirect, and clients are not expected to fork multiple paths of
+   execution to make a query.
+
+   Second, the semantics of the request/response allow for future and/or
+   non-standard response formats.  In this document, only a JSON
+   [RFC7159] response media type is noted, with the response contents to
+   be described separately (see [RFC7483]).  This document only
+   describes how RDAP is transported using HTTP with this format.
+
+   Third, this protocol is intended to be able to make use of the range
+   of mechanisms available for use with HTTP.  HTTP offers a number of
+   mechanisms not described further in this document.  Operators are
+   able to make use of these mechanisms according to their local policy,
+   including cache control, authorization, compression, and redirection.
+   HTTP also benefits from widespread investment in scalability,
+   reliability, and performance, as well as widespread programmer
+   understanding of client behaviors for web services styled after REST
+   [REST], reducing the cost to deploy Registration Data Directory
+   Services and clients.  This protocol is forward compatible with HTTP
+   2.0.
+
+4.  Queries
+
+4.1.  HTTP Methods
+
+   Clients use the GET method to retrieve a response body and use the
+   HEAD method to determine existence of data on the server.  Clients
+   SHOULD use either the HTTP GET or HEAD methods (see [RFC7231]).
+   Servers are under no obligation to support other HTTP methods;
+   therefore, clients using other methods will likely not interoperate
+   properly.
+
+   Clients and servers MUST support HTTPS to support security services.
+
+4.2.  Accept Header
+
+   To indicate to servers that an RDAP response is desired, clients
+   include an Accept header field with an RDAP-specific JSON media type,
+   the generic JSON media type, or both.  Servers receiving an RDAP
+   request return an entity with a Content-Type header containing the
+   RDAP-specific JSON media type.
+
+
+
+
+Newton, et al.               Standards Track                    [Page 5]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   This specification does not define the responses a server returns to
+   a request with any other media types in the Accept header field, or
+   with no Accept header field.  One possibility would be to return a
+   response in a media type suitable for rendering in a web browser.
+
+4.3.  Query Parameters
+
+   Servers MUST ignore unknown query parameters.  Use of unknown query
+   parameters for cache busting is described in Appendix B.
+
+5.  Types of HTTP Response
+
+   This section describes the various types of responses a server may
+   send to a client.  While no standard HTTP response code is forbidden
+   in usage, this section defines the minimal set of response codes in
+   common use by servers that a client will need to understand.  While
+   some clients may be constructed with simple tooling that does not
+   account for all of these response codes, a more robust client
+   accounting for these codes will likely provide a better user
+   experience.  It is expected that usage of response codes and types
+   for this application not defined here will be described in subsequent
+   documents.
+
+5.1.  Positive Answers
+
+   If a server has the information requested by the client and wishes to
+   respond to the client with the information according to its policies,
+   it returns that answer in the body of a 200 (OK) response (see
+   [RFC7231]).
+
+5.2.  Redirects
+
+   If a server wishes to inform a client that the answer to a given
+   query can be found elsewhere, it returns either a 301 (Moved
+   Permanently) response code to indicate a permanent move or a 302
+   (Found), 303 (See Other), or 307 (Temporary Redirect) response code
+   to indicate a non-permanent redirection, and it includes an HTTP(S)
+   URL in the Location header field (see [RFC7231]).  The client is
+   expected to issue a subsequent request to satisfy the original query
+   using the given URL without any processing of the URL.  In other
+   words, the server is to hand back a complete URL, and the client
+   should not have to transform the URL to follow it.  Servers are under
+   no obligation to return a URL conformant to [RFC7482].
+
+   For this application, such an example of a permanent move might be a
+   Top-Level Domain (TLD) operator informing a client the information
+
+
+
+
+
+Newton, et al.               Standards Track                    [Page 6]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   being sought can be found with another TLD operator (i.e., a query
+   for the domain bar in foo.example is found at
+   http://foo.example/domain/bar).
+
+   For example, if the client uses
+
+      http://serv1.example.com/weirds/domain/example.com
+
+   the server redirecting to
+
+      https://serv2.example.net/weirds2/
+
+   would set the Location: field to the value
+
+      https://serv2.example.net/weirds2/domain/example.com
+
+5.3.  Negative Answers
+
+   If a server wishes to respond that it has an empty result set (that
+   is, no data appropriately satisfying the query), it returns a 404
+   (Not Found) response code.  Optionally, it MAY include additional
+   information regarding the negative answer in the HTTP entity body.
+
+   If a server wishes to inform the client that information about the
+   query is available, but cannot include the information in the
+   response to the client for policy reasons, the server MUST respond
+   with an appropriate response code out of HTTP's 4xx range.  A client
+   MAY retry the query if that is appropriate for the respective
+   response code.
+
+5.4.  Malformed Queries
+
+   If a server receives a query that it cannot interpret as an RDAP
+   query, it returns a 400 (Bad Request) response code.  Optionally, it
+   MAY include additional information regarding this negative answer in
+   the HTTP entity body.
+
+5.5.  Rate Limits
+
+   Some servers apply rate limits to deter address scraping and other
+   abuses.  When a server declines to answer a query due to rate limits,
+   it returns a 429 (Too Many Requests) response code as described in
+   [RFC6585].  A client that receives a 429 response SHOULD decrease its
+   query rate and honor the Retry-After header field if one is present.
+   Servers may place stricter limits upon clients that do not honor the
+   Retry-After header.  Optionally, the server MAY include additional
+   information regarding the rate limiting in the HTTP entity body.
+
+
+
+
+Newton, et al.               Standards Track                    [Page 7]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   Note that this is not a defense against denial-of-service (DoS)
+   attacks, since a malicious client could ignore the code and continue
+   to send queries at a high rate.  A server might use another response
+   code if it did not wish to reveal to a client that rate limiting is
+   the reason for the denial of a reply.
+
+5.6.  Cross-Origin Resource Sharing (CORS)
+
+   When responding to queries, it is RECOMMENDED that servers use the
+   Access-Control-Allow-Origin header field, as specified by
+   [W3C.REC-cors-20140116].  A value of "*" is suitable when RDAP is
+   used for public resources.
+
+   This header (often called the CORS header) helps in-browser web
+   applications by lifting the "same-origin" restriction (i.e., a
+   browser may load RDAP client code from one web server but query
+   others for RDAP data).
+
+   By default, browsers do not send cookies when cross origin requests
+   are allowed.  Setting the Access-Control-Allow-Credentials header
+   field to "true" will send cookies.  Use of the
+   Access-Control-Allow-Credentials header field is NOT RECOMMENDED.
+
+6.  Extensibility
+
+   For extensibility purposes, this document defines an IANA registry
+   for prefixes used in JSON [RFC7159] data serialization and URI path
+   segments (see Section 8).
+
+   Prefixes and identifiers SHOULD only consist of the alphabetic US-
+   ASCII characters A through Z in both uppercase and lowercase, the
+   numerical digits 0 through 9, and the underscore character, and they
+   SHOULD NOT begin with an underscore character, numerical digit, or
+   the characters "xml".  The following describes the production of JSON
+   names in ABNF [RFC5234].
+
+     name = ALPHA *( ALPHA / DIGIT / "_" )
+
+                       Figure 1: ABNF for JSON Names
+
+   This restriction is a union of the Ruby programming language
+   identifier syntax and the XML element name syntax and has two
+   purposes.  First, client implementers using modern programming
+   languages such as Ruby or Java can use libraries that automatically
+   promote JSON names to first-order object attributes or members.
+   Second, a clean mapping between JSON and XML is easy to accomplish
+   using these rules.
+
+
+
+
+Newton, et al.               Standards Track                    [Page 8]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+7.  Security Considerations
+
+   This document does not pose strong security requirements to the RDAP
+   protocol.  However, it does not restrict against the use of security
+   mechanisms offered by the HTTP protocol.  It does require that RDAP
+   clients and servers MUST support HTTPS.
+
+   This document makes recommendations for server implementations
+   against DoS (Section 5.5) and interoperability with existing security
+   mechanisms in HTTP clients (Section 5.6).
+
+   Additional security considerations to the RDAP protocol are covered
+   in [RFC7481].
+
+8.  IANA Considerations
+
+8.1.  RDAP Extensions Registry
+
+   IANA has created a new category in the protocol registries labeled
+   "Registration Data Access Protocol (RDAP)", and within that category,
+   has established a URL-referenceable, stand-alone registry labeled
+   "RDAP Extensions".  The purpose of this registry is to ensure
+   uniqueness of extension identifiers.  The extension identifier is
+   used as a prefix in JSON names and as a prefix of path segments in
+   RDAP URLs.
+
+   The production rule for these identifiers is specified in Section 6.
+
+   In accordance with [RFC5226], the IANA policy for assigning new
+   values, shall be Specification Required: values and their meanings
+   must be documented in an RFC or in some other permanent and readily
+   available reference, in sufficient detail that interoperability
+   between independent implementations is possible.
+
+   The following is a template for an RDAP extension registration:
+
+      Extension identifier: the identifier of the extension
+
+      Registry operator: the name of the registry operator
+
+      Published specification: RFC number, bibliographical reference, or
+      URL to a permanent and readily available specification
+
+      Person & email address to contact for further information: The
+      names and email addresses of individuals to contact regarding this
+      registry entry
+
+
+
+
+
+Newton, et al.               Standards Track                    [Page 9]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+      Intended usage: brief reasons for this registry entry (as defined
+      by [RFC5226]).
+
+   The following is an example of a registration in the RDAP extension
+   registry:
+
+      Extension identifier: lunarNic
+
+      Registry operator: The Registry of the Moon, LLC
+
+      Published specification: http://www.example/moon_apis/rdap
+
+      Person & email address to contact for further information:
+      Professor Bernardo de la Paz <berny@moon.example>
+
+      Intended usage: COMMON
+
+9.  Internationalization Considerations
+
+9.1.  URIs and IRIs
+
+   Clients can use Internationalized Resource Identifiers (IRIs)
+   [RFC3987] for internal use as they see fit but MUST transform them to
+   URIs [RFC3986] for interaction with RDAP servers.  RDAP servers MUST
+   use URIs in all responses, and again clients can transform these URIs
+   to IRIs for internal use as they see fit.
+
+9.2.  Language Identifiers in Queries and Responses
+
+   Under most scenarios, clients requesting data will not signal that
+   the data be returned in a particular language or script.  On the
+   other hand, when servers return data and have knowledge that the data
+   is in a language or script, the data SHOULD be annotated with
+   language identifiers whenever they are available, thus allowing
+   clients to process and display the data accordingly.
+
+   [RFC7483] provides such a mechanism.
+
+9.3.  Language Identifiers in HTTP Headers
+
+   Given the description of the use of language identifiers in
+   Section 9.2, unless otherwise specified, servers SHOULD ignore the
+   HTTP [RFC7231] Accept-Language header field when formulating HTTP
+   entity responses, so that clients do not conflate the Accept-Language
+   header with the 'lang' values in the entity body.
+
+
+
+
+
+
+Newton, et al.               Standards Track                   [Page 10]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   However, servers MAY return language identifiers in the Content-
+   Language header field so as to inform clients of the intended
+   language of HTTP layer messages.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
+              Identifiers (IRIs)", RFC 3987, January 2005,
+              <http://www.rfc-editor.org/info/rfc3987>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6585]  Nottingham, M. and R. Fielding, "Additional HTTP Status
+              Codes", RFC 6585, April 2012,
+              <http://www.rfc-editor.org/info/rfc6585>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing", RFC
+              7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+              June 2014, <http://www.rfc-editor.org/info/rfc7231>.
+
+   [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the
+              Registration Data Access Protocol (RDAP)", RFC 7481,
+              February 2015, <http://www.rfc-editor.org/info/rfc7481>.
+
+   [RFC7482]  Newton, A. and S. Hollenbeck, "Registration Data Access
+              Protocol (RDAP) Query Format", RFC 7482, February 2015,
+              <http://www.rfc-editor.org/info/rfc7482>.
+
+   [RFC7483]  Newton, A. and S. Hollenbeck, "JSON Responses for the
+              Registration Data Access Protocol (RDAP)", RFC 7483,
+              February 2015, <http://www.rfc-editor.org/info/rfc7483>.
+
+
+
+Newton, et al.               Standards Track                   [Page 11]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   [RFC7484]  Blanchet, M., "Finding the Authoritative Registration Data
+              (RDAP) Service", RFC 7484, February 2015,
+              <http://www.rfc-editor.org/info/rfc7484>.
+
+   [W3C.REC-cors-20140116]
+              Kesteren, A., "Cross-Origin Resource Sharing", W3C
+              Recommendation, REC-cors-20140116, January 2014,
+              <http://www.w3.org/TR/2014/REC-cors-20140116/>.
+
+10.2.  Informative References
+
+   [REST]     Fielding, R. and R. Taylor, "Principled Design of the
+              Modern Web Architecture", ACM Transactions on Internet
+              Technology, Vol. 2, No. 2, May 2002.
+
+   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
+              September 2004, <http://www.rfc-editor.org/info/rfc3912>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, August 2010,
+              <http://www.rfc-editor.org/info/rfc5890>.
+
+   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, March 2014,
+              <http://www.rfc-editor.org/info/rfc7159>.
+
+   [SAC-051]  Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS
+              Terminology and Structure", A report from the ICANN
+              Security and Stability Advisory Committee (SSAC),
+              September 2011.
+
+   [lacnic-joint-whois]
+              LACNIC, "Joint Whois", December 2005,
+              <ftp://anonymous@ftp.registro.br/pub/gter/
+              gter20/02-jwhois-lacnic.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+Newton, et al.               Standards Track                   [Page 12]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+Appendix A.  Protocol Example
+
+   To demonstrate typical behavior of an RDAP client and server, the
+   following is an example of an exchange, including a redirect.  The
+   data in the response has been elided for brevity, as the data format
+   is not described in this document.  The media type used here is
+   described in [RFC7483].
+
+   An example of an RDAP client and server exchange:
+
+     Client:
+         <TCP connect to rdap.example.com port 80>
+         GET /rdap/ip/203.0.113.0/24 HTTP/1.1
+         Host: rdap.example.com
+         Accept: application/rdap+json
+
+     rdap.example.com:
+         HTTP/1.1 301 Moved Permanently
+         Location: http://rdap-ip.example.com/rdap/ip/203.0.113.0/24
+         Content-Length: 0
+         Content-Type: application/rdap+json
+         <TCP disconnect>
+
+     Client:
+         <TCP connect to rdap-ip.example.com port 80>
+         GET /rdap/ip/203.0.113.0/24 HTTP/1.1
+         Host:  rdap-ip.example.com
+         Accept: application/rdap+json
+
+     rdap-ip.example.com:
+         HTTP/1.1 200 OK
+         Content-Type: application/rdap+json
+         Content-Length: 9001
+
+         { ... }
+         <TCP disconnect>
+
+Appendix B.  Cache Busting
+
+   Some HTTP [RFC7230] cache infrastructures do not adhere to caching
+   standards adequately and could cache responses longer than is
+   intended by the server.  To overcome these issues, clients can use an
+   ad hoc and improbably used query parameter with a random value of
+   their choosing.  As Section 4.3 instructs servers to ignore unknown
+   parameters, this is compatible with the RDAP definition.
+
+
+
+
+
+
+Newton, et al.               Standards Track                   [Page 13]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   An example of using an unknown query parameter to bust caches:
+
+     http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123
+
+   Use of an unknown parameter to overcome misbehaving caches is not
+   part of any specification and is offered here for informational
+   purposes.
+
+Appendix C.  Bootstrapping and Redirection
+
+   The traditional deployment model of WHOIS [RFC3912] does not provide
+   a mechanism for determining the authoritative source for information.
+
+   Some approaches have been implemented in the past, most notably the
+   Joint WHOIS [lacnic-joint-whois] initiative.  However, among other
+   shortcomings, Joint WHOIS is implemented using proxies and server-
+   side referrals.
+
+   These issues are solved in RDAP using HTTP redirects and
+   bootstrapping.  Bootstrapping is discussed in [RFC7484].  In
+   constrained environments, the processes outlined in [RFC7484] may not
+   be viable, and there may be the need for servers acting as a
+   "redirector".
+
+   Redirector servers issue HTTP redirects to clients using a
+   redirection table informed by [RFC7484].  Figure 2 diagrams a client
+   using a redirector for bootstrapping.
+
+                                      REDIRECTOR       ARIN
+                                      RDAP             RDAP
+                                        .               .
+                                        |               |
+        Q: 23.1.1.1? -----------------> |               |
+                                        |               |
+           <---------- HTTP 301 --------|               |
+                  ('Try ARIN RDAP')     |               |
+                                        |               |
+                                                        |
+          Q: 23.1.1.1? -------------------------------> |
+                                                        |
+             <---------- HTTP 200 --------------------- |
+                    (JSON response is returned)         |
+                                                        |
+                                                        |
+                                                        .
+
+                 Figure 2: Querying RDAP Data for 23.1.1.1
+
+
+
+
+Newton, et al.               Standards Track                   [Page 14]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   In some cases, particularly sub-delegations made between Regional
+   Internet Registries (RIRs) known as "ERX space" and transfers of
+   networks, multiple HTTP redirects will be issued.  Figure 3 shows
+   such a scenario.
+
+                          REDIRECTOR  LACNIC           ARIN
+                          RDAP        RDAP             RDAP
+                            .           .               .
+        Q: 23.1.1.1? ---->  |           |               |
+                            |           |               |
+          <-- HTTP 301 ---  |           |               |
+         ('Try LACNIC')     |           |               |
+                            |           |               |
+                            |           |               |
+        Q: 23.1.1.1? -----------------> |               |
+                                        |               |
+           <---------- HTTP 301 --------|               |
+                  ('Try ARIN RDAP')     |               |
+                                        |               |
+                                                        |
+          Q: 23.1.1.1? -------------------------------> |
+                                                        |
+             <---------- HTTP 200 --------------------- |
+                    (JSON response is returned)         |
+                                                        |
+                                                        |
+                                                        .
+
+      Figure 3: Querying RDAP Data for Data That Has Been Transferred
+
+Acknowledgements
+
+   John Levine provided text to tighten up the Accept header field usage
+   and the text for the section on 429 responses.
+
+   Marc Blanchet provided some clarifying text regarding the use of URLs
+   with redirects, as well as very useful feedback during Working Group
+   Last Call (WGLC).
+
+   Normative language reviews were provided by Murray S. Kucherawy,
+   Andrew Sullivan, Tom Harrison, Ed Lewis, and Alexander Mayrhofer.
+
+   Jean-Phillipe Dionne provided text for the Security Considerations
+   section.
+
+   The concept of the redirector server informatively discussed in
+   Appendix C was documented by Carlos M.  Martinez and Gerardo Rada of
+
+
+
+
+Newton, et al.               Standards Track                   [Page 15]
+
+RFC 7480                     RDAP over HTTP                   March 2015
+
+
+   LACNIC and Linlin Zhou of CNNIC and subsequently incorporated into
+   this document.
+
+   This document is the work product of the IETF's WEIRDS working group,
+   of which Olaf Kolkman and Murray Kucherawy were chairs.
+
+Authors' Addresses
+
+   Andrew Lee Newton
+   American Registry for Internet Numbers
+   3635 Concorde Parkway
+   Chantilly, VA  20151
+   United States
+
+   EMail: andy@arin.net
+   URI:   http://www.arin.net
+
+
+   Byron J. Ellacott
+   Asia Pacific Network Information Centre
+   6 Cordelia Street
+   South Brisbane  QLD 4101
+   Australia
+
+   EMail: bje@apnic.net
+   URI:   http://www.apnic.net
+
+
+   Ning Kong
+   China Internet Network Information Center
+   4 South 4th Street, Zhongguancun, Haidian District
+   Beijing  100190
+   China
+
+   Phone: +86 10 5881 3147
+   EMail: nkong@cnnic.cn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton, et al.               Standards Track                   [Page 16]
+