datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)
RFC 5144

Document type: RFC - Proposed Standard (February 2008; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5144 (Proposed Standard)
Responsible AD: Chris Newman
Send notices to: crisp-chairs@tools.ietf.org, sanz@denic.de

Network Working Group                                          A. Newton
Request for Comments: 5144        American Registry for Internet Numbers
Category: Standards Track                                        M. Sanz
                                                                DENIC eG
                                                           February 2008

         A Domain Availability Check (DCHK) Registry Type for
            the Internet Registry Information Service (IRIS)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes a lightweight domain availability service
   using the Internet Registry Information Service (IRIS) framework and
   the data model of the IRIS Domain Registry (DREG) service.

Newton & Sanz               Standards Track                     [Page 1]
RFC 5144                       IRIS-DCHK                   February 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Document Terminology . . . . . . . . . . . . . . . . . . . . .  3
   3.  Domain Availability Check Registry . . . . . . . . . . . . . .  3
     3.1.  Schema Description . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  The <domain> Result  . . . . . . . . . . . . . . . . .  4
       3.1.2.  Support for <iris:lookupEntity>  . . . . . . . . . . .  7
     3.2.  DCHK Formal XML Syntax . . . . . . . . . . . . . . . . . .  7
     3.3.  Blocks Extensible Exchange Protocol (BEEP) Transport
           Compliance . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.3.1.  Message Pattern  . . . . . . . . . . . . . . . . . . . 12
       3.3.2.  Server Authentication  . . . . . . . . . . . . . . . . 12
     3.4.  URI Resolution . . . . . . . . . . . . . . . . . . . . . . 13
       3.4.1.  Application Service Label  . . . . . . . . . . . . . . 13
       3.4.2.  Bottom-Up Resolution . . . . . . . . . . . . . . . . . 13
       3.4.3.  Top-Down Resolution  . . . . . . . . . . . . . . . . . 13
   4.  Internationalization Considerations  . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  XML Namespace Registration . . . . . . . . . . . . . . . . 14
     5.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 14
     5.3.  S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 14
     5.4.  BEEP Registration  . . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 16

Newton & Sanz               Standards Track                     [Page 2]
RFC 5144                       IRIS-DCHK                   February 2008

1.  Introduction

   This document describes a lightweight service for checking the
   availability of domain names.  This service is based on the IRIS
   framework and uses the data model defined by RFC 3982 [7].  By doing
   this, the domain availability service has the advantages provided by
   IRIS and DREG, such as well-known methods for server navigation,
   structured queries and results, and layered extensibility.

   The use of IRIS for this service also allows seamless integration
   between the domain availability service and the service provided by
   DREG.  This allows a user to find the availability status of a domain
   and reference the full registration information in DREG.

   The data model in this service (called a registry schema in IRIS
   terms) is a strict subset of the DREG data model.  This enables
   implementors to directly reuse DREG code paths and allows operators
   to deploy the service in either the same server processes as a DREG
   service (same host and port) or in a different server process
   (different port) or machine (different host).

   As an example, an operator may wish to deploy both types of service
   on the same set of machines.  As time goes on, the operator may then
   decide to segregate the services, placing the domain availability
   service on one set of machines and the DREG service on a separate set
   of machines with a stricter set of controls.  Either deployment
   scenario is transparent to the end user and always appears to be
   seamlessly complementary.

   When coupled with [9], this domain availability service is

[include full document text]