Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)
RFC 3983

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                          A. Newton
Request for Comments: 3983                                VeriSign, Inc.
Category: Standards Track                                        M. Sanz
                                                                DENIC eG
                                                            January 2005

      Using the Internet Registry Information Service (IRIS) over
             the Blocks Extensible Exchange Protocol (BEEP)

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.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies how to use the Blocks Extensible Exchange
   Protocol (BEEP) as the application transport substrate for the
   Internet Registry Information Service (IRIS).

Table of Contents

   1.  Introduction and Motivations . . . . . . . . . . . . . . . . .  2
   2.  Document Terminology . . . . . . . . . . . . . . . . . . . . .  3
   3.  BEEP Profile Identification  . . . . . . . . . . . . . . . . .  3
   4.  IRIS Message Packages  . . . . . . . . . . . . . . . . . . . .  4
   5.  IRIS Message Patterns  . . . . . . . . . . . . . . . . . . . .  4
       5.1.  Registry Dependent Patterns. . . . . . . . . . . . . . .  4
       5.2.  Default Pattern. . . . . . . . . . . . . . . . . . . . .  4
   6.  Server Authentication Methods  . . . . . . . . . . . . . . . .  5
       6.1.  Registry Dependent Methods. . . . . . . .  . . . . . . .  5
       6.2.  Basic Server Authentication Method. . . .  . . . . . . .  5
   7.  IRIS Transport Mapping Definitions . . . . . . . . . . . . . .  6
       7.1.  URI Scheme . . . . . . . . . . . . . . . . . . . . . . .  6
       7.2.  Application Protocol Label . . . . . . . . . . . . . . .  6
       7.3.  Allowable Character Sets . . . . . . . . . . . . . . . .  6
       7.4.  BEEP Mapping . . . . . . . . . . . . . . . . . . . . . .  6
   8.  Registrations  . . . . . . . . . . . . . . . . . . . . . . . .  6
       8.1.  BEEP Profile Registration. . . . . . . . . . . . . . . .  6
       8.2.  URI Scheme Registration. . . . . . . . . . . . . . . . .  7

Newton & Sanz               Standards Track                     [Page 1]
RFC 3983                       IRIS-Beep                    January 2005

       8.3.  Well-Known TCP Port Registration . . . . . . . . . . . .  7
       8.4.  S-NAPTR Registration . . . . . . . . . . . . . . . . . .  8
   9.  Registry Definition Checklist  . . . . . . . . . . . . . . . .  8
   10. Internationalization Considerations  . . . . . . . . . . . . .  8
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   12. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       13.1. Normative References . . . . . . . . . . . . . . . . . . 10
       13.2. Informative References . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12

1.  Introduction and Motivations

   The proposal in this document describes the IRIS [6] application
   transport binding that uses BEEP [2].  Requirements for IRIS and the
   specification in this document are outlined in CRISP [19].

   The choice of BEEP as the transport substrate is primarily driven by
   the need to reuse an existing, well-understood protocol with all the
   necessary features to support the requirements.  This would give
   implementers a wealth of toolkits and debugging gear for use in
   constructing both servers and clients and allow operators to apply
   existing experience in issues of deployment.  The construction of a
   simple application transport for the specific purpose of IRIS would
   yield a similar standard, though likely smaller and less complete,
   after taking into consideration matters such as framing and
   authentication.

   Precedents for using other transport mechanisms in layered
   applications do not seem to fit with the design goals of IRIS.  HTTP
   [15] offers many features employed for use by similar applications.
   However, IRIS is not intended to be put to uses such as bypassing
   firewalls, commingling URI schemes, or any other methods that might
   lead to confusion between IRIS and traditional World Wide Web
   applications.  Beyond adhering to the guidelines spelled out in RFC
   3205 [16], the use of HTTP also offers many other challenges that
   quickly erode its appeal.  For example, the appropriate use of TLS
   [4] with HTTP is defined by RFC 2817 [14], but the common use, as
   described in RFC 2818 [18], is usually the only method in most