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 | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) 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 most
Show full document text