Network Working Group A. Newton
Request for Comments: 3983 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
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)
通过块可扩展交换协议（BEEP）使用Internet注册表信息服务（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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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).
本文档指定如何使用块可扩展交换协议（BEEP）作为Internet注册表信息服务（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
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
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
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
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].
本文档中的建议描述了使用BEEP[2]的IRIS[6]应用程序传输绑定。CRISP[19]概述了本文件中IRIS和规范的要求。
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.
选择BEEP作为传输基板主要是因为需要重用现有的、充分理解的协议，该协议具有支持需求所需的所有功能。这将为实现者提供大量的工具箱和调试工具，用于构建服务器和客户端，并允许操作员在部署问题上应用现有经验。为IRIS的特定目的构建一个简单的应用程序传输将产生一个类似的标准，尽管在考虑到帧和身份验证等问题后可能更小、更不完整。
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 implementations.
在分层应用程序中使用其他传输机制的先例似乎不符合IRIS的设计目标。HTTP[15]提供了许多用于类似应用程序的功能。然而，IRIS并不打算用于绕过防火墙、混合URI方案或任何其他可能导致IRIS和传统万维网应用程序混淆的方法。除了遵守RFC 3205[16]中规定的指导原则外，HTTP的使用还带来了许多其他挑战，这些挑战很快削弱了它的吸引力。例如，RFC 2817[14]定义了TLS[4]与HTTP的适当使用，但RFC 2818[18]中描述的常用方法通常是大多数实现中的唯一方法。
Finally, the use of IRIS directly over TCP, such as that specified by EPP-TCP [17], does not offer the client negotiation characteristics needed by a referral application in which a single client, in processing a query, may traverse multiple servers operating with different parameters.
最后，直接在TCP上使用IRIS（如EPP-TCP[17]中指定的）不提供转介应用程序所需的客户端协商特性，在转介应用程序中，单个客户端在处理查询时可能会遍历使用不同参数运行的多个服务器。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[5]中的描述进行解释。
The BEEP profile identifier for IRIS is a URI composed of the IRIS schema URN, followed by a slash, followed by an IRIS registry type (which is a URN).
IRIS的BEEP配置文件标识符是一个URI，由IRIS模式URN、斜杠和IRIS注册表类型（URN）组成。
In this profile identifier, the IRIS schema MUST be abbreviated according to the rules of IRIS. This is possible because the IRIS schema URN is compliant with XML_URN [20].
在此配置文件标识符中，必须根据IRIS规则缩写IRIS模式。这是可能的，因为IRIS模式URN符合XML_URN[20]。
The registry type URN MUST be abbreviated according to the rules of IRIS (see [6]). This is possible because the registry type URN is compliant with XML_URN [20].
根据IRIS规则，注册表类型URN必须缩写（参见[6]）。这是可能的，因为注册表类型URN与XML_URN[20]兼容。
The following is an example of an IRIS profile identifier for BEEP. It identifies the version of IRIS to match that specified by "urn:iana:params:xml:ns:iris1" with a registry type URN of "urn:iana:params:xml:ns:dreg1":
以下是用于BEEP的虹膜配置文件标识符的示例。它标识IRIS的版本，以匹配“urn:iana:params:xml:ns:iris1”指定的版本和注册表类型urn为“urn:iana:params:xml:ns:dreg1”的版本：
http://iana.org/beep/iris1/dreg1
http://iana.org/beep/iris1/dreg1
The full ABNF [8] follows, with certain values included from IRIS [6]:
下面是完整的ABNF[8]，其中包含IRIS[6]中的某些值：
profile = profile-uri "/" iris-urn-abbrev
"/" registry-urn-abbrev
profile-uri = "http://iana.org/beep/"
iris-urn-abbrev = // as specified by IRIS
registry-urn-abbrev = // as specified by IRIS
profile = profile-uri "/" iris-urn-abbrev
"/" registry-urn-abbrev
profile-uri = "http://iana.org/beep/"
iris-urn-abbrev = // as specified by IRIS
registry-urn-abbrev = // as specified by IRIS
This URI is used in the "profile" element in BEEP during channel creation. According to the rules of BEEP, multiple "profile" elements may be offered, thus allowing negotiation of the version of IRIS to be used for every registry type being served.
在频道创建期间，此URI在BEEP中的“profile”元素中使用。根据BEEP的规则，可以提供多个“配置文件”元素，从而允许对提供服务的每个注册表类型使用IRIS版本进行协商。
Once this profile is accepted and the channel is created, the channel is considered ready to exchange IRIS messages. A server MUST honor queries for all advertised registry types on any channel opened with an IRIS profile URI.
一旦接受此配置文件并创建通道，通道即被视为准备好交换IRIS消息。服务器必须在使用IRIS配置文件URI打开的任何通道上接受对所有播发注册表类型的查询。
The BEEP profile for IRIS transmits XML [1] containing the requests and responses for IRIS registries. These XML instances MUST be encoded as Unicode [9] using the media-type of "application/xml" according to RFC 3023 [11].
IRIS的BEEP配置文件传输包含IRIS注册表请求和响应的XML[1]。根据RFC 3023[11]，这些XML实例必须使用媒体类型“application/XML”编码为Unicode[9]。
XML processors are obliged to recognize both UTF-8 and UTF-16 [9] encodings. XML allows mechanisms to identify and use other character encodings by means of the "encoding" attribute in the declaration. Absence of this attribute or a byte order mark (BOM) indicates a default of UTF-8 encoding. Thus, for compatibility reasons, and per RFC 2277 [12], use of UTF-8 is RECOMMENDED with this transport mapping. UTF-16 is OPTIONAL. Other encodings MUST NOT be used.
XML处理器必须同时识别UTF-8和UTF-16[9]编码。XML允许机制通过声明中的“encoding”属性来识别和使用其他字符编码。缺少此属性或字节顺序标记（BOM）表示默认的UTF-8编码。因此，出于兼容性原因，并根据RFC 2277[12]，建议在该传输映射中使用UTF-8。UTF-16是可选的。不得使用其他编码。
A registry type MAY define other message packages that are not IRIS XML instances (e.g., binary images referenced by an IRIS response).
注册表类型可以定义不是IRIS XML实例的其他消息包（例如，由IRIS响应引用的二进制图像）。
Because each registry type is defined by a separate BEEP profile (see [6]), each registry type MAY define a different message pattern. These patterns MUST be within the allowable scope of BEEP [2]. If a registry type does not explicitly define a message pattern, the default pattern is used (see Section 5.2).
由于每种注册表类型都是由单独的BEEP配置文件定义的（请参见[6]），因此每种注册表类型都可以定义不同的消息模式。这些模式必须在BEEP[2]的允许范围内。如果注册表类型未明确定义消息模式，则使用默认模式（请参阅第5.2节）。
However, each registry type MUST be capable of supporting the default pattern (Section 5.2) for use with the <lookupEntity> query in IRIS.
但是，每种注册表类型必须能够支持默认模式（第5.2节），以便与IRIS中的<lookupEntity>查询一起使用。
The default BEEP profile for IRIS only has a one-to-one request/ response message pattern. This exchange involves sending an IRIS XML instance, which results in a response of an IRIS XML instance.
IRIS的默认蜂鸣模式只有一对一的请求/响应消息模式。此交换涉及发送一个IRIS XML实例，这将导致IRIS XML实例的响应。
The client sends the request by using an "MSG" message containing a valid IRIS XML instance. The server responds with an "RPY" message containing a valid IRIS XML instance. The "ERR" message is used for sending fault codes. The list of allowable fault codes is listed in BEEP [2].
客户端使用包含有效IRISXML实例的“MSG”消息发送请求。服务器响应一条“RPY”消息，其中包含一个有效的irisxml实例。“ERR”消息用于发送故障代码。BEEP[2]中列出了允许的故障代码列表。
When the TLS [4] tuning profile in BEEP is used, it is possible to verify the authenticity of the server. However, a convention is needed to conduct this authentication. This convention dictates the name of the authority a client uses to ask for authentication credentials so that the server knows which set of credentials to pass back. Because this is dependent on the authority component of the URI, each registry type SHOULD define a server authentication method.
使用BEEP中的TLS[4]调优配置文件时，可以验证服务器的真实性。但是，需要一个约定来进行此身份验证。此约定指定客户端用于请求身份验证凭据的权限的名称，以便服务器知道要传回哪组凭据。因为这取决于URI的授权组件，所以每个注册表类型都应该定义一个服务器身份验证方法。
If a registry type does not explicitly define a server authentication method, the basic server authentication method (Section 6.2) is used.
如果注册表类型未明确定义服务器身份验证方法，则使用基本服务器身份验证方法（第6.2节）。
The basic server authentication method is as follows:
基本的服务器身份验证方法如下所示：
1. When connecting to a server, the client MUST present the name of the authority to the server by using the BEEP [2] serverName mechanism. For instance, if the URI "iris:dreg1//com/domain/ example.com" is being resolved, the client would use the serverName="com" attribute during the BEEP session instantiation.
1. 连接到服务器时，客户端必须使用BEEP[2]serverName机制向服务器提供授权的名称。例如，如果正在解析URI“iris:dreg1//com/domain/example.com”，则客户端将在BEEP会话实例化期间使用serverName=“com”属性。
2. During TLS negotiation, the server presents to the client a certificate for the authority given in serverName. This certificate MUST be an X.509 certificate [10]. This certificate MUST contain the authority in either the subjectDN or the subjectAltName extension of type dNSName.
2. 在TLS协商期间，服务器向客户机提供serverName中给定权限的证书。此证书必须是X.509证书[10]。此证书必须包含subjectDN或类型为dNSName的subjectAltName扩展中的权限。
3. The certificate MUST be cryptographically verified according to the procedures of TLS.
3. 证书必须按照TLS的程序进行加密验证。
4. The client then checks the subject of the certificate for a case insensitive match in the following order:
4. 然后，客户端按以下顺序检查证书的主题是否存在不区分大小写的匹配：
1. Any of the dNSName types in the subjectAltName. 2. The subjectDN consisting solely of 'dc' components, in which each 'dc' component represents a label from the authority name (e.g., example.com is dc=example, dc=com). 3. A subjectDN in which the left-most component is a 'cn' component containing the name of the authority. A wildcard character ('*') MAY be used as the left-most label of the name in the 'cn' component.
1. subjectAltName中的任何dNSName类型。2.subjectDN仅由“dc”组件组成，其中每个“dc”组件表示来自机构名称的标签（例如，example.com是dc=example，dc=com）。3.一种subjectDN，其中最左边的组件是包含授权机构名称的“cn”组件。通配符（“*”）可以用作“cn”组件中名称的最左侧标签。
If the subject of the certificate does not match any of these name components, then the certificate is invalid for representing the authority.
如果证书的主题与这些名称组件中的任何一个都不匹配，则该证书对于表示授权无效。
This section lists the definitions required by IRIS [6] for transport mappings.
本节列出了IRIS[6]对传输映射所需的定义。
The URI scheme name specific to BEEP over IRIS MUST be "iris.beep".
特定于BEEP over IRIS的URI方案名称必须为“IRIS.BEEP”。
The application protocol label MUST be "iris.beep".
应用程序协议标签必须为“iris.beep”。
See Sections 4 and 10.
见第4节和第10节。
The mapping of IRIS in this document is specific to RFC 3080 [2]. This mapping MUST use TCP as specified by RFC 3081 [3].
本文档中的IRIS映射特定于RFC 3080[2]。此映射必须使用RFC 3081[3]指定的TCP。
Profile Identification: http://iana.org/beep/iris1
Profile Identification: http://iana.org/beep/iris1
Messages exchanged during Channel Creation: none
通道创建期间交换的消息：无
Messages starting one-to-one exchanges: IRIS XML instance
开始一对一交换的消息：irisxml实例
Messages in positive replies: IRIS XML instance
肯定回复中的消息：IRIS XML实例
Messages in negative replies: none
否定回复中的消息：无
Messages in one-to-many exchanges: none
一对多交换中的消息：无
Message Syntax: IRIS XML instances as defined by IRIS [6]
消息语法：IRIS定义的IRIS XML实例[6]
Message Semantics: request/response exchanges as defined by IRIS [6]
消息语义：IRIS定义的请求/响应交换[6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
URL scheme name: iris.beep
URL方案名称：iris.beep
URL scheme syntax: defined in Section 7.1 and [6]
URL方案语法：在第7.1节和[6]中定义
Character encoding considerations: as defined in RFC 2396 [7]
字符编码注意事项：如RFC 2396[7]中所定义
Intended usage: identifies an IRIS entity made available using the BEEP profile for IRIS
预期用途：标识使用IRIS的BEEP配置文件提供的IRIS实体
Applications using this scheme: defined in IRIS [6]
使用此方案的应用程序：在IRIS[6]中定义
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 12.
安全注意事项：定义见第12节。
Relevant Publications: BEEP [2] and IRIS [6]
相关出版物：BEEP[2]和IRIS[6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Author/Change controller: the IESG
作者/变更控制员：IESG
Protocol Number: TCP
协议编号：TCP
Message Formats, Types, Opcodes, and Sequences: defined in Sections 3, 4, and 5.
消息格式、类型、操作码和序列：在第3、4和5节中定义。
Functions: defined in IRIS [6]
功能：在IRIS[6]中定义
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: IRIS over BEEP
建议名称：IRIS over BEEP
Short name: iris.beep
简称：iris.beep
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Application Protocol Label: iris.beep
应用程序协议标签：iris.beep
Intended usage: identifies an IRIS server using BEEP
预期用途：使用嘟嘟声识别IRIS服务器
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 12
安全注意事项：定义见第12节
Relevant Publications: BEEP [2] and IRIS [6]
相关出版物：BEEP[2]和IRIS[6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Author/Change controller: the IESG
作者/变更控制员：IESG
Specifications of registry types MUST include the following explicit definitions:
注册表类型的规范必须包括以下明确定义：
o message pattern -- a definition of the message pattern for use with BEEP, or a declaration to use the default message pattern in Section 5.2.
o 消息模式——与BEEP一起使用的消息模式定义，或第5.2节中使用默认消息模式的声明。
o server authentication method -- a definition of the method to use for server authentication with TLS, a declaration to use the basic server authentication method in Section 6.2, or a declaration to use no server authentication at all.
o 服务器身份验证方法——定义使用TLS进行服务器身份验证的方法，声明使用第6.2节中的基本服务器身份验证方法，或声明完全不使用服务器身份验证。
See Section 4.
见第4节。
Registrations with the IANA are described in Section 8.
IANA的注册情况见第8节。
Implementers should be fully aware of the security considerations given by IRIS [6], BEEP [2], and TLS [4]. With respect to server authentication with the use of TLS, see Section 6.
实现者应该充分了解IRIS[6]、BEEP[2]和TLS[4]给出的安全注意事项。关于使用TLS的服务器身份验证，请参见第6节。
Clients SHOULD be prepared to use the following BEEP tuning profiles:
客户端应准备好使用以下蜂鸣音调谐配置文件：
o http://iana.org/beep/SASL/DIGEST-MD5 -- for user authentication without the need of session encryption.
o http://iana.org/beep/SASL/DIGEST-MD5 --用于用户身份验证，无需会话加密。
o http://iana.org/beep/SASL/OTP -- for user authentication without the need of session encryption.
o http://iana.org/beep/SASL/OTP --用于用户身份验证，无需会话加密。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher -- for encryption.
o http://iana.org/beep/TLS 使用TLS_RSA_和_3DES_EDE_CBC_SHA密码进行加密。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-side certificates -- for encryption and user authentication.
o http://iana.org/beep/TLS 使用TLS_RSA_和_3DES_EDE_CBC_SHA密码以及客户端证书——进行加密和用户身份验证。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher -- for encryption. See [13].
o http://iana.org/beep/TLS 使用TLS_RSA_和_AES_128_CBC_SHA密码进行加密。见[13]。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side certificates -- for encryption and user authentication. See [13].
o http://iana.org/beep/TLS 使用TLS_RSA_和_AES_128_CBC_SHA密码以及客户端证书——进行加密和用户身份验证。见[13]。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher -- for encryption. See [13].
o http://iana.org/beep/TLS 使用TLS_RSA_和_AES_256_CBC_SHA密码进行加密。见[13]。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side certificates -- for encryption and user authentication. See [13].
o http://iana.org/beep/TLS 使用TLS_RSA_和_AES_256_CBC_SHA密码以及客户端证书——进行加密和用户身份验证。见[13]。
Anonymous client access SHOULD be considered in one of two methods:
应采用以下两种方法之一考虑匿名客户端访问：
1. When no authentication tuning profile has been used. 2. Using the SASL anonymous profile: http://iana.org/beep/SASL/ANONYMOUS
1. 未使用身份验证优化配置文件时。2.使用SASL匿名配置文件：http://iana.org/beep/SASL/ANONYMOUS
IRIS contains a referral mechanism as a standard course of operation. However, care should be taken that user authentication mechanisms do not hand user credentials to untrusted servers. Therefore, clients SHOULD NOT use the http://iana.org/beep/SASL/PLAIN tuning profile. As specified by SASL/PLAIN, clients MUST NOT use the http://iana.org/beep/SASL/PLAIN tuning profile without first encrypting the TCP session (e.g. such as with the http://iana.org/beep/TLS tuning profile).
IRIS包含一个转介机制，作为标准的操作过程。但是，应注意，用户身份验证机制不会将用户凭据传递给不受信任的服务器。因此，客户端不应使用http://iana.org/beep/SASL/PLAIN 调整配置文件。按照SASL/PLAIN的规定，客户端不得使用http://iana.org/beep/SASL/PLAIN 在不首先加密TCP会话的情况下优化配置文件（例如，使用http://iana.org/beep/TLS 调整配置文件）。
[1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[1] 万维网联盟，“可扩展标记语言（XML）1.0”，W3C XML，1998年2月<http://www.w3.org/TR/1998/REC-xml-19980210>.
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[3] Rose，M.“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[4] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[6] Newton，A.和M.Sanz，“IRIS：互联网注册信息服务（IRIS）核心协议”，RFC 3981，2005年1月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[9] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[9] Unicode联盟，“Unicode标准，第3版”，ISBN 0-201-61633-52000，<Unicode标准，第3版>。
[10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[10] Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[11] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[11] Murata，M.，Laurent，S.St.，和D.Kohn，“XML媒体类型”，RFC3023，2001年1月。
[12] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[12] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[13] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[14] Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[15] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[16] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[16] Moore，K.，“关于HTTP作为基板的使用”，BCP 56，RFC 3205，2002年2月。
[17] Hollenbeck, S., "EPP TCP Transport", Work in Progress, January 2002.
[17] Hollenbeck，S.，“EPP TCP传输”，正在进行的工作，2002年1月。
[18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[18] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[19] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004.
[19] Newton，A.，“跨注册互联网服务协议（CRISP）要求”，RFC 3707，2004年2月。
[20] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[20] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Andrew L.Newton VeriSign，Inc.美国弗吉尼亚州斯特林Ridgetop Circle 21345，邮编20166
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329德国法兰克福
EMail: sanz@denic.de
URI: http://www.denic.de/
EMail: sanz@denic.de
URI: http://www.denic.de/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。