Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)
RFC 3983
Document | Type | RFC - Proposed Standard (January 2005; No errata) | |
---|---|---|---|
Authors | Marcos Sanz , Andrew Newton | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3983 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
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 mostShow full document text