Using the Registration Data Access Protocol (RDAP) with HTTP
draft-ietf-weirds-using-http-01
Network Working Group A. Newton
Internet-Draft ARIN
Intended status: Standards Track B. Ellacott
Expires: June 8, 2013 APNIC
N. Kong
CNNIC
December 5, 2012
Using the Registration Data Access Protocol (RDAP) with HTTP
draft-ietf-weirds-using-http-01
Abstract
This document describes the usage of the Registration Data Access
Protocol (RDAP) using HTTP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 8, 2013.
Copyright Notice
Copyright (c) 2012 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. Expires June 8, 2013 [Page 1]
Internet-Draft RDAP over HTTP December 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . . 6
5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . . 7
5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . . 7
5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . . 7
5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Internationalization Considerations . . . . . . . . . . . . . 10
8.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Language Identifiers in Queries and Responses . . . . . . 10
8.3. Language Identifiers in HTTP Headers . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Cache Busting . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Newton, et al. Expires June 8, 2013 [Page 2]
Internet-Draft RDAP over HTTP December 2012
1. Introduction
This document describes the usage of HTTP for Registration Data
Directory Services running on RESTful web servers. The goal of this
document is to tie together the usage patterns of HTTP into a common
profile applicable to the various types of Directory Services serving
Registration Data using RESTful styling. By giving the various
Directory Services common behavior, a single client is better able to
retrieve data from Directory Services adhering to this behavior.
In designing these common usage patterns, this draft endeavours to
satisfy requirements for a Registration Data Access Protocol (RDAP)
that is documented in [draft-kucherawy-weirds-requirements]. This
draft also introduces an additional design consideration to define a
simple use of HTTP. Where complexity may reside, it is the goal of
this specification to place it upon the server and to keep the client
as simple as possible. A client implementation should be possible
Show full document text