draft-ietf-weirds-using-http-03.txt   draft-ietf-weirds-using-http-04.txt 
Network Working Group A.L. Newton Network Working Group A.L. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track B.J. Ellacott Intended status: Standards Track B.J. Ellacott
Expires: September 28, 2013 APNIC Expires: October 17, 2013 APNIC
N. Kong N. Kong
CNNIC CNNIC
March 27, 2013 April 17, 2013
Using the Registration Data Access Protocol (RDAP) with HTTP HTTP usage in the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-using-http-03 draft-ietf-weirds-using-http-04
Abstract Abstract
This document describes the usage of the Registration Data Access This document is one of a collection that together describe the
Protocol (RDAP) using HTTP. Registration Data Access Protocol (RDAP). It describes how RDAP is
transported using the Hypertext Transfer Protocol (HTTP).
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2013. This Internet-Draft will expire on October 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
1. Introduction 1. Introduction
This document describes the usage of HTTP for Registration Data This document describes the usage of HTTP for Registration Data
Directory Services running on RESTful web servers. The goal of this Directory Services. The goal of this document is to tie together
document is to tie together the usage patterns of HTTP into a common usage patterns of HTTP into a common profile applicable to the
profile applicable to the various types of Directory Services serving various types of Directory Services serving Registration Data using
Registration Data using RESTful styling. By giving the various RESTful practices. By giving the various Directory Services common
Directory Services common behavior, a single client is better able to behavior, a single client is better able to retrieve data from
retrieve data from Directory Services adhering to this behavior. Directory Services adhering to this behavior.
In designing these common usage patterns, this draft endeavours to The registration data expected to be presented by this service is
satisfy requirements for a Registration Data Access Protocol (RDAP). Internet resource registration data - registration of domain names
This draft also introduces an additional design consideration to and Internet number resources. This data is typically provided by
define a simple use of HTTP. Where complexity may reside, it is the WHOIS [RFC3912] services, but the WHOIS protocol is insufficient to
goal of this specification to place it upon the server and to keep modern registration data service requirements. A replacement
the client as simple as possible. A client implementation should be protocol is expected to retain the simple transactional nature of
possible using common operating system scripting tools. 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 organisation 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.
This is the basic usage pattern for this protocol: This is the basic usage pattern for this protocol:
1. A client issues an HTTP query using GET. As an example, a query 1. A client issues an HTTP query using GET. As an example, a query
for the network registration 192.0.2.0 might be http:// for the network registration 192.0.2.0 might be http://
example.com/ip/192.0.2.0. example.com/ip/192.0.2.0.
2. If the receiving server has the information for the query, it 2. If the receiving server has the information for the query, it
examines the Accept header field of the query and returns a 200 examines the Accept header field of the query and returns a 200
response with a response entity appropriate for the requested response with a response entity appropriate for the requested
format. format.
3. If the receiving server does not have the information for the 3. If the receiving server does not have the information for the
query but does have knowledge of where the information can be query but does have knowledge of where the information can be
found, it will return a redirection response (3xx) with the found, it will return a redirection response (3xx) with the
Location: header containing an HTTP URL pointing to the Location: header field containing an HTTP(S) URL (Uniform
information or another server known to have knowledge of the Resource Locator) pointing to the information or another server
location of the information. The client is expected to re-query known to have knowledge of the location of the information. The
using that HTTP URL. client is expected to re-query using that HTTP URL.
4. If the receiving server does not have the information being 4. If the receiving server does not have the information being
requested and does not have knowledge of where the information requested and does not have knowledge of where the information
can be found, it should return a 404 response. can be found, it returns a 404 response.
5. 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 important to note that it is not the intent of this document to It is important to note that it is not the intent of this document to
redefine the meaning and semantics of HTTP. The purpose of this redefine the meaning and semantics of HTTP. The purpose of this
document is to clarify the use of standard HTTP mechanisms for this document is to clarify the use of standard HTTP mechanisms for this
application. application.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
As is noted in SSAC Report on WHOIS Terminology and Structure As is noted in SSAC Report on WHOIS Terminology and Structure
[SAC-051], the term "Whois" is overloaded, often referring to a [SAC-051], the term "WHOIS" is overloaded, often referring to a
protocol, a service and data. In accordance with [SAC-051], this protocol, a service and data. In accordance with [SAC-051], this
document describes the base behavior for a Registration Data Access document describes the base behavior for a Registration Data Access
Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for
Domain Name Registries (DNRs), DNRD-AP. This document and others Domain Name Registries (DNRs), the Domain Name Registration Data
from the IETF WEIRDS working group describe a single protocol, RDAP, Access Protocol (DNRD-AP).
for access to the data of both DNRs and Regional Internet Registries
(RIRs). RIRs are also often referred to as number resource In this document, an RDAP client is an HTTP User Agent performing an
registries and are responsible for the registration of IP address RDAP query, and an RDAP server is an HTTP server providing an RDAP
networks and autonomous system numbers. response. RDAP query and response formats are described in other
documents in the collection of RDAP specifications, while this
document describes how RDAP clients and servers use HTTP to exchange
queries and responses.
3. Design Intents 3. Design Intents
There are a few design criteria this document attempts to support. There are a few design criteria this document attempts to meet.
First, each query is meant to return either zero or one result. With First, each query is meant to return either zero or one result. With
the maximum upper bound being set to one, the issuance of redirects the maximum upper bound being set to one, the issuance of redirects
is simplified to the known query/response model used by HTTP is simplified to the known query/response model used by HTTP
[RFC2616]. Should a result contain more than one result, some of [RFC2616]. Should an entity contain more than one result, some of
which are better served by other servers, the redirection model which are better served by other servers, the redirection model
becomes much more complicated. becomes much more complicated.
Second, multiple response formats are supported by this protocol. At Second, multiple response formats are supported by this protocol. At
present the IETF WEIRDS working group is defining only a JSON present the IETF WEIRDS working group is defining only a JSON
[RFC4627] response format, but server operators may use other data [RFC4627] response format, but server operators may use other data
formats when those formats are requested. formats when those formats are requested.
Third, HTTP offers a number of transport protocol mechanisms not Third, this protocol is intended to be able to make use of the range
described further in this document. Operators are able to make use of mechanisms available for use with HTTP. HTTP offers a number of
of these mechanisms according to their local policy, including cache mechanisms not described further in this document. Operators are
control, authorization, compression, and redirection. HTTP also able to make use of these mechanisms according to their local policy,
benefits from widespread investment in scalability, reliability, and including cache control, authorization, compression, and redirection.
performance, and widespread programmer understanding of client HTTP also benefits from widespread investment in scalability,
behaviours for RESTful web services, reducing the cost to deploy reliability, and performance, and widespread programmer understanding
Registration Data Directory Services and clients. of client behaviours for RESTful web services, reducing the cost to
deploy Registration Data Directory Services and clients.
4. Queries 4. Queries
4.1. Accept Header 4.1. Accept Header
RDAP clients MUST include an Accept: header specifying application/ RDAP clients MUST include an Accept: header field specifying
rdap+json, application/json, or both. Servers receiving an RDAP application/rdap+json, application/json, or both. Servers receiving
request MUST return an entity with Content-Type application/ an RDAP request MUST return an entity with Content-Type application/
rdap+json. rdap+json.
This specification does not define the responses a server returns to This specification does not define the responses a server returns to
a request with any other media types in the Accept: header, or with a request with any other media types in the Accept: header field, or
no Accept: header. One possibility would be to return a response in with no Accept: header field. One possibility would be to return a
a media type suitable for rendering in a web browser. response in a media type suitable for rendering in a web browser.
4.2. Query Parameters 4.2. Query Parameters
Servers SHOULD ignore unknown query parameters. Use of unknown query Servers MUST ignore unknown query parameters. Use of unknown query
parameters for cache-busting is described in Appendix A. parameters for cache-busting is described in Appendix Appendix B.
5. Types of HTTP Response 5. Types of HTTP Response
This section describes the various types of responses a server may This section describes the various types of responses a server may
send to a client. While no standard HTTP response code is forbidden send to a client. While no standard HTTP response code is forbidden
in usage, at a minimum clients SHOULD understand the response codes in usage, at a minimum clients SHOULD understand the response codes
described in this section. It is expected that usage of response described in this section. It is expected that usage of response
codes and types for this application not defined here will be codes and types for this application not defined here will be
described in subsequent documents. described in subsequent documents.
5.1. Positive Answers 5.1. Positive Answers
If a server has the information requested by the client and wishes to If a server has the information requested by the client and wishes to
respond to the client with the information according to its policies, respond to the client with the information according to its policies,
it SHOULD encode the answer in the format most appropriate according it encodes the answer in the format most appropriate according to the
to the standard and defined rules for processing the HTTP Accept standard and defined rules for processing the HTTP Accept header
header, and return that answer in the body of a 200 response. field, and return that answer in the body of a 200 response.
5.2. Redirects 5.2. Redirects
If a server wishes to inform a client that the answer to a given If a server wishes to inform a client that the answer to a given
query can be found elsewhere, it SHOULD return either a 301 or a 307 query can be found elsewhere, it MUST return a 301 response code to
response code and an HTTP URL in the Location: header. The client is indicate a permanent move, or a 307 response code to indicate a non-
expected to issue a subsequent query using the given URL without any permanent redirection, and include an HTTP(s) URL in the Location:
header field. 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 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 complete URL and the client should not have to transform the URL to
follow it. follow it.
A server SHOULD use a 301 response to inform the client of a For this application, such an example of a permanent move might be a
permanent move and a 307 response otherwise. For this application, Top Level Domain (TLD) operator informing a client the information
such an example of a permanent move might be a top level domain (TLD) being sought can be found with another TLD operator (i.e. a query
operator informing a client the information being sought can be found for the domain bar in foo.example is found at http://foo.example/
with another TLD operator (i.e. a query for the domain bar in domain/bar).
foo.example is found at http://foo.example/domain/bar).
In other words, when generating the redirect url, the server will
only alter the base of the URL. It will not attempt to normalize or
modify the path segment.
For example, if the client sends http://serv1.example.com/weirds/ For example, if the client sends http://serv1.example.com/weirds/
domain/example.com, the server redirecting to https:// domain/example.com, the server redirecting to https://
serv2.example.net/weirds2/ would set the Location: field to the serv2.example.net/weirds2/ would set the Location: field to the
value: https://serv2.example.net/weirds2/domain/example.com. value: https://serv2.example.net/weirds2/domain/example.com.
5.3. Negative Answers 5.3. Negative Answers
If a server wishes to respond that it has no information regarding If a server wishes to respond that it has no information regarding
the query, it SHOULD return a 404 response code. Optionally, it MAY the query, it MUST return a 404 response code. Optionally, it MAY
include additional information regarding the negative answer in the include additional information regarding the negative answer in the
HTTP entity body. 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. Clients
MAY retry the query based on the respective response code.
5.4. Malformed Queries 5.4. Malformed Queries
If a server receives a query which it cannot understand, it SHOULD If a server receives a query which it cannot interpret as an RDAP
return a 400 response code. Optionally, it MAY include additional query, it MUST return a 400 response code. Optionally, it MAY
information regarding this negative answer in the HTTP entity body. include additional information regarding this negative answer in the
HTTP entity body.
5.5. Rate Limits 5.5. Rate Limits
Some servers apply rate limits to deter address scraping and other Some servers apply rate limits to deter address scraping and other
abuses. When a server declines to answer a query due to rate limits, abuses. When a server declines to answer a query due to rate limits,
it MAY return a 429 response code as described in [RFC6585]. A it SHOULD return a 429 response code as described in [RFC6585]. A
client that receives a 429 response SHOULD decrease its query rate, client that receives a 429 response SHOULD decrease its query rate,
and honor the Retry-After header if one is present. and honor the Retry-After header field if one is present.
Note that this is not a defense against denial-of-service attacks, Note that this is not a defense against denial-of-service attacks,
since a malicious client could ignore the code and continue to send since a malicious client could ignore the code and continue to send
queries at a high rate. 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 5.6. Cross-Origin Resource Sharing
When responding to queries, it is RECOMMENDED that servers use the When responding to queries, it is RECOMMENDED that servers use the
Access-Control-Allow-Origin header, as specified by Access-Control-Allow-Origin header field, as specified by [W3C.CR-
[W3C.WD-cors-20130129]. cors-20130129].
6. Extensibility 6. Extensibility
For extensibility purposes, this document defines an IANA registry For extensibility purposes, this document defines an IANA registry
for prefixes used in JSON [RFC4627] data serialization and URI path for prefixes used in JSON [RFC4627] data serialization and URI path
segments (see Section 7). segments (see Section 8).
Prefixes and identifiers SHOULD only consist of the alphabetic ASCII Prefixes and identifiers SHOULD only consist of the alphabetic ASCII
characters A through Z in both uppercase and lowercase, the numerical characters A through Z in both uppercase and lowercase, the numerical
digits 0 through 9, underscore characters, and SHOULD NOT begin with digits 0 through 9, underscore characters, and SHOULD NOT begin with
an underscore character, numerical digit or the characters "xml". an underscore character, numerical digit or the characters "xml".
The following describes the production of JSON names in ABNF The following describes the production of JSON names in ABNF
[RFC5234]. [RFC5234].
ABNF for JSON names ABNF for JSON names
name = ALPHA *( ALPHA / DIGIT / "_" ) name = ALPHA *( ALPHA / DIGIT / "_" )
Figure 1
This restriction is a union of the Ruby programming language This restriction is a union of the Ruby programming language
identifier syntax and the XML element name syntax and has two identifier syntax and the XML element name syntax and has two
purposes. First, client implementers using modern programming purposes. First, client implementers using modern programming
languages such as Ruby or Java may use libraries that automatically languages such as Ruby or Java can use libraries that automatically
promote JSON names to first order object attributes or members. promote JSON names to first order object attributes or members.
Second, a clean mapping between JSON and XML is easy to accomplish Second, a clean mapping between JSON and XML is easy to accomplish
using these rules. using these rules.
7. IANA Considerations 7. Security Considerations
7.1. RDAP Extensions Registry 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.
This document made recommendations for server implementations against
denial-of-service (Section 5.5) and interoperability with existing
security mechanism in HTTP clients (Section 5.6).
Additional security considerations to the RDAP protocol will be
covered in future RFCs documenting specific security mechanisms and
schemes.
8. IANA Considerations
8.1. RDAP Extensions Registry
This specification proposes an IANA registry for RDAP extensions. This specification proposes an IANA registry for RDAP extensions.
The purpose of this registry is to ensure uniqueness of extension The purpose of this registry is to ensure uniqueness of extension
identifiers. The extension identifier is used as prefix in JSON identifiers. The extension identifier is used as a prefix in JSON
names and as a prefix of path segments in RDAP URLs. names and as a prefix of path segments in RDAP URLs.
The production rule for these identifiers is specified in Section 6. The production rule for these identifiers is specified in Section 6.
In accordance with RFC5226, the IANA policy for assigning new values In accordance with RFC5226, the IANA policy for assigning new values
shall be Specification Required: values and their meanings must be shall be Specification Required: values and their meanings must be
documented in an RFC or in some other permanent and readily available documented in an RFC or in some other permanent and readily available
reference, in sufficient detail that interoperability between reference, in sufficient detail that interoperability between
independent implementations is possible. independent implementations is possible.
skipping to change at page 7, line 32 skipping to change at page 7, line 35
Registry operator: The Registry of the Moon, LLC Registry operator: The Registry of the Moon, LLC
Published specification: http://www.example/moon_apis/rdap Published specification: http://www.example/moon_apis/rdap
Person & email address to contact for further information: Person & email address to contact for further information:
Professor Bernardo de la Paz <berny@moon.example> Professor Bernardo de la Paz <berny@moon.example>
Intended usage: COMMON Intended usage: COMMON
7.2. RDAP Media Type Registration 8.2. RDAP Media Type Registration
This specification registers the "application/rdap+json" media type. This specification registers the "application/rdap+json" media type.
Type name: application Type name: application
Subtype name: rdap+json Subtype name: rdap+json
Required parameters: n/a Required parameters: n/a
Encoding considerations: n/a Encoding considerations: n/a
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Security considerations: n/a Security considerations: n/a
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: [[ this document ]] Published specification: [[ this document ]]
Applications that use this media type: RDAP Applications that use this media type: RDAP
Additional information: n/a Additional information: n/a
Person & email address to contact for further information: Andy Person & email address to contact for further information: Andy
Newton &andy@hxr.us&; Newton <andy@hxr.us>;
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Andy Newton Author: Andy Newton
Change controller: IETF Change controller: IETF
Provisional Registration: Yes Provisional Registration: Yes
8. Internationalization Considerations 9. Internationalization Considerations
8.1. URIs and IRIs 9.1. URIs and IRIs
Clients MAY use IRIs as they see fit, but MUST transform them to URIs Clients MAY use IRIs [RFC3987] as they see fit, but MUST transform
[RFC3986] for interaction with RDAP servers. RDAP servers MUST use them to URIs [RFC3986] for interaction with RDAP servers. RDAP
URIs in all responses, and clients MAY transform these URIs to IRIs. servers MUST use URIs in all responses, and clients MAY transform
these URIs to IRIs.
8.2. Language Identifiers in Queries and Responses 9.2. Language Identifiers in Queries and Responses
Depending on the data format of the response, servers MAY include Under most scenarios, clients requesting data will not signal that
data in character sets other than ASCII and languages other than the data be returned in a particular language or script. On the
English (the data format will most likely be in Unicode and almost other hand, when servers return data and have knowledge that the data
certainly languages other than English will be encountered). Under is in a language or script, the data SHOULD be annotated with
most scenarios, clients requesting data will not signal that the data language identifiers whenever they are available, thus allowing
be returned in a particular language or script. On the other hand, clients to process and display the data accordingly.
when servers return data and have knowledge that the data is in a
language or script, the data should be annotated with language
identifiers thus allowing clients to process and display the data
accordingly.
8.3. Language Identifiers in HTTP Headers The mechanism for including a language identifier in a response will
be defined in subsequent documents describing specific response
formats.
Given the description of the use of language identifiers in 9.3. Language Identifiers in HTTP Headers
Section 8.2, unless otherwise specified servers SHOULD ignore the
HTTP [RFC2616] Accept-Language header when formulating responses. Given the description of the use of language identifiers in Section
9.2, unless otherwise specified servers SHOULD ignore the HTTP
[RFC2616] 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.
However, servers MAY return language identifiers in the Content- However, servers MAY return language identifiers in the Content-
Language header so as to inform clients of the intended language of Language header field so as to inform clients of the intended
HTTP layer messages. language of HTTP layer messages.
9. Contributing Authors and Acknowledgements 10. Contributing Authors and Acknowledgements
John Levine provided text to tighten up the Accept header usage and John Levine provided text to tighten up the Accept header field usage
the text for the section on 429 responses. and the text for the section on 429 responses.
Marc Blanchet provided some clarifying text regarding the use of URLs Marc Blanchet provided some clarifying text regarding the use of URLs
with redirects. with redirects, as well as very useful feedback during WGLC.
10. Normative References Normative language reviews were provided by Murray S. Kucherawy and
Andrew Sullivan.
Jean-Phillipe Dionne provided text for the Security Considerations
section.
11. References
[SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS
Terminology and Structure", September 2011. Terminology and Structure", September 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012. Codes", RFC 6585, April 2012.
[W3C.WD-cors-20130129] [W3C.CR-cors-20130129]
Kesteren, A., "Cross-Origin Resource Sharing", World Wide Kesteren, A., "Cross-Origin Resource Sharing", World Wide
Web Consortium LastCall WD-cors-20130129, January 2013, Web Consortium Candidate Recommendation CR-cors-20130129,
<http://www.w3.org/TR/2012/WD-cors-20130129>. January 2013, <http://www.w3.org/TR/2013/CR-
cors-20130129>.
Appendix A. Cache Busting Appendix A. Protocol Example
To demonstrate typical behaviour 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.
To overcome issues with misbehaving HTTP [RFC2616] cache An example of an RDAP client and server exchange:
infrastructure, clients MAY use an adhoc and improbably used query
parameter with a random value of their choosing. As Section 4.2 Client:
instructs servers to ignore unknown parameters, this is unlikely to <TCP connect to rdap.example.com port 80>
have any known side effects. GET /ip/203.0.113.0/24 HTTP/1.1
Host: rdap.example.com
Accept: application/rdap+json
rdap.example.com:
HTTP 301 Moved Permanently
Location: http://rdap-ip.example.com/ip/203.0.113.0/24
Content-Length: 0
Content-Type: application/rdap+json; charset=UTF-8
<TCP disconnect>
Client:
<TCP connect to rdap-ip.example.com port 80>
GET /ip/203.0.113.0/24 HTTP/1.1
Host: rdap-ip.example.com
Accept: application/rdap+json
rdap-ip.example.com:
HTTP 200 OK
Content-Type: application/rdap_json; charset=UTF-8
Content-Length: 9001
{ ... }
<TCP disconnect>
Appendix B. Cache Busting
Some HTTP [RFC2616] cache infrastructure does not adhere to caching
standards adequately, and could cache responses longer than is
intended by the server. To overcome these issues, clients MAY use an
adhoc and improbably used query parameter with a random value of
their choosing. As Section 4.2 instructs servers to ignore unknown
parameters, this is unlikely to have any known side effects.
An example of using an unknown query parameter to bust caches: An example of using an unknown query parameter to bust caches:
http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123 http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123
Use of an unknown parameter to overcome misbehaving caches is not Use of an unknown parameter to overcome misbehaving caches is not
part of any specification and is offered here for informational part of any specification and is offered here for informational
purposes. purposes.
Appendix B. Changelog Appendix C. Changelog
Initial WG -00: Updated to working group document 2012-September-20 Initial WG -00: Updated to working group document 2012-September-20
-01 -01
* Updated for the sections moved to the JSON responses draft. * Updated for the sections moved to the JSON responses draft.
* Simplified media type, removed "level" parameter. * Simplified media type, removed "level" parameter.
* Updated 2119 language and added boilerplate. * Updated 2119 language and added boilerplate.
* In section 1, noted that redirects can go to redirect servers * In section 1, noted that redirects can go to redirect servers
as well. as well.
* Added Section 8.2 and Section 8.3. * Added Section 9.2 and Section 9.3.
-02 -02
* Added a section on 429 response codes. * Added a section on 429 response codes.
* Changed Accept header language in section 4.1 * Changed Accept header language in section 4.1
* Removed reference to the now dead requirements draft. * Removed reference to the now dead requirements draft.
* Added contributing authors and acknowledgements section. * Added contributing authors and acknowledgements section.
skipping to change at page 10, line 49 skipping to change at page 11, line 49
* Changed media type to application/rdap+json * Changed media type to application/rdap+json
* Added media type registration * Added media type registration
-03 -03
* Removed forward reference to draft-ietf-weirds-json-response. * Removed forward reference to draft-ietf-weirds-json-response.
* Added reference and recommended usage of CORS * Added reference and recommended usage of CORS
-04
* Revised introduction and abstract.
* Added negative responses other than 404.
* Added security considerations.
* Added and corrected references: CORS, RFC3912, RFC3987,
RFC5890.
* Expanded on first use several acronyms.
* Updated 2119 language.
Authors' Addresses Authors' Addresses
Andrew Lee Newton Andrew Lee Newton
American Registry for Internet Numbers American Registry for Internet Numbers
3635 Concorde Parkway 3635 Concorde Parkway
Chantilly, VA 20151 Chantilly, VA 20151
US US
Email: andy@arin.net Email: andy@arin.net
URI: http://www.arin.net URI: http://www.arin.net
Byron J. Ellacott Byron J. Ellacott
Asia Pacific Network Information Center Asia Pacific Network Information Center
6 Cordelia Street 6 Cordelia Street
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: bje@apnic.net Email: bje@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Ning Kong Ning Kong
China Internet Network Information Center China Internet Network Information Center
4 South 4th Street, Zhongguancun, Haidian District 4 South 4th Street, Zhongguancun, Haidian District
Beijing 100190 Beijing 100190
China China
Phone: +86 10 5881 3147 Phone: +86 10 5881 3147
Email: nkong@cnnic.cn Email: nkong@cnnic.cn
 End of changes. 70 change blocks. 
140 lines changed or deleted 249 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/