HTTP usage in the Registration Data Access Protocol (RDAP)

The information below is for an old version of the document
Document Type Active Internet-Draft (weirds WG)
Authors Andrew Newton  , Byron Ellacott  , Ning Kong 
Last updated 2013-04-16
Replaces draft-designteam-weirds-using-http
Stream IETF
Intended RFC status Proposed Standard
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state WG Consensus: Waiting for Write-Up
Awaiting Expert Review/Resolution of Issues Raised, Doc Shepherd Follow-up Underway
Document shepherd Olaf Kolkman
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        A.L. Newton
Internet-Draft                                                      ARIN
Intended status: Standards Track                           B.J. Ellacott
Expires: October 17, 2013                                          APNIC
                                                                 N. Kong
                                                          April 17, 2013

       HTTP usage in the Registration Data Access Protocol (RDAP)


   This document is one of a collection that together describe the
   Registration Data Access Protocol (RDAP).  It describes how RDAP is
   transported using the Hypertext Transfer Protocol (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

   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 October 17, 2013.

Copyright Notice

   Copyright (c) 2013 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 (
   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.

1.  Introduction

Newton, et al.          Expires October 17, 2013                [Page 1]
Internet-Draft               RDAP over HTTP                   April 2013

   This document describes the usage of HTTP for Registration Data
   Directory Services.  The goal of this document is to tie together
   usage patterns of HTTP into a common profile applicable to the
   various types of Directory Services serving Registration Data using
   RESTful practices.  By giving the various Directory Services common
   behavior, a single client is better able to retrieve data from
   Directory Services adhering to this behavior.

   The registration data expected to be presented by this service is
   Internet resource registration data - registration of domain names
   and Internet number resources.  This data is typically provided by
   WHOIS [RFC3912] services, but the WHOIS protocol is insufficient to
   modern registration data service requirements.  A replacement
   protocol is expected to retain the simple transactional nature of
   WHOIS, while providing a specification for queries and responses,
   redirection to authoritative sources, support for Internationalized
   Domain Names (IDNs, [RFC5890]), and support for localized
   registration data such as addresses and 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:

   1.  A client issues an HTTP query using GET. As an example, a query
       for the network registration might be http://

   2.  If the receiving server has the information for the query, it
       examines the Accept header field of the query and returns a 200
       response with a response entity appropriate for the requested

   3.  If the receiving server does not have the information for the
       query but does have knowledge of where the information can be
       found, it will return a redirection response (3xx) with the
       Location: header field containing an HTTP(S) URL (Uniform
       Resource Locator) pointing to the information or another server
       known to have knowledge of the location of the information.  The
       client is expected to re-query using that HTTP URL.

   4.  If the receiving server does not have the information being
Show full document text