draft-ietf-weirds-using-http-09.txt   draft-ietf-weirds-using-http-10.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track B. Ellacott Intended status: Standards Track B. Ellacott
Expires: February 8, 2015 APNIC Expires: February 23, 2015 APNIC
N. Kong N. Kong
CNNIC CNNIC
August 7, 2014 August 22, 2014
HTTP usage in the Registration Data Access Protocol (RDAP) HTTP usage in the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-using-http-09 draft-ietf-weirds-using-http-10
Abstract Abstract
This document is one of a collection that together describe the This document is one of a collection that together describe the
Registration Data Access Protocol (RDAP). It describes how RDAP is Registration Data Access Protocol (RDAP). It describes how RDAP is
transported using the Hypertext Transfer Protocol (HTTP). transported using the Hypertext Transfer Protocol (HTTP). RDAP is a
successor protocol to the very old WHOIS protocol.
Normative Reference Note
Normative references to RFC 7231 and draft-ietf-httpbis-http2 can be
replaced with a reference to RFC 2616 if draft-ietf-httpbis-http2 is
still a work in progress when this document is ready for publication.
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 February 8, 2015. This Internet-Draft will expire on February 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . 4
4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 5 4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . 5 4.2. Accept Header . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Query Parameters . . . . . . . . . . . . . . . . . . . . 5
5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . 5 5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . 5
5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . 5 5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . 5
5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 6 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 6
5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 6 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 6
5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Cross-Origin Resource Sharing . . . . . . . . . . . . . . 7 5.6. Cross-Origin Resource Sharing . . . . . . . . . . . . . . 7
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 8 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 8
9. Internationalization Considerations . . . . . . . . . . . . . 9 9. Internationalization Considerations . . . . . . . . . . . . . 9
9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 9 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Language Identifiers in Queries and Responses . . . . . . 9 9.2. Language Identifiers in Queries and Responses . . . . . . 9
9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 9 9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 9
10. Contributing Authors and Acknowledgements . . . . . . . . . . 9 10. Contributing Authors and Acknowledgements . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 11 Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 11
Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 11 Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 12
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 12 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes the usage of HTT[RFC7231]P for Registration This document describes the usage of HTTP[RFC7230] for Registration
Data Directory Services. The goal of this document is to tie Data Directory Services. The goal of this document is to tie
together usage patterns of HTTP into a common profile applicable to together usage patterns of HTTP into a common profile applicable to
the various types of Directory Services serving Registration Data the various types of Directory Services serving Registration Data
using RESTful practices. By giving the various Directory Services using RESTful practices. By giving the various Directory Services
common behavior, a single client is better able to retrieve data from common behavior, a single client is better able to retrieve data from
Directory Services adhering to this behavior. Directory Services adhering to this behavior.
The registration data expected to be presented by this service is The registration data expected to be presented by this service is
Internet resource registration data - registration of domain names Internet resource registration data - registration of domain names
and Internet number resources. This data is typically provided by and Internet number resources. This data is typically provided by
skipping to change at page 3, line 23 skipping to change at page 3, line 18
WHOIS, while providing a specification for queries and responses, WHOIS, while providing a specification for queries and responses,
redirection to authoritative sources, support for Internationalized redirection to authoritative sources, support for Internationalized
Domain Names (IDNs, [RFC5890]), and support for localized Domain Names (IDNs, [RFC5890]), and support for localized
registration data such as addresses and organisation or person names. registration data such as addresses and organisation or person names.
In designing these common usage patterns, this document introduces In designing these common usage patterns, this document introduces
considerations for a simple use of HTTP. Where complexity may considerations for a simple use of HTTP. Where complexity may
reside, it is the goal of this document to place it upon the server 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 and to keep the client as simple as possible. A client
implementation should be possible using common operating system implementation should be possible using common operating system
scripting tools. scripting tools (e.g. bash and wget).
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 GE[I-D.ietf-httpbis-http2]T. 1. A client issues an HTTP query using GET[RFC7231]. As an example,
As an example, a query for the network registration 192.0.2.0 a query for the network registration 192.0.2.0 might be
might be http://example.com/ip/192.0.2.0. http://example.com/ip/192.0.2.0. [I-D.ietf-weirds-rdap-query]
details the various queries used in RDAP.
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. [I-D.ietf-weirds-json-response] details a response in
JSON standardized by the IETF. Other formats may be used as
well.
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 field containing an HTTP(S) URL (Uniform Location: header field containing an HTTP(S) URL (Uniform
Resource Locator) pointing to the information or another server Resource Locator) pointing to the information or another server
known to have knowledge of the location of the information. The known to have knowledge of the location of the information. The
client is expected to re-query 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
skipping to change at page 4, line 16 skipping to change at page 4, line 13
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 Security and Stability Advisory Committee (SSAC)
[SAC-051], the term "WHOIS" is overloaded, often referring to a Report on WHOIS Terminology and Structure [SAC-051], the term "WHOIS"
protocol, a service and data. In accordance with [SAC-051], this is overloaded, often referring to a protocol, a service and data. In
document describes the base behavior for a Registration Data Access accordance with [SAC-051], this document describes the base behavior
Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for for a Registration Data Access Protocol (RDAP). [SAC-051] describes
Domain Name Registries (DNRs), the Domain Name Registration Data a protocol profile of RDAP for Domain Name Registries (DNRs), the
Access Protocol (DNRD-AP). Domain Name Registration Data Access Protocol (DNRD-AP).
In this document, an RDAP client is an HTTP User Agent performing an 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 RDAP query, and an RDAP server is an HTTP server providing an RDAP
response. RDAP query and response formats are described in other response. RDAP query and response formats are described in
documents in the collection of RDAP specifications, while this [I-D.ietf-weirds-rdap-query] and [I-D.ietf-weirds-json-response],
document describes how RDAP clients and servers use HTTP to exchange while this document describes how RDAP clients and servers use HTTP
queries and responses. to exchange queries and responses. [I-D.ietf-weirds-rdap-sec]
describes security consideration for RDAP.
3. Design Intents 3. Design Intents
There are a few design criteria this document attempts to meet. 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 traditional query/response model used by HTTP is simplified to the traditional query/response model used by HTTP
[RFC7231]. Should an entity contain more than one result, some of [RFC7230]. 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, the semantics of the request/response allow for future and/or Second, the semantics of the request/response allow for future and/or
non-standard response formats. In this document, only a JSON non-standard response formats. In this document, only a JSON
[RFC4627] response media type is noted, with the response contents to [RFC4627] response media type is noted, with the response contents to
be described separately. This document only describes how RDAP is be described separately (see [I-D.ietf-weirds-json-response]). This
transported using HTTP with this format. 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 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 of mechanisms available for use with HTTP. HTTP offers a number of
mechanisms not described further in this document. Operators are mechanisms not described further in this document. Operators are
able to make use of these mechanisms according to their local policy, able to make use of these mechanisms according to their local policy,
including cache control, authorization, compression, and redirection. including cache control, authorization, compression, and redirection.
HTTP also benefits from widespread investment in scalability, HTTP also benefits from widespread investment in scalability,
reliability, and performance, and widespread programmer understanding reliability, and performance, and widespread programmer understanding
of client behaviours for RESTful web services, reducing the cost to of client behaviours for RESTful web services, reducing the cost to
deploy Registration Data Directory Services and clients. deploy Registration Data Directory Services and clients.
4. Queries 4. Queries
4.1. Accept Header 4.1. HTTP Methods
Clients SHOULD use either the HTTP GET or HEAD methods (see
[RFC7231]). The GET method should be used to retreive a response
body. The HEAD method can be used to determine existence of data on
the server. Servers are under no obligation to support other HTTP
methods.
4.2. Accept Header
To indicate to servers that an RDAP response is desired, clients To indicate to servers that an RDAP response is desired, clients
include an Accept: header field with an RDAP specific JSON media include an Accept: header field with an RDAP specific JSON media
type, the generic JSON media type, or both. Servers receiving an type, the generic JSON media type, or both. Servers receiving an
RDAP request return an entity with a Content-Type: header containing RDAP request return an entity with a Content-Type: header containing
the RDAP specific JSON media type. the RDAP specific JSON media type.
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 field, or 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 with no Accept: header field. One possibility would be to return a
response in 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.3. Query Parameters
Servers MUST 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 B. parameters for cache-busting is described in 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 as they will be in common use by servers. described in this section as they will be in common use by servers.
skipping to change at page 6, line 7 skipping to change at page 6, line 15
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 returns either a 301 response code query can be found elsewhere, it returns either a 301 response code
to indicate a permanent move, or a 302, 303 or 307 response code to to indicate a permanent move, or a 302, 303 or 307 response code to
indicate a non-permanent redirection, and it includes an HTTP(s) URL indicate a non-permanent redirection, and it includes an HTTP(s) URL
in the Location: header field. The client is expected to issue a in the Location: header field. The client is expected to issue a
subsequent request to satisfy the original query using the given URL subsequent request to satisfy the original query using the given URL
without any processing of the URL. In other words, the server is to 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 hand back a complete URL and the client should not have to transform
the URL to follow it. the URL to follow it. Servers are under no obligation to return a
URL conformant to [I-D.ietf-weirds-rdap-query].
For this application, such an example of a permanent move might be a For this application, such an example of a permanent move might be a
Top Level Domain (TLD) operator informing a client the information Top Level Domain (TLD) operator informing a client the information
being sought can be found with another TLD operator (i.e. a query for 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/ the domain bar in foo.example is found at http://foo.example/domain/
bar). bar).
For example, if the client sends For example, if the client sends
http://serv1.example.com/weirds/domain/example.com, the server http://serv1.example.com/weirds/domain/example.com, the server
redirecting to https://serv2.example.net/weirds2/ would set the redirecting to https://serv2.example.net/weirds2/ would set the
skipping to change at page 7, line 11 skipping to change at page 7, line 23
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. A server might use another response code if 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 it did not wish to reveal to a client that rate limiting is the
reason for the denial of a reply. 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 field, as specified by Access-Control-Allow-Origin header field, as specified by
[W3C.CR-cors-20130129]. [W3C.CR-cors-20130129]. As the use of RDAP is for public resources,
a value of "*" is suitable for most cases.
This header (often called the CORS header), helps in-browser web
applications by lifting the "same-origin" restriction.
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 8). 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
skipping to change at page 8, line 5 skipping to change at page 8, line 19
7. Security Considerations 7. Security Considerations
This document does not pose strong security requirements to the RDAP This document does not pose strong security requirements to the RDAP
protocol. However, it does not restrict against the use of security protocol. However, it does not restrict against the use of security
mechanisms offered by the HTTP protocol. mechanisms offered by the HTTP protocol.
This document made recommendations for server implementations against This document made recommendations for server implementations against
denial-of-service (Section 5.5) and interoperability with existing denial-of-service (Section 5.5) and interoperability with existing
security mechanism in HTTP clients (Section 5.6). security mechanism in HTTP clients (Section 5.6).
Additional security considerations to the RDAP protocol will be Additional security considerations to the RDAP protocol are covered
covered in future RFCs documenting specific security mechanisms and in [I-D.ietf-weirds-rdap-sec].
schemes.
8. IANA Considerations 8. IANA Considerations
8.1. RDAP Extensions Registry 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 a 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.
skipping to change at page 10, line 12 skipping to change at page 10, line 27
Normative language reviews were provided by Murray S. Kucherawy and Normative language reviews were provided by Murray S. Kucherawy and
Andrew Sullivan. Andrew Sullivan.
Jean-Phillipe Dionne provided text for the Security Considerations Jean-Phillipe Dionne provided text for the Security Considerations
section. section.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-httpbis-http2] [I-D.ietf-weirds-json-response]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Newton, A. and S. Hollenbeck, "JSON Responses for the
Protocol version 2", draft-ietf-httpbis-http2-14 (work in Registration Data Access Protocol (RDAP)", draft-ietf-
progress), July 2014. weirds-json-response-08 (work in progress), August 2014.
[I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-11
(work in progress), July 2014.
[I-D.ietf-weirds-rdap-sec]
Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol", draft-ietf-weirds-
rdap-sec-07 (work in progress), August 2014.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [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 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[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.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[W3C.CR-cors-20130129] [W3C.CR-cors-20130129]
Kesteren, A., "Cross-Origin Resource Sharing", World Wide Kesteren, A., "Cross-Origin Resource Sharing", World Wide
Web Consortium Candidate Recommendation CR-cors-20130129, Web Consortium Candidate Recommendation CR-cors-20130129,
January 2013, January 2013,
<http://www.w3.org/TR/2013/CR-cors-20130129>. <http://www.w3.org/TR/2013/CR-cors-20130129>.
11.2. Informative References 11.2. Informative References
skipping to change at page 11, line 13 skipping to change at page 11, line 44
RFC 5890, August 2010. RFC 5890, August 2010.
[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.
Appendix A. Protocol Example Appendix A. Protocol Example
To demonstrate typical behaviour of an RDAP client and server, the To demonstrate typical behaviour of an RDAP client and server, the
following is an example of an exchange, including a redirect. 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 data in the response has been elided for brevity, as the data format
is not described in this document. is not described in this document. The media type used here is
described in [I-D.ietf-weirds-json-response].
An example of an RDAP client and server exchange: An example of an RDAP client and server exchange:
Client: Client:
<TCP connect to rdap.example.com port 80> <TCP connect to rdap.example.com port 80>
GET /ip/203.0.113.0/24 HTTP/1.1 GET /ip/203.0.113.0/24 HTTP/1.1
Host: rdap.example.com Host: rdap.example.com
Accept: application/rdap+json Accept: application/rdap+json
rdap.example.com: rdap.example.com:
skipping to change at page 11, line 46 skipping to change at page 12, line 36
rdap-ip.example.com: rdap-ip.example.com:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/rdap+json Content-Type: application/rdap+json
Content-Length: 9001 Content-Length: 9001
{ ... } { ... }
<TCP disconnect> <TCP disconnect>
Appendix B. Cache Busting Appendix B. Cache Busting
Some HTTP [RFC7231] cache infrastructure does not adhere to caching Some HTTP [RFC7230] cache infrastructure does not adhere to caching
standards adequately, and could cache responses longer than is standards adequately, and could cache responses longer than is
intended by the server. To overcome these issues, clients can use an intended by the server. To overcome these issues, clients can use an
adhoc and improbably used query parameter with a random value of adhoc and improbably used query parameter with a random value of
their choosing. As Section 4.2 instructs servers to ignore unknown their choosing. As Section 4.3 instructs servers to ignore unknown
parameters, this is unlikely to have any known side effects. 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.
skipping to change at page 14, line 26 skipping to change at page 15, line 17
* Changed status lines in example to include http version number. * Changed status lines in example to include http version number.
* Removed charset from media types in examples. * Removed charset from media types in examples.
* Changed wording of 404 negative response to specifically say * Changed wording of 404 negative response to specifically say
"empty result set". "empty result set".
* Changed references to HTTP. * Changed references to HTTP.
-10
* Corrected references to HTTP.
* Added a reference to draft-ietf-weirds-json-response (discuss
item from Barry Leiba)
* Added a reference to draft-ietf-weirds-rdap-query (discuss item
from Barry Leiba)
* Noted that redirect URLs do not have to conform to draft-ietf-
weirds-rdap-query (comment by Richard Barnes)
* Noted that CORS header is most likely to be "*" (comment by
Richard Barnes)
* Added reference to draft-ietf-weirds-rdap-sec (comment by
Richard Barnes)
* Added a sentence to the abstract explaining the purpose of RDAP
(comment by Stephen Farrell)
* Added further references to draft-ietf-weirds-rdap-query and
draft-ietf-weirds-json-response (comment by Stephen Farrell)
* Added comment regarding the use of the CORS header (comment by
Stephen Farrell)
* Explanded SSAC (comment by Sean Turner)
* Added text about HEAD and GET.
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
 End of changes. 31 change blocks. 
55 lines changed or deleted 115 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/