draft-ietf-weirds-using-http-06.txt   draft-ietf-weirds-using-http-07.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: December 20, 2013 APNIC Expires: January 04, 2014 APNIC
N. Kong N. Kong
CNNIC CNNIC
June 18, 2013 July 03, 2013
HTTP usage in the Registration Data Access Protocol (RDAP) HTTP usage in the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-using-http-06 draft-ietf-weirds-using-http-07
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).
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 20, 2013. This Internet-Draft will expire on January 04, 2014.
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/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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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. Accept Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . 5 4.2. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 6 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 6
5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 6 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 6
5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 7 5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 6
5.6. Cross-Origin Resource Sharing . . . . . . . . . . . . . . 7 5.6. Cross-Origin Resource Sharing . . . . . . . . . . . . . . 7
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 8 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 8
8.2. RDAP Media Type Registration . . . . . . . . . . . . . . 9 9. Internationalization Considerations . . . . . . . . . . . . . 9
9. Internationalization Considerations . . . . . . . . . . . . . 10 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 9
9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Language Identifiers in Queries and Responses . . . . . . 9
9.2. Language Identifiers in Queries and Responses . . . . . . 10 9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 9
9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 10 10. Contributing Authors and Acknowledgements . . . . . . . . . . 9
10. Contributing Authors and Acknowledgements . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 11
Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 12 Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 11
Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 13 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 12
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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. The goal of this document is to tie together Directory Services. The goal of this document is to tie together
usage patterns of HTTP into a common profile applicable to the usage patterns of HTTP into a common profile applicable to the
various types of Directory Services serving Registration Data using various types of Directory Services serving Registration Data using
RESTful practices. By giving the various Directory Services common RESTful practices. By giving the various Directory Services common
behavior, a single client is better able to retrieve data from behavior, a single client is better able to retrieve data from
Directory Services adhering to this behavior. Directory Services adhering to this behavior.
skipping to change at page 4, line 52 skipping to change at page 4, line 44
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 an entity 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, 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 defined, with the response contents [RFC4627] response media type is noted, with the response contents to
to be described separately. This document only describes how RDAP is be described separately. This document only describes how RDAP is
transported using HTTP with this format. 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. Accept Header
RDAP clients MUST include an Accept: header field specifying To indicate to servers that an RDAP response is desired, clients
application/rdap+json, application/json, or both. Servers receiving include an Accept: header field with an RDAP specific JSON media
an RDAP request MUST return an entity with Content-Type application/ type, the generic JSON media type, or both. Servers receiving an
rdap+json. RDAP request return an entity with a Content-Type: header containing
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.2. 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.
skipping to change at page 9, line 11 skipping to change at page 9, line 4
this registry entry this registry entry
Intended usage: brief reasons for this registry entry Intended usage: brief reasons for this registry entry
The following is an example of a registration in the RDAP extension The following is an example of a registration in the RDAP extension
registry: registry:
Extension identifier: lunarNic Extension identifier: lunarNic
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
8.2. RDAP Media Type Registration
This specification registers the "application/rdap+json" media type.
Type name: application
Subtype name: rdap+json
Required parameters: n/a
Encoding considerations: See section 3.1 of [RFC6839].
Security considerations: The media represented by this identifier
does not have security considerations beyond that found in section
6 of [RFC4627]
Interoperability considerations: There are no known
interoperability problems regarding this media format.
Published specification: [[ this document ]]
Applications that use this media type: Implementations of the
Registration Data Access Protocol (RDAP)
Additional information: This media type is a product of the IETF
WEIRDS working group. The WEIRDS charter, information on the
WEIRDS mailing list, and other documents produced by the WEIRDS
working group can be found at https://datatracker.ietf.org/wg/
weirds/ [1]
Person & email address to contact for further information: Andy
Newton <andy@hxr.us>
Intended usage: COMMON
Restrictions on usage: none
Author: Andy Newton
Change controller: IETF
Provisional Registration: No (upon publication of this RFC)
9. Internationalization Considerations 9. Internationalization Considerations
9.1. URIs and IRIs 9.1. URIs and IRIs
Clients can use IRIs [RFC3987] for internal use as they see fit, but Clients can use IRIs [RFC3987] for internal use as they see fit, but
MUST transform them to URIs [RFC3986] for interaction with RDAP MUST transform them to URIs [RFC3986] for interaction with RDAP
servers. RDAP servers MUST use URIs in all responses, and again servers. RDAP servers MUST use URIs in all responses, and again
clients can transform these URIs to IRIs for internal use as they see clients can transform these URIs to IRIs for internal use as they see
fit. fit.
skipping to change at page 12, line 12 skipping to change at page 11, line 9
[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.
[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 [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839, January 2013.
[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.
skipping to change at page 15, line 42 skipping to change at page 14, line 12
* Corrected RFC 6839 as an informative reference. * Corrected RFC 6839 as an informative reference.
* Replaced MAYs with cans in Seciton 9.1. * Replaced MAYs with cans in Seciton 9.1.
* Replaced MAY with can in Appendix B. * Replaced MAY with can in Appendix B.
* Added a note in in Appendix C for the RFC Editor to remove this * Added a note in in Appendix C for the RFC Editor to remove this
section. section.
-07
* Dropped reference to MUST with application/rdap+json
* Dropped IANA registration of application/rdap+json
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. 16 change blocks. 
73 lines changed or deleted 34 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/