Network Working Group M. Rose
Request For Comments: 3080 Invisible Worlds, Inc.
Category: Standards Track March 2001
Network Working Group M. Rose
Request For Comments: 3080 Invisible Worlds, Inc.
Category: Standards Track March 2001
The Blocks Extensible Exchange Protocol Core
块可扩展交换协议核心
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
本备忘录描述了一个用于面向连接的异步交互的通用应用程序协议内核，称为BEEP（块可扩展交换协议）内核。BEEP允许在单个应用程序用户身份的上下文中进行同时和独立的交换，同时支持文本和二进制消息。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6
2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 23
2.4 Session Establishment and Release . . . . . . . . . . . . 25
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 27
2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 28
2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 28
2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 29
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 30
3. Transport Security . . . . . . . . . . . . . . . . . . . . 31
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 34
3.1.1 Profile Identification and Initialization . . . . . . . . 34
3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 36
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 36
4. User Authentication . . . . . . . . . . . . . . . . . . . 37
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 38
4.1.1 Profile Identification and Initialization . . . . . . . . 39
4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 43
5. Registration Templates . . . . . . . . . . . . . . . . . . 44
5.1 Profile Registration Template . . . . . . . . . . . . . . 44
5.2 Feature Registration Template . . . . . . . . . . . . . . 44
6. Initial Registrations . . . . . . . . . . . . . . . . . . 45
6.1 Registration: BEEP Channel Management . . . . . . . . . . 45
6.2 Registration: TLS Transport Security Profile . . . . . . . 45
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6
2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 23
2.4 Session Establishment and Release . . . . . . . . . . . . 25
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 27
2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 28
2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 28
2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 29
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 30
3. Transport Security . . . . . . . . . . . . . . . . . . . . 31
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 34
3.1.1 Profile Identification and Initialization . . . . . . . . 34
3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 36
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 36
4. User Authentication . . . . . . . . . . . . . . . . . . . 37
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 38
4.1.1 Profile Identification and Initialization . . . . . . . . 39
4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 43
5. Registration Templates . . . . . . . . . . . . . . . . . . 44
5.1 Profile Registration Template . . . . . . . . . . . . . . 44
5.2 Feature Registration Template . . . . . . . . . . . . . . 44
6. Initial Registrations . . . . . . . . . . . . . . . . . . 45
6.1 Registration: BEEP Channel Management . . . . . . . . . . 45
6.2 Registration: TLS Transport Security Profile . . . . . . . 45
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46
6.4 Registration: application/beep+xml . . . . . . . . . . . . 47
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 48
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 50
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 51
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . 53
References . . . . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . 55
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 58
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46
6.4 Registration: application/beep+xml . . . . . . . . . . . . 47
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 48
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 50
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 51
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . 53
References . . . . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . 55
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 58
This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP.
This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP.translate error, please retry
At BEEP's core is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. Messages are arbitrary MIME [1] content, but are usually textual (structured using XML [2]).
BEEP的核心是一个框架机制，允许对等方之间同时独立地交换消息。消息是任意MIME[1]内容，但通常是文本（使用XML[2]结构化）。
All exchanges occur in the context of a channel -- a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange.
所有交换都发生在通道的上下文中——绑定到应用程序的一个定义良好的方面，如传输安全性、用户身份验证或数据交换。
Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BEEP is the notion of channel management. In addition to defining BEEP's channel management profile, this document defines:
每个通道都有一个关联的“概要文件”，它定义了所交换消息的语法和语义。BEEP操作中隐含着通道管理的概念。除了定义BEEP的频道管理配置文件外，本文档还定义：
o the TLS [3] transport security profile; and,
o TLS[3]传输安全配置文件；和
o the SASL [4] family of profiles.
o SASL[4]系列配置文件。
Other profiles, such as those used for data exchange, are defined by an application protocol designer.
其他配置文件（如用于数据交换的配置文件）由应用程序协议设计器定义。
A BEEP session is mapped onto an underlying transport service. A separate series of documents describe how a particular transport service realizes a BEEP session. For example, [5] describes how a BEEP session is mapped onto a single TCP [6] connection.
BEEP会话映射到基础传输服务。另一系列文档描述了特定传输服务如何实现BEEP会话。例如，[5]描述了一个BEEP会话如何映射到一个TCP[6]连接上。
When a session is established, each BEEP peer advertises the profiles it supports. Later on, during the creation of a channel, the client supplies one or more proposed profiles for that channel. If the server creates the channel, it selects one of the profiles and sends it in a reply; otherwise, it may indicate that none of the profiles are acceptable, and decline creation of the channel.
建立会话时，每个BEEP对等方都会公布其支持的配置文件。稍后，在创建频道的过程中，客户端为该频道提供一个或多个建议的概要文件。如果服务器创建通道，它将选择其中一个配置文件并在应答中发送它；否则，它可能指示所有配置文件都不可接受，并拒绝创建通道。
Channel usage falls into one of two categories:
频道使用分为两类：
initial tuning: these are used by profiles that perform initialization once the BEEP session is established (e.g., negotiating the use of transport security); although several exchanges may be required to perform the initialization, these channels become inactive early in the BEEP session and remain so for the duration.
初始调整：一旦建立了BEEP会话（例如，协商传输安全性的使用），配置文件将使用这些配置文件执行初始化；尽管执行初始化可能需要几次交换，但这些通道在蜂鸣音会话的早期变为非活动状态，并在整个过程中保持不活动状态。
continuous: these are used by profiles that support data exchange; typically, these channels are created after the initial tuning channels have gone quiet.
连续：这些用于支持数据交换的概要文件；通常，这些通道是在初始调谐通道安静后创建的。
Note that because of their special nature, only one tuning channel may be established at any given time; in contrast, BEEP allows multiple data exchange channels to be simultaneously in use.
注意，由于其特殊性质，在任何给定时间只能建立一个调谐通道；相反，BEEP允许同时使用多个数据交换通道。
Although BEEP is peer-to-peer, it is convenient to label each peer in the context of the role it is performing at a given time:
虽然BEEP是点对点的，但在给定时间内，在其执行的角色的上下文中标记每个对等方是很方便的：
o When a BEEP session is established, the peer that awaits new connections is acting in the listening role, and the other peer, which establishes a connection to the listener, is acting in the initiating role. In the examples which follow, these are referred to as "L:" and "I:", respectively.
o 建立BEEP会话时，等待新连接的对等方将扮演侦听角色，另一个与侦听器建立连接的对等方将扮演发起角色。在下面的示例中，这些分别称为“L:”和“I:”。
o A BEEP peer starting an exchange is termed the client; similarly, the other BEEP peer is termed the server. In the examples which follow, these are referred to as "C:" and "S:", respectively.
o 启动交换的哔哔声对等被称为客户端；类似地，另一个BEEP对等被称为服务器。在下面的示例中，它们分别被称为“C:”和“S:”。
Typically, a BEEP peer acting in the server role is also acting in a listening role. However, because BEEP is peer-to-peer in nature, no such requirement exists.
通常，担任服务器角色的BEEP对等机也担任侦听角色。然而，由于BEEP本质上是点对点的，因此不存在这样的要求。
BEEP allows three styles of exchange:
BEEP允许三种类型的交换：
MSG/RPY: the client sends a "MSG" message asking the server to perform some task, the server performs the task and replies with a "RPY" message (termed a positive reply).
MSG/RPY：客户机发送一条“MSG”消息，要求服务器执行某项任务，服务器执行该任务并回复一条“RPY”消息（称为肯定回复）。
MSG/ERR: the client sends a "MSG" message, the server does not perform any task and replies with an "ERR" message (termed a negative reply).
MSG/ERR：客户机发送一条“MSG”消息，服务器不执行任何任务，并用一条“ERR”消息进行回复（称为否定回复）。
MSG/ANS: the client sends a "MSG" message, the server, during the course of performing some task, replies with zero or more "ANS" messages, and, upon completion of the task, sends a "NUL" message, which signifies the end of the reply.
MSG/ANS：客户机发送一条“MSG”消息，服务器在执行某项任务的过程中，回复零条或多条“ANS”消息，任务完成后，发送一条“NUL”消息，表示回复结束。
The first two styles are termed one-to-one exchanges, whilst the third style is termed a one-to-many exchange.
前两种类型称为一对一交换，而第三种类型称为一对多交换。
A message is structured according to the rules of MIME. Accordingly, each message may begin with "entity-headers" (c.f., MIME's Section 3 [1]). If none, or only some, of the "entity-headers" are present:
消息是根据MIME规则构造的。因此，每条消息可以以“实体头”开头（c.f.，MIME第3[1]节）。如果不存在或仅存在部分“实体标题”：
o the default "Content-Type" is "application/octet-stream"; and,
o 默认的“内容类型”为“应用程序/八位字节流”；和
o the default "Content-Transfer-Encoding" is "binary".
o 默认的“内容传输编码”是“二进制”。
Normally, a message is sent in a single frame. However, it may be convenient or necessary to segment a message into multiple frames (e.g., if only part of a message is ready to be sent).
通常，消息是在单个帧中发送的。然而，将消息分为多个帧可能是方便的或必要的（例如，如果只有一部分消息准备好发送）。
Each frame consists of a header, the payload, and a trailer. The header and trailer are each represented using printable ASCII characters and are terminated with a CRLF pair. Between the header and the trailer is the payload, consisting of zero or more octets.
每个机架包括一个收割台、有效负载和一个拖车。页眉和尾部分别使用可打印的ASCII字符表示，并以CRLF对终止。在收割台和拖车之间是有效载荷，由零个或多个八位字节组成。
For example, here is a message contained in a single frame that contains a payload of 120 octets spread over 5 lines (each line is terminated with a CRLF pair):
例如，这里是包含在单个帧中的消息，该帧包含120个八位字节的有效负载，分布在5条线路上（每条线路以CRLF对终止）：
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
In this example, note that the entire message is represented in a single frame.
在本例中，请注意，整个消息在单个帧中表示。
The ABNF [7] for a frame is:
帧的ABNF[7]为：
frame = data / mapping
frame = data / mapping
data = header payload trailer
data = header payload trailer
header = msg / rpy / err / ans / nul
header = msg / rpy / err / ans / nul
msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF
msg=“msg”SP common CR LF rpy=“rpy”SP common CR LF ans=“ans”SP common SP ansno CR LF err=“err”SP common CR LF nul=“nul”SP common CR LF
common = channel SP msgno SP more SP seqno SP size
channel = 0..2147483647
msgno = 0..2147483647
more = "." / "*"
seqno = 0..4294967295
size = 0..2147483647
ansno = 0..2147483647
common = channel SP msgno SP more SP seqno SP size
channel = 0..2147483647
msgno = 0..2147483647
more = "." / "*"
seqno = 0..4294967295
size = 0..2147483647
ansno = 0..2147483647
payload = *OCTET
payload = *OCTET
trailer = "END" CR LF
拖车=“结束”CR左前
mapping = ;; each transport mapping may define additional frames
mapping = ;; each transport mapping may define additional frames
The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each component. The header is terminated with a CRLF pair.
帧头由三个字符的关键字组成（其中一个是：“MSG”、“RPY”、“ERR”、“ANS”或“NUL”），后跟零个或多个参数。单个空格字符（十进制代码32“”）分隔每个组件。标头以CRLF对终止。
The channel number ("channel") must be a non-negative integer (in the range 0..2147483647).
通道号（“通道”）必须是非负整数（范围为0..2147483647）。
The message number ("msgno") must be a non-negative integer (in the range 0..2147483647) and have a different value than all other "MSG" messages on the same channel for which a reply has not been completely received.
消息编号（“msgno”）必须是非负整数（范围为0..2147483647），并且与未完全收到回复的同一通道上的所有其他“MSG”消息具有不同的值。
The continuation indicator ("more", one of: decimal code 42, "*", or decimal code 46, ".") specifies whether this is the final frame of the message:
连续指示符（“更多”，十进制代码42、*”或十进制代码46、“.”中的一个）指定这是否是消息的最后一帧：
intermediate ("*"): at least one other frame follows for the message; or,
中间（“*”）：消息后面至少有一个其他帧；或
complete ("."): this frame completes the message.
完成（“.”）：此框架完成消息。
The sequence number ("seqno") must be a non-negative integer (in the range 0..4294967295) and specifies the sequence number of the first octet in the payload, for the associated channel (c.f., Section 2.2.1.2).
序列号（“seqno”）必须是非负整数（范围为0..4294967295），并指定有效负载中第一个八位组的序列号，用于相关信道（c.f.，第2.2.1.2节）。
The payload size ("size") must be a non-negative integer (in the range 0..2147483647) and specifies the exact number of octets in the payload. (This does not include either the header or trailer.)
有效负载大小（“大小”）必须是非负整数（范围为0..2147483647），并指定有效负载中的八位字节的确切数目。（这不包括收割台或拖车。）
Note that a frame may have an empty payload, e.g.,
请注意，帧可能具有空有效载荷，例如。，
S: RPY 0 1 * 287 20
S: ...
S: ...
S: END
S: RPY 0 1 . 307 0
S: END
S: RPY 0 1 * 287 20
S: ...
S: ...
S: END
S: RPY 0 1 . 307 0
S: END
The answer number ("ansno") must be a non-negative integer (in the range 0..4294967295) and must have a different value than all other answers in progress for the message being replied to.
应答号（“ansno”）必须是非负整数（范围为0..4294967295），并且必须具有与正在应答的邮件的所有其他正在进行的应答不同的值。
There are two kinds of frames: data and mapping. Each transport mapping (c.f., Section 2.5) may define its own frames. For example, [5] defines the SEQ frame. The remainder of this section discusses data frames.
有两种帧：数据帧和映射帧。每个传输映射（c.f.，第2.5节）可以定义自己的帧。例如，[5]定义了SEQ帧。本节的其余部分将讨论数据帧。
When a message is segmented and sent as several frames, those frames must be sent sequentially, without any intervening frames from other messages on the same channel. However, there are two exceptions: first, no restriction is made with respect to the interleaving of frames for other channels; and, second, in a one-to-many exchange, multiple answers may be simultaneously in progress. Accordingly, frames for "ANS" messages may be interleaved on the same channel -- the answer number is used for collation, e.g.,
当一条消息被分割并作为多个帧发送时，这些帧必须按顺序发送，而不会有来自同一通道上其他消息的任何中间帧。然而，有两个例外：第一，对于其他信道的帧的交织没有限制；其次，在一对多的交换中，多个答案可能同时进行。因此，“ANS”消息的帧可以在同一信道上交错-应答号用于排序，例如。，
S: ANS 1 0 * 0 20 0
S: ...
S: ...
S: END
S: ANS 1 0 * 20 20 1
S: ...
S: ...
S: END
S: ANS 1 0 . 40 10 0
S: ...
S: END
S: ANS 1 0 * 0 20 0
S: ...
S: ...
S: END
S: ANS 1 0 * 20 20 1
S: ...
S: ...
S: END
S: ANS 1 0 . 40 10 0
S: ...
S: END
which shows two "ANS" messages interleaved on channel 1 as part of a reply to message number 0. Note that the sequence number is advanced for each frame sent on the channel, and is independent of the messages sent in those frames.
它显示两条“ANS”消息在通道1上交错，作为对消息编号0的答复的一部分。请注意，对于通道上发送的每个帧，序列号都是高级的，并且与在这些帧中发送的消息无关。
There are several rules for identifying poorly-formed frames:
有几种规则可用于识别形状不良的框架：
o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or "NUL";
o 如果标题不是以“MSG”、“RPY”、“ERR”、“ANS”或“NUL”开头；
o if any of the parameters in the header cannot be determined or are invalid (i.e., syntactically incorrect);
o 如果标题中的任何参数无法确定或无效（即语法错误）；
o if the value of the channel number doesn't refer to an existing channel;
o 如果通道编号的值不涉及现有通道；
o if the header starts with "MSG", and the message number refers to a "MSG" message that has been completely received but for which a reply has not been completely sent;
o 如果报头以“MSG”开头，且消息编号指已完全接收但尚未完全发送回复的“MSG”消息；
o if the header doesn't start with "MSG", and refers to a message number for which a reply has already been completely received;
o 如果报头不是以“MSG”开头，而是指已经完全收到回复的消息编号；
o if the header doesn't start with "MSG", and refers to a message number that has never been sent (except during session establishment, c.f., Section 2.3.1.1);
o 如果报头不是以“MSG”开头，而是指从未发送过的消息编号（会话建立期间除外，c.f.，第2.3.1.1节）；
o if the header starts with "MSG", "RPY", "ERR", or "ANS", and refers to a message number for which at least one other frame has been received, and the three-character keyword starting this frame and the immediately-previous received frame for this message number are not identical;
o 如果报头以“MSG”、“RPY”、“ERR”或“ANS”开头，并指已收到至少一个其他帧的消息编号，且开始此帧的三字符关键字与此消息编号的前一个接收帧不相同；
o if the header starts with "NUL", and refers to a message number for which at least one other frame has been received, and the keyword of of the immediately-previous received frame for this reply isn't "ANS";
o 如果报头以“NUL”开头，并指已收到至少一个其他帧的消息编号，且该回复的前一个接收帧的关键字不是“ANS”；
o if the continuation indicator of the previous frame received on the same channel was intermediate ("*"), and its message number isn't identical to this frame's message number;
o 如果在同一通道上接收的前一帧的继续指示符为中间（“*”），且其消息编号与此帧的消息编号不相同；
o if the value of the sequence number doesn't correspond to the expected value for the associated channel (c.f., Section 2.2.1.2); or,
o 如果序列号的值与相关信道的预期值不一致（c.f.，第2.2.1.2节）；或
o if the header starts with "NUL", and the continuation indicator is intermediate ("*") or the payload size is non-zero.
o 如果报头以“NUL”开头，且延续指示符为中间（“*”）或有效负载大小为非零。
If a frame is poorly-formed, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
如果帧格式不良，则会话将在不生成响应的情况下终止，建议记录诊断条目。
The frame payload consists of zero or more octets.
帧有效负载由零个或多个八位字节组成。
Every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively. (When a channel is created, the sequence number associated with the first payload octet of the first frame is 0.)
在信道的每个方向上发送的每个有效负载八位组都有一个相关的序列号。帧内有效载荷八位字节的编号应确保第一个有效载荷八位字节是编号最低的，并且后续有效载荷八位字节是连续编号的。（创建信道时，与第一帧的第一个有效负载八位字节相关联的序列号为0。）
The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of [8] for a discussion of the arithmetic properties of sequence numbers.
实际的序列号空间是有限的，尽管非常大，范围在0..4294967295（2**32-1）之间。由于空间是有限的，所有处理序列号的算法都是以模2**32执行的。当序列号再次从2**32-1循环到0时，此无符号算术保留序列号之间的关系。有关序列号算术特性的讨论，请参阅[8]第2节至第5节。
When receiving a frame, the sum of its sequence number and payload size, modulo 4294967296 (2**32), gives the expected sequence number associated with the first payload octet of the next frame received. Accordingly, when receiving a frame if the sequence number isn't the expected value for this channel, then the BEEP peers have lost synchronization, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
接收帧时，其序列号和有效负载大小之和（模4294967296（2**32））给出与接收到的下一帧的第一个有效负载八位组相关联的预期序列号。因此，当接收到帧时，如果序列号不是此通道的预期值，则BEEP对等方已失去同步，然后会话在不生成响应的情况下终止，建议记录诊断条目。
The frame trailer consists of "END" followed by a CRLF pair.
车架拖车由“端部”和CRLF对组成。
When receiving a frame, if the characters immediately following the payload don't correspond to a trailer, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
接收帧时，如果有效负载后面的字符与拖车不对应，则会话将在不生成响应的情况下终止，建议记录诊断条目。
The semantics of each message is channel-specific. Accordingly, the profile associated with a channel must define:
每个消息的语义都是特定于通道的。因此，与通道关联的配置文件必须定义：
o the initialization messages, if any, exchanged during channel creation;
o 通道创建期间交换的初始化消息（如有）；
o the messages that may be exchanged in the payload of the channel; and,
o 可在信道的有效载荷中交换的消息；和
o the semantics of these messages.
o 这些消息的语义。
A profile registration template (Section 5.1) organizes this information.
配置文件注册模板（第5.1节）组织此信息。
When defining the behavior of the profile, the template must specify how poorly-formed "MSG" messages are replied to. For example, the channel management profile sends a negative reply containing an error message (c.f., Section 2.3.1.5).
在定义概要文件的行为时，模板必须指定如何回复格式错误的“MSG”消息。例如，信道管理配置文件发送包含错误消息的否定回复（c.f.，第2.3.1.5节）。
If a poorly-formed reply is received on channel zero, the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
如果在通道0上收到格式错误的回复，会话将在不生成响应的情况下终止，建议记录诊断条目。
If a poorly-formed reply is received on another channel, then the channel must be closed using the procedure in Section 2.3.1.3.
如果在另一个通道上收到格式不良的回复，则必须使用第2.3.1.3节中的程序关闭该通道。
When a BEEP session starts, only channel number zero is defined, which is used for channel management. Section 6.1 contains the profile registration for BEEP channel management.
当蜂鸣音会话启动时，仅定义用于通道管理的通道号0。第6.1节包含BEEP通道管理的配置文件注册。
Channel management allows each BEEP peer to advertise the profiles that it supports (c.f., Section 2.3.1.1), bind an instance of one of those profiles to a channel (c.f., Section 2.3.1.2), and then later close any channels or release the BEEP session (c.f., Section 2.3.1.3).
通道管理允许每个BEEP对等方公布其支持的配置文件（c.f.，第2.3.1.1节），将其中一个配置文件的实例绑定到通道（c.f.，第2.3.1.2节），然后关闭任何通道或释放BEEP会话（c.f.，第2.3.1.3节）。
A BEEP peer should support at least 257 concurrent channels.
BEEP对等机应至少支持257个并发通道。
When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero that contains a "greeting" element, e.g.,
建立BEEP会话时，每个BEEP对等方通过立即发送包含“问候”元素的消息编号为零的肯定回复来表示其可用性，例如。，
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Note that this example implies that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends its greeting -- this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.
请注意，这个示例意味着发起角色中的BEEP peer将等待，直到侦听角色中的BEEP peer发送其问候语——这是表示的一个工件；事实上，两个BEEP节点都独立发送回复。
The "greeting" element has two optional attributes ("features" and "localize") and zero or more "profile" elements, one for each profile supported by the BEEP peer acting in a server role:
“greeting”元素有两个可选属性（“features”和“localize”）和零个或多个“profile”元素，每个profile元素一个，由担任服务器角色的BEEP对等方支持：
o the "features" attribute, if present, contains one or more feature tokens, each indicating an optional feature of the channel management profile supported by the BEEP peer;
o “features”（功能）属性（如果存在）包含一个或多个功能标记，每个标记表示BEEP对等方支持的通道管理配置文件的可选功能；
o the "localize" attribute, if present, contains one or more language tokens (defined in [9]), each identifying a desirable language tag to be used by the remote BEEP peer when generating textual diagnostics for the "close" and "error" elements (the tokens are ordered from most to least desirable); and,
o “localize”属性（如果存在）包含一个或多个语言标记（在[9]中定义），每个标记标识远程BEEP对等方在为“close”和“error”元素生成文本诊断时要使用的理想语言标记（标记按从最理想到最不理想的顺序排列）；和
o each "profile" element contained within the "greeting" element identifies a profile, and unlike the "profile" elements that occur within the "start" element, the content of each "profile" element may not contain an optional initialization message.
o “greeting”元素中包含的每个“profile”元素标识一个概要文件，与“start”元素中出现的“profile”元素不同，每个“profile”元素的内容可能不包含可选的初始化消息。
Section 5.2 defines a registration template for optional features.
第5.2节定义了可选功能的注册模板。
When a BEEP peer wants to create a channel, it sends a "start" element on channel zero, e.g.,
当一个蜂鸣节点想要创建一个通道时，它会在通道0上发送一个“开始”元素，例如。，
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
The "start" element has a "number" attribute, an optional "serverName" attribute, and one or more "profile" elements:
“start”元素有一个“number”属性、一个可选的“serverName”属性和一个或多个“profile”元素：
o the "number" attribute indicates the channel number (in the range 1..2147483647) used to identify the channel in future messages;
o “number”属性表示用于在将来的消息中标识通道的通道号（范围为1..2147483647）；
o the "serverName" attribute, an arbitrary string, indicates the desired server name for this BEEP session; and,
o “serverName”属性是一个任意字符串，表示此BEEP会话所需的服务器名称；和
o each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content:
o “start”元素包含的每个“profile”元素都有一个“uri”属性、一个可选的“encoding”属性和任意字符数据作为内容：
* the "uri" attribute authoritatively identifies the profile;
* “uri”属性权威性地标识概要文件；
* the "encoding" attribute, if present, specifies whether the content of the "profile" element is represented as a base64- encoded string; and,
* “encoding”属性（如果存在）指定“profile”元素的内容是否表示为base64编码的字符串；和
* the content of the "profile" element, if present, must be no longer than 4K octets in length and specifies an initialization message given to the channel as soon as it is created.
* “profile”元素的内容（如果存在）长度不得超过4K八位字节，并指定在创建通道后立即发送给通道的初始化消息。
To avoid conflict in assigning channel numbers when requesting the creation of a channel, BEEP peers acting in the initiating role use only positive integers that are odd-numbered; similarly, BEEP peers acting in the listening role use only positive integers that are even-numbered.
为避免在请求创建通道时分配通道号时发生冲突，担任发起角色的BEEP对等方仅使用奇数正整数；类似地，担任侦听角色的BEEP对等方仅使用偶数的正整数。
The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in a negative reply.
BEEP对等方接收到的第一个成功的“start”元素的“serverName”属性在BEEP会话期间是有意义的。如果存在，则BEEP对等方决定是否按照指示的“服务器名称”操作；如果不是，则在否定应答中发送“error”元素。
When a BEEP peer receives a "start" element on channel zero, it examines each of the proposed profiles, and decides whether to use one of them to create the channel. If so, the appropriate "profile" element is sent in a positive reply; otherwise, an "error" element is sent in a negative reply.
当BEEP对等方在通道0上接收到“开始”元素时，它将检查每个建议的配置文件，并决定是否使用其中一个来创建通道。如果是，则以肯定的答复发送适当的“profile”元素；否则，在否定应答中发送“error”元素。
When creating the channel, the value of the "serverName" attribute from the first successful "start" element is consulted to provide configuration information, e.g., the desired server-side certificate when starting the TLS transport security profile (Section 3.1).
创建通道时，参考第一个成功的“启动”元素的“serverName”属性值，以提供配置信息，例如，启动TLS传输安全配置文件时所需的服务器端证书（第3.1节）。
For example, a successful channel creation might look like this:
例如，成功创建频道可能如下所示：
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END
Similarly, an unsuccessful channel creation might look like this:
类似地，不成功的频道创建可能如下所示：
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='2'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: ERR 0 1 . 221 127
S: Content-Type: application/beep+xml
S:
S: <error code='501'>number attribute
S: in <start> element must be odd-valued</error>
S: END
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='2'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: ERR 0 1 . 221 127
S: Content-Type: application/beep+xml
S:
S: <error code='501'>number attribute
S: in <start> element must be odd-valued</error>
S: END
Finally, here's an example in which an initialization element is exchanged during channel creation:
最后，下面是一个示例，其中在通道创建期间交换初始化元素：
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]>
S: </profile>
S: END
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]>
S: </profile>
S: END
When a BEEP peer wants to close a channel, it sends a "close" element on channel zero, e.g.,
当一个蜂鸣声对等方想要关闭一个通道时，它会在通道0上发送一个“关闭”元素，例如。，
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
The "close" element has a "number" attribute, a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content:
“close”元素有一个“number”属性、“code”属性、一个可选的“xml:lang”属性和一个可选的文本诊断作为其内容：
o the "number" attribute indicates the channel number;
o “编号”属性表示通道编号；
o the "code" attribute is a three-digit reply code meaningful to programs (c.f., Section 8);
o “代码”属性是对程序有意义的三位数回复代码（c.f.，第8节）；
o the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and,
o “xml:lang”属性标识元素内容所用的语言（该值是由远程BEEP对等方发送的“greeting”元素的“localize”属性建议的，但不是强制的）；和
o the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs.
o 文本诊断（可能是多行的）对实现者，可能是管理员，甚至可能是用户都有意义，但对程序却没有意义。
Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used.
请注意，如果存在文本诊断，则只有在使用作为远程蜂鸣器对等方的首选语言时，“xml:lang”属性才不存在。
If the value of the "number" attribute is zero, then the BEEP peer wants to release the BEEP session (c.f., Section 2.4) -- otherwise the value of the "number" attribute refers to an existing channel, and the remainder of this section applies.
如果“number”属性的值为零，则BEEP对等方希望释放BEEP会话（c.f.，第2.4节）——否则，“number”属性的值指的是现有通道，本节其余部分适用。
A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".)
只要一个蜂鸣器在该通道上发送的所有“MSG”消息都得到确认，蜂鸣器对等方就可以为该通道发送一条“关闭”消息。（确认包括发送消息“message”的BEEP对等方收到的回复的第一帧。）
After sending the "close" message, that BEEP peer must not send any more "MSG" messages on that channel being closed until the reply to the "close" message has been received (either by an "error" message rejecting the request to close the channel, or by an "ok" message subsequently followed by the channel being successfully started).
发送“关闭”消息后，在收到对“关闭”消息的回复之前，该BEEP对等方不得在正在关闭的通道上再发送任何“MSG”消息（通过拒绝关闭通道请求的“错误”消息，或通过随后成功启动通道的“确定”消息）。
NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel.
请注意：在收到关闭通道请求的肯定答复之前，BEEP对等方必须准备好处理它在该通道上收到的任何“MSG”消息。
When a BEEP peer receives a "close" message for a channel, it may, at any time, reject the request to close the channel by sending an "error" message in a negative reply.
当BEEP对等方收到通道的“关闭”消息时，它可以在任何时候通过在否定回复中发送“错误”消息来拒绝关闭通道的请求。
Otherwise, before accepting the request to close the channel, and sending an "ok" message in a positive reply, it must:
否则，在接受关闭通道的请求并以肯定回复发送“ok”消息之前，必须：
o finish sending any queued "MSG" messages on that channel of its own;
o 完成在自己的通道上发送任何排队的“MSG”消息；
o await complete replies to any outstanding "MSG" messages it has sent on that channel; and,
o 等待对其在该频道上发送的任何未完成的“MSG”消息的完整回复；和
o finish sending complete replies to any outstanding "MSG" messages it has received on that channel, and ensure that the final frames of those replies have been successfully delivered, i.e.,
o 完成对其在该频道上收到的任何未完成的“MSG”消息的完整回复，并确保这些回复的最终帧已成功交付，即。，
* for transport mappings that guarantee inter-channel ordering of messages, the replies must be sent prior to sending the "ok" message in a positive reply; otherwise,
* 对于保证消息的通道间顺序的传输映射，必须在发送肯定回复中的“ok”消息之前发送回复；否则
* the replies must be sent and subsequently acknowledged by the underlying transport service prior to sending the "ok" message in a positive reply.
* 在以肯定回复发送“ok”消息之前，必须先发送回复，然后由基础传输服务确认。
Briefly, a successful channel close might look like this:
简单地说，成功的频道关闭可能如下所示：
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END
Similarly, an unsuccessful channel close might look like this:
类似地，不成功的通道关闭可能如下所示：
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: ERR 0 2 . 392 79
S: Content-Type: application/beep+xml
S:
S: <error code='550'>still working</error>
S: END
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: ERR 0 2 . 392 79
S: Content-Type: application/beep+xml
S:
S: <error code='550'>still working</error>
S: END
When a BEEP peer agrees to close a channel (or release the BEEP session), it sends an "ok" element in a positive reply.
当蜂鸣器对等方同意关闭通道（或释放蜂鸣器会话）时，它会在肯定回复中发送一个“ok”元素。
The "ok" element has no attributes and no content.
“ok”元素没有属性，也没有内容。
When a BEEP peer declines the creation of a channel, it sends an "error" element in a negative reply, e.g.,
当BEEP对等方拒绝创建通道时，它会在否定回复中发送一个“错误”元素，例如。，
I: MSG 0 1 . 52 115
I: Content-Type: application/beep+xml
I:
I: <start number='2'>
I: <profile uri='http://iana.org/beep/FOO' />
I: </start>
I: END
L: ERR 0 1 . 221 105
L: Content-Type: application/beep+xml
L:
L: <error code='550'>all requested profiles are
L: unsupported</error>
L: END
I: MSG 0 1 . 52 115
I: Content-Type: application/beep+xml
I:
I: <start number='2'>
I: <profile uri='http://iana.org/beep/FOO' />
I: </start>
I: END
L: ERR 0 1 . 221 105
L: Content-Type: application/beep+xml
L:
L: <error code='550'>all requested profiles are
L: unsupported</error>
L: END
The "error" element has a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content:
“error”元素有一个“code”属性、一个可选的“xml:lang”属性和一个可选的文本诊断作为其内容：
o the "code" attribute is a three-digit reply code meaningful to programs (c.f., Section 8);
o “代码”属性是对程序有意义的三位数回复代码（c.f.，第8节）；
o the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and,
o “xml:lang”属性标识元素内容所用的语言（该值是由远程BEEP对等方发送的“greeting”元素的“localize”属性建议的，但不是强制的）；和
o the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs.
o 文本诊断（可能是多行的）对实现者，可能是管理员，甚至可能是用户都有意义，但对程序却没有意义。
Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used.
请注意，如果存在文本诊断，则只有在使用作为远程蜂鸣器对等方的首选语言时，“xml:lang”属性才不存在。
In addition, a BEEP peer sends an "error" element whenever:
此外，每当出现以下情况时，蜂鸣器会发送一个“错误”元素：
o it receives a "MSG" message containing a poorly-formed or unexpected element;
o 它接收一条“MSG”消息，其中包含格式错误或意外的元素；
o it receives a "MSG" message asking to close a channel (or release the BEEP session) and it declines to do so; or
o 它收到一条“MSG”消息，要求关闭一个频道（或释放蜂鸣音会话），但拒绝关闭；或
o a BEEP session is established, the BEEP peer is acting in the listening role, and that BEEP peer is unavailable (in this case, the BEEP acting in the listening role does not send a "greeting" element).
o 建立了一个BEEP会话，BEEP对等方扮演监听角色，并且该BEEP对等方不可用（在这种情况下，扮演监听角色的BEEP不会发送“问候”元素）。
In the final case, both BEEP peers terminate the session, and it is recommended that a diagnostic entry be logged by both BEEP peers.
在最后一种情况下，两个BEEP对等方都会终止会话，建议两个BEEP对等方都记录一个诊断条目。
When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero on channel zero that contains a "greeting" element, e.g.,
建立BEEP会话时，每个BEEP对等方通过立即在包含“问候”元素的通道0上发送消息编号为零的肯定回复来表示其可用性，例如。，
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Alternatively, if the BEEP peer acting in the listening role is unavailable, it sends a negative reply, e.g.,
或者，如果担任监听角色的BEEP对等方不可用，则会发送否定回复，例如。，
L: <wait for incoming connection>
I: <open connection>
L: ERR 0 0 . 0 60
L: Content-Type: application/beep+xml
L:
L: <error code='421' />
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
L: <wait for incoming connection>
I: <open connection>
L: ERR 0 0 . 0 60
L: Content-Type: application/beep+xml
L:
L: <error code='421' />
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
and the "greeting" element sent by the BEEP peer acting in the initiating role is ignored. It is recommended that a diagnostic entry be logged by both BEEP peers.
并且忽略扮演发起角色的BEEP对等方发送的“问候”元素。建议两个BEEP对等方都记录一个诊断条目。
Note that both of these examples imply that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends its greeting -- this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.
请注意，这两个示例都暗示，发起角色中的BEEP对等方将等待，直到侦听角色中的BEEP对等方发送其问候语——这是表示的一个工件；事实上，两个BEEP节点都独立发送回复。
When a BEEP peer wants to release the BEEP session, it sends a "close" element with a zero-valued "number" attribute on channel zero. The other BEEP peer indicates its willingness by sending an "ok" element in a positive reply, e.g.,
当BEEP对等方想要释放BEEP会话时，它会发送一个“close”元素，该元素在通道0上具有零值“number”属性。另一个蜂鸣声对等方通过在肯定回复中发送“ok”元素表示其愿意，例如。，
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml
C:
C: <close code='200' />
C: END
S: RPY 0 1 . 264 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml
C:
C: <close code='200' />
C: END
S: RPY 0 1 . 264 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
Alternatively, if the other BEEP doesn't want to release the BEEP session, the exchange might look like this:
或者，如果另一个蜂鸣音不想释放蜂鸣音会话，则交换可能如下所示：
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml
C:
C: <close code='200' />
C: END
S: ERR 0 1 . 264 79
S: Content-Type: application/beep+xml
S:
S: <error code='550'>still working</error>
S: END
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml
C:
C: <close code='200' />
C: END
S: ERR 0 1 . 264 79
S: Content-Type: application/beep+xml
S:
S: <error code='550'>still working</error>
S: END
If session release is declined, the BEEP session should not be terminated, if possible.
如果会话释放被拒绝，则如果可能，不应终止蜂鸣音会话。
All transport interactions occur in the context of a session -- a mapping onto a particular transport service. Accordingly, this memo defines the requirements that must be satisfied by any document describing how a particular transport service realizes a BEEP session.
所有传输交互都发生在会话的上下文中——映射到特定传输服务。因此，本备忘录定义了描述特定运输服务如何实现BEEP会话的任何文件必须满足的要求。
A BEEP session is connection-oriented. A mapping document must define:
BEEP会话是面向连接的。映射文档必须定义：
o how a BEEP session is established;
o 如何建立BEEP会话；
o how a BEEP peer is identified as acting in the listening role;
o 如何识别“哔哔”声同伴担任监听角色；
o how a BEEP peer is identified as acting in the initiating role;
o 如何识别BEEP对等方作为发起角色；
o how a BEEP session is released; and,
o 如何释放蜂鸣音会话；和
o how a BEEP session is terminated.
o 如何终止蜂鸣音会话。
A BEEP session is message-oriented. A mapping document must define:
蜂鸣音会话是面向消息的。映射文档必须定义：
o how messages are reliably sent and received;
o 如何可靠地发送和接收信息；
o how messages on the same channel are received in the same order as they were sent; and,
o 同一频道上的消息如何以发送时的相同顺序接收；和
o how messages on different channels are sent without ordering constraint.
o 不同通道上的消息如何在没有顺序约束的情况下发送。
BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel).
BEEP可在单个通道内和单独通道之间进行异步交互。此功能允许流水线（通道内）和并行（通道间）。
A BEEP peer acting in the client role may send multiple "MSG" messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel.
担任客户端角色的BEEP对等方可以在同一通道上发送多条“MSG”消息，而无需等待接收相应的回复。这在单个通道内提供了管道。
A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel.
担任服务器角色的BEEP对等方必须按照接收的顺序处理给定通道的所有“MSG”消息。因此，BEEP对等方必须以与给定通道上接收到的相应“MSG”消息相同的顺序生成回复。
Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply to the "MSG" message consists of zero or more "ANS" messages followed by a "NUL" message. In this style of exchange, the "ANS" messages comprising the reply may be interleaved. When the BEEP peer acting in the server role signifies the end of the reply by generating the "NUL" message, it may then process the next "MSG" message received for that channel.
请注意，在一对多交换（c.f.，第2.1.1节）中，“MSG”消息的回复由零条或多条“ANS”消息和一条“NUL”消息组成。在这种交换方式中，组成应答的“ANS”消息可以交错。当担任服务器角色的BEEP对等方通过生成“NUL”消息表示应答结束时，它可能随后处理为该通道接收的下一条“MSG”消息。
A BEEP peer acting in the client role may send multiple "MSG" messages on different channels without waiting to receive the corresponding replies. The channels operate independently, in parallel.
担任客户端角色的BEEP对等方可以在不同的通道上发送多条“MSG”消息，而无需等待接收相应的回复。这些通道独立并行运行。
A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels.
担任服务器角色的BEEP对等方可以按照其选择的任何顺序处理在不同通道上接收的“MSG”消息。因此，尽管给定通道的回复似乎是按照接收相应“MSG”消息的相同顺序生成的，但不同通道上的回复没有顺序约束。
A BEEP peer acting in the server role may send a negative reply before it receives the final "MSG" frame of a message. If it does so, that BEEP peer is obliged to ignore any subsequent "MSG" frames for that message, up to and including the final "MSG" frame.
担任服务器角色的BEEP对等方可能会在收到消息的最终“MSG”帧之前发送否定回复。如果它这样做，则该BEEP对等方必须忽略该消息的任何后续“MSG”帧，直到并包括最终的“MSG”帧。
If a BEEP peer acting in the client role receives a negative reply before it sends the final "MSG" frame for a message, then it is required to send a "MSG" frame with a continuation status of complete (".") and having a zero-length payload.
如果担任客户端角色的BEEP对等方在发送消息的最终“MSG”帧之前收到否定答复，则需要发送一个“MSG”帧，其持续状态为“完成”（“.”），负载长度为零。
If the processing of a particular message has sequencing impacts on other messages (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport mapping.
如果特定消息的处理对其他消息（信道内或信道间）有顺序影响，则相应的配置文件应定义此行为，例如，其消息改变基础传输映射的配置文件。
BEEP is peer-to-peer -- as such both peers must be prepared to receive all messages defined in this memo. Accordingly, an initiating BEEP peer capable of acting only in the client role must behave gracefully if it receives a "MSG" message. Accordingly, all profiles must provide an appropriate error message for replying to unexpected "MSG" messages.
BEEP是对等的——因此，两个对等方都必须准备好接收此备忘录中定义的所有消息。因此，只有在客户端角色中才能执行操作的发起BEEP对等方在收到“MSG”消息时必须举止优雅。因此，所有配置文件都必须提供适当的错误消息，用于回复意外的“MSG”消息。
As a consequence of the peer-to-peer nature of BEEP, message numbers are unidirectionally-significant. That is, the message numbers in "MSG" messages sent by a BEEP peer acting in the initiating role are unrelated to the message numbers in "MSG" messages sent by a BEEP peer acting in the listening role.
由于BEEP的点对点特性，消息编号具有单向意义。也就是说，担任发起角色的BEEP对等方发送的“MSG”消息中的消息编号与担任侦听角色的BEEP对等方发送的“MSG”消息中的消息编号无关。
For example, these two messages
例如，这两条消息
I: MSG 0 1 . 52 120
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/SASL/OTP' />
I: </start>
I: END
L: MSG 0 1 . 221 116
L: Content-Type: application/beep+xml
L:
L: <start number='2'>
L: <profile uri='http://iana.org/beep/APEX' />
L: </start>
L: END
I: MSG 0 1 . 52 120
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/SASL/OTP' />
I: </start>
I: END
L: MSG 0 1 . 221 116
L: Content-Type: application/beep+xml
L:
L: <start number='2'>
L: <profile uri='http://iana.org/beep/APEX' />
L: </start>
L: END
refer to different messages sent on channel zero.
请参阅在通道0上发送的不同消息。
When a BEEP session is established, plaintext transfer, without privacy, is provided. Accordingly, transport security in BEEP is achieved using an initial tuning profile.
当建立BEEP会话时，将提供无隐私的明文传输。因此，BEEP中的传输安全性是通过使用初始调整配置文件来实现的。
This document defines one profile:
本文档定义了一个配置文件：
o the TLS transport security profile, based on TLS version one [3].
o TLS传输安全配置文件，基于TLS版本一[3]。
Other profiles may be defined and deployed on a bilateral basis. Note that because of their intimate relationship with the transport service, a given transport security profile tends to be relevant to a single transport mapping (c.f., Section 2.5).
其他配置文件可在双边基础上定义和部署。请注意，由于其与运输服务的密切关系，给定的运输安全配置文件往往与单个运输映射相关（c.f.，第2.5节）。
When a channel associated with transport security begins the underlying negotiation process, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers. (If the negotiation process fails, then either BEEP peer may instead terminate the session, and it is recommended that a diagnostic entry be logged.)
当与传输安全相关联的通道开始底层协商过程时，所有通道（包括通道0）在BEEP会话中关闭。因此，在协商过程完成后，无论协商结果如何，BEEP对等方都会发出新的问候语。（如果协商过程失败，则任何一方都可以终止会话，建议记录诊断条目。）
A BEEP peer may choose to issue different greetings based on whether privacy is in use, e.g.,
BEEP peer可根据是否使用隐私权选择发出不同的问候语，例如：。，
L: <wait for incoming connection> I: <open connection> L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I:
L:<等待传入连接>I:<打开连接>L:RPY 0。0 110 L:内容类型：应用程序/beep+xml L:L:<greeting>L:<profile uri=http://iana.org/beep/TLS“/>L:</greeting>L:END I:RPY 0。0 52 I:Content Type:application/beep+xml I:I:<greeting/>I:END I:MSG 0 1。52 158 I：内容类型：应用程序/beep+xml I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/TLS'>
I: <![CDATA[<ready />]]>
I: </profile>
I: </start>
I: END
L: RPY 0 1 . 110 121
L: Content-Type: application/beep+xml
L:
L: <profile uri='http://iana.org/beep/TLS'>
L: <![CDATA[<proceed />]]>
L: </profile>
L: END
I: <start number='1'>
I: <profile uri='http://iana.org/beep/TLS'>
I: <![CDATA[<ready />]]>
I: </profile>
I: </start>
I: END
L: RPY 0 1 . 110 121
L: Content-Type: application/beep+xml
L:
L: <profile uri='http://iana.org/beep/TLS'>
L: <![CDATA[<proceed />]]>
L: </profile>
L: END
... successful transport security negotiation ...
... 成功的运输安全谈判。。。
L: RPY 0 0 . 0 221
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://iana.org/beep/APEX' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
L: RPY 0 0 . 0 221
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://iana.org/beep/APEX' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Of course, not all BEEP peers need be as single-minded:
当然，并非所有BEEP同龄人都需要一心一意：
L: <wait for incoming connection> I: <open connection> L: RPY 0 0 . 0 268 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' /> L: <profile uri='http://iana.org/beep/APEX' /> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I:
L:<等待传入连接>I:<打开连接>L:RPY 0。0 268 L:内容类型：应用程序/beep+xml L:L:<greeting>L:<profile uri=http://iana.org/beep/SASL/ANONYMOUS“/>L:<profile uri=”http://iana.org/beep/SASL/OTP“/>L:<profile uri=”http://iana.org/beep/APEX“/>L:<profile uri=”http://iana.org/beep/TLS“/>L:</greeting>L:END I:RPY 0。0 52 I:内容类型：应用程序/beep+xml I:
I: <greeting />
I: END
I: MSG 0 1 . 52 158
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/TLS'>
I: <![CDATA[<ready />]]>
I: </profile>
I: </start>
I: END
L: RPY 0 1 . 268 121
L: Content-Type: application/beep+xml
L:
L: <profile uri='http://iana.org/beep/TLS'>
L: <![CDATA[<proceed />]]>
L: </profile>
L: END
I: <greeting />
I: END
I: MSG 0 1 . 52 158
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/TLS'>
I: <![CDATA[<ready />]]>
I: </profile>
I: </start>
I: END
L: RPY 0 1 . 268 121
L: Content-Type: application/beep+xml
L:
L: <profile uri='http://iana.org/beep/TLS'>
L: <![CDATA[<proceed />]]>
L: </profile>
L: END
... failed transport security negotiation ...
... 传输安全协商失败。。。
L: RPY 0 0 . 0 268
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://iana.org/beep/APEX' />
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
L: RPY 0 0 . 0 268
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://iana.org/beep/APEX' />
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Section 6.2 contains the registration for this profile.
第6.2节包含此配置文件的注册。
The TLS transport security profile is identified as:
TLS传输安全配置文件标识为：
http://iana.org/beep/TLS
http://iana.org/beep/TLS
in the BEEP "profile" element during channel creation.
在频道创建过程中，在“配置文件”元素中。
During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "ready" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "ready" element and includes the resulting response in the reply, e.g.,
在频道创建过程中，蜂鸣“开始”元素中相应的“配置文件”元素可能包含“就绪”元素。如果通道创建成功，则在发送相应的回复之前，BEEP对等方处理“就绪”元素，并在回复中包含结果响应，例如。，
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]>
S: </profile>
S: END
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]>
S: </profile>
S: END
Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g.,
请注意，可能会创建通道，但封装操作会失败，例如。，
C: MSG 0 1 . 52 173
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready version="oops" />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 193
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<error code='501'>version attribute
S: poorly formed in <ready> element</error>]]>
S: </profile>
S: END
C: MSG 0 1 . 52 173
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready version="oops" />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 193
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<error code='501'>version attribute
S: poorly formed in <ready> element</error>]]>
S: </profile>
S: END
In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.
在这种情况下，将发送肯定应答（当通道创建成功时），但封装的响应包含操作失败原因的指示。
Section 7.2 defines the messages that are used in the TLS transport security profile.
第7.2节定义了TLS传输安全配置文件中使用的消息。
The "ready" element has an optional "version" attribute and no content:
“ready”元素有一个可选的“version”属性，没有内容：
o the "version" element defines the earliest version of TLS acceptable for use.
o “版本”元素定义了可接受使用的TLS的最早版本。
When a BEEP peer sends the "ready" element, it must not send any further traffic on the underlying transport service until a corresponding reply ("proceed" or "error") is received; similarly, the receiving BEEP peer must wait until any pending replies have been generated and sent before it processes a "ready" element.
当BEEP对等方发送“就绪”元素时，在收到相应的回复（“继续”或“错误”）之前，它不得在基础传输服务上发送任何进一步的通信量；类似地，在处理“就绪”元素之前，接收BEEP的对等方必须等到生成并发送了任何挂起的应答。
The "proceed" element has no attributes and no content. It is sent as a reply to the "ready" element.
“继续”元素没有属性和内容。它作为对“ready”元素的答复发送。
When a BEEP peer receives the "ready" element, it must not send any further traffic on the underlying transport service until it generates a corresponding reply. If the BEEP peer decides to allow transport security negotiation, it implicitly closes all channels (including channel zero), and sends the "proceed" element, and awaits the underlying negotiation process for transport security.
当BEEP对等方收到“ready”元素时，在生成相应的应答之前，它不得在基础传输服务上发送任何进一步的通信量。如果BEEP对等方决定允许传输安全协商，它将隐式关闭所有通道（包括通道0），并发送“继续”元素，并等待传输安全的底层协商过程。
When a BEEP peer receives a "proceed" element in reply to its "ready" message, it implicitly closes all channels (including channel zero), and immediately begins the underlying negotiation process for transport security.
当一个BEEP对等方收到一个“继续”元素来回复其“就绪”消息时，它会隐式关闭所有通道（包括通道零），并立即开始传输安全的底层协商过程。
When a BEEP session is established, anonymous access, without trace information, is provided. Accordingly, user authentication in BEEP is achieved using an initial tuning profile.
建立BEEP会话时，将提供无跟踪信息的匿名访问。因此，使用初始调优配置文件实现BEEP中的用户身份验证。
This document defines a family of profiles based on SASL mechanisms:
本文档定义了一系列基于SASL机制的配置文件：
o each mechanism in the IANA SASL registry [15] has an associated profile.
o IANA SASL注册表[15]中的每个机制都有一个相关的配置文件。
Other profiles may be defined and deployed on a bilateral basis.
其他配置文件可在双边基础上定义和部署。
Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further, no additional attempts at authentication are allowed.
无论何时在任何通道上成功进行身份验证，都会在BEEP会话上更新所有现有和未来通道的身份验证；此外，不允许进行其他身份验证尝试。
Note that regardless of transport security and user authentication, authorization is an internal matter for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided (i.e., unauthorized operations might be rejected with error code 530).
请注意，无论传输安全性和用户身份验证如何，授权都是每个BEEP对等方的内部事务。因此，每个对等方可以基于所提供的认证凭证选择限制其允许的操作（即，未经授权的操作可能被拒绝，错误代码530）。
Section 6.3 contains the registration for this profile.
第6.3节包含此配置文件的注册。
Note that SASL may provide both user authentication and transport security. Once transport security is successfully negotiated for a BEEP session, then a SASL security layer must not be negotiated; similarly, once any SASL negotiation is successful, a transport security profile must not begin its underlying negotiation process.
注意，SASL可以同时提供用户身份验证和传输安全。一旦为BEEP会话成功协商传输安全性，则不得协商SASL安全层；类似地，一旦任何SASL协商成功，传输安全配置文件不得开始其底层协商过程。
Section 4 of the SASL specification [4] requires the following information be supplied by a protocol definition:
SASL规范[4]第4节要求协议定义提供以下信息：
service name: "beep"
服务名称：“嘟嘟”
initiation sequence: Creating a channel using a BEEP profile corresponding to a SASL mechanism starts the exchange. An optional parameter corresponding to the "initial response" sent by the client is carried within a "blob" element during channel creation.
启动顺序：使用与SASL机制相对应的蜂鸣配置文件创建通道将启动交换。与客户端发送的“初始响应”相对应的可选参数在通道创建期间携带在“blob”元素中。
exchange sequence: "Challenges" and "responses" are carried in exchanges of the "blob" element. The "status" attribute of the "blob" element is used both by a server indicating a successful completion of the exchange, and a client aborting the exchange, The server indicates failure of the exchange by sending an "error" element.
交换顺序：“挑战”和“响应”在“blob”元素的交换中进行。“blob”元素的“status”属性既可由服务器使用，表示交换成功完成，也可由客户端中止交换。服务器通过发送“error”元素表示交换失败。
security layer negotiation: When a security layer starts negotiation, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers.
安全层协商：当安全层开始协商时，所有通道（包括通道0）在BEEP会话中关闭。因此，在协商过程完成后，无论协商结果如何，BEEP对等方都会发出新的问候语。
If a security layer is successfully negotiated, it takes effect immediately following the message that concludes the server's successful completion reply.
如果安全层协商成功，它将在服务器成功完成应答的消息结束后立即生效。
use of the authorization identity: This is made available to all channels for the duration of the BEEP session.
授权标识的使用：在嘟嘟声会话期间，所有通道都可以使用授权标识。
Each SASL mechanism registered with the IANA is identified as:
在IANA注册的每个SASL机制标识为：
http://iana.org/beep/SASL/mechanism
http://iana.org/beep/SASL/mechanism
where "MECHANISM" is the token assigned to that mechanism by the IANA.
其中，“机制”是IANA分配给该机制的令牌。
Note that during channel creation, a BEEP peer may provide multiple profiles to the remote peer, e.g.,
请注意，在通道创建期间，一个BEEP对等方可能会向远程对等方提供多个配置文件，例如。，
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END
During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "blob" element. Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g.,
在频道创建过程中，BEEP“start”元素中相应的“profile”元素可能包含一个“blob”元素。请注意，可能会创建通道，但封装操作会失败，例如。，
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 178
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<error code='534'>authentication mechanism is
S: too weak</error>]]>
S: </profile>
S: END
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 178
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<error code='534'>authentication mechanism is
S: too weak</error>]]>
S: </profile>
S: END
In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.
在这种情况下，将发送肯定应答（当通道创建成功时），但封装的响应包含操作失败原因的指示。
Otherwise, the server sends a challenge (or signifies success), e.g.,
Otherwise, the server sends a challenge (or signifies success), e.g.,translate error, please retry
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 171
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
</blob>]]>
S: </profile>
S: END
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 171
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
</blob>]]>
S: </profile>
S: END
Note that this example implies that the "blob" element in the server's reply appears on two lines -- this is an artifact of the presentation; in fact, only one line is used.
注意，这个示例意味着服务器回复中的“blob”元素出现在两行上——这是表示的工件；事实上，只使用了一行。
If a challenge is received, then the client responds and awaits another reply, e.g.,
如果收到质询，则客户机响应并等待另一个答复，例如。，
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: RPY 1 0 . 0 66
S: Content-Type: application/beep+xml
S:
S: <blob status='complete' />
S: END
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: RPY 1 0 . 0 66
S: Content-Type: application/beep+xml
S:
S: <blob status='complete' />
S: END
Of course, the client could abort the authentication process by sending "<blob status='abort' />" instead.
当然，客户端可以通过发送“<blob status='abort'/>”来中止身份验证过程。
Alternatively, the server might reject the response with an error: e.g.,
或者，服务器可能会拒绝响应并出现错误：例如。，
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: ERR 1 0 . 0 60
S: Content-Type: application/beep+xml
S:
S: <error code='535' />
S: END
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: ERR 1 0 . 0 60
S: Content-Type: application/beep+xml
S:
S: <error code='535' />
S: END
Finally, depending on the SASL mechanism, an initialization element may be exchanged unidirectionally during channel creation, e.g.,
最后，根据SASL机制，可以在信道创建期间单向交换初始化元素，例如。，
C: MSG 0 1 . 52 125
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />
C: </start>
C: END
S: RPY 0 1 . 221 185
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]>
S: </profile>
S: END
C: MSG 0 1 . 52 125
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />
C: </start>
C: END
S: RPY 0 1 . 221 185
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]>
S: </profile>
S: END
Note that this example implies that the "blob" element in the server's reply appears on two lines -- this is an artifact of the presentation; in fact, only one line is used.
Note that this example implies that the "blob" element in the server's reply appears on two lines -- this is an artifact of the presentation; in fact, only one line is used.translate error, please retry
Section 7.3 defines the messages that are used for each profile in the SASL family.
第7.3节定义了SASL系列中每个配置文件使用的消息。
Note that because many SASL mechanisms exchange binary data, the content of the "blob" element is always a base64-encoded string.
注意，由于许多SASL机制交换二进制数据，“blob”元素的内容始终是base64编码的字符串。
The "blob" element has an optional "status" attribute, and arbitrary octets as its content:
The "blob" element has an optional "status" attribute, and arbitrary octets as its content:translate error, please retry
o the "status" attribute, if present, takes one of three values:
o “状态”属性（如果存在）采用以下三个值之一：
abort: used by a client to indicate that it is aborting the authentication process;
中止：客户端用于指示正在中止身份验证过程；
complete: used by a server to indicate that the exchange is complete and successful; or,
完成：由服务器使用，表示交换已完成并成功；或
continue: used by either a client or server, otherwise.
继续：由客户端或服务器使用，否则。
Finally, note that SASL's EXTERNAL mechanism works with an "external authentication" service, which is provided by one of:
最后，请注意，SASL的外部机制与“外部身份验证”服务一起工作，该服务由以下服务之一提供：
o a transport security profile, capable of providing authentication information (e.g., Section 3.1), being active on the connection;
o 传输安全配置文件，能够提供认证信息（例如，第3.1节），在连接上处于活动状态；
o a network service, capable of providing strong authentication (e.g., IPSec [12]), underlying the connection; or,
o 网络服务，能够在连接的基础上提供强身份验证（例如，IPSec[12]）；或
o a locally-defined security service.
o 本地定义的安全服务。
For authentication to succeed, two conditions must hold:
要使身份验证成功，必须满足两个条件：
o an external authentication service must be active; and,
o 外部身份验证服务必须处于活动状态；和
o if present, the authentication identity must be consistent with the credentials provided by the external authentication service (if the authentication identity is empty, then an authorization identity is automatically derived from the credentials provided by the external authentication service).
o 如果存在，则身份验证标识必须与外部身份验证服务提供的凭据一致（如果身份验证标识为空，则授权标识将自动从外部身份验证服务提供的凭据派生）。
When a profile is registered, the following information is supplied:
注册配置文件时，将提供以下信息：
Profile Identification: specify a URI [10] that authoritatively identifies this profile.
配置文件标识：指定授权标识此配置文件的URI[10]。
Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation.
通道创建期间交换的消息：指定通道创建期间可能交换的数据类型。
Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts.
启动一对一交换的消息：指定交换启动时可能出现的数据类型。
Messages in positive replies: specify the datatypes that may be present in a positive reply.
肯定回复中的消息：指定肯定回复中可能存在的数据类型。
Messages in negative replies: specify the datatypes that may be present in a negative reply.
否定回复中的消息：指定否定回复中可能存在的数据类型。
Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange.
一对多交换中的消息：指定一对多交换中可能存在的数据类型。
Message Syntax: specify the syntax of the datatypes exchanged by the profile.
消息语法：指定配置文件交换的数据类型的语法。
Message Semantics: specify the semantics of the datatypes exchanged by the profile.
消息语义：指定概要文件交换的数据类型的语义。
Contact Information: specify the postal and electronic contact information for the author of the profile.
联系信息：指定配置文件作者的邮政和电子联系信息。
When a feature for the channel management profile is registered, the following information is supplied:
注册通道管理配置文件的功能时，将提供以下信息：
Feature Identification: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-".
特征标识：指定标识此特征的字符串。除非该功能已向IANA注册，否则该功能的标识必须以“x-”开头。
Feature Semantics: specify the semantics of the feature.
特征语义：指定特征的语义。
Contact Information: specify the postal and electronic contact information for the author of the feature.
联系信息：指定功能作者的邮政和电子联系信息。
Profile Identification: not applicable
配置文件标识：不适用
Messages exchanged during Channel Creation: not applicable
通道创建期间交换的消息：不适用
Messages starting one-to-one exchanges: "start" or "close"
开始一对一交换的消息：“开始”或“关闭”
Messages in positive replies: "greeting", "profile", or "ok"
正面回复中的消息：“问候语”、“个人资料”或“确定”
Messages in negative replies: "error"
否定回复中的消息：“错误”
Messages in one-to-many exchanges: none
一对多交换中的消息：无
Message Syntax: c.f., Section 7.1
消息语法：c.f.，第7.1节
Message Semantics: c.f., Section 2.3.1
消息语义：c.f.，第2.3.1节
Contact Information: c.f., the "Author's Address" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
Profile Identification: http://iana.org/beep/TLS
Profile Identification: http://iana.org/beep/TLS
Messages exchanged during Channel Creation: "ready"
通道创建期间交换的消息：“就绪”
Messages starting one-to-one exchanges: "ready"
开始一对一交换的消息：“就绪”
Messages in positive replies: "proceed"
正面回复中的消息：“继续”
Messages in negative replies: "error"
否定回复中的消息：“错误”
Messages in one-to-many exchanges: none
一对多交换中的消息：无
Message Syntax: c.f., Section 7.2
消息语法：c.f.，第7.2节
Message Semantics: c.f., Section 3.1.3
消息语义：c.f.，第3.1.3节
Contact Information: c.f., the "Author's Address" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
Profile Identification: http://iana.org/beep/SASL/mechanism, where
"mechanism" is a token registered with the IANA
Profile Identification: http://iana.org/beep/SASL/mechanism, where
"mechanism" is a token registered with the IANA
Messages exchanged during Channel Creation: "blob"
通道创建期间交换的消息：“blob”
Messages starting one-to-one exchanges: "blob"
开始一对一交换的消息：“blob”
Messages in positive replies: "blob"
正面回复中的消息：“blob”
Messages in negative replies: "error"
否定回复中的消息：“错误”
Messages in one-to-many exchanges: none
一对多交换中的消息：无
Message Syntax: c.f., Section 7.3
消息语法：c.f.，第7.3节
Message Semantics: c.f., Section 4.1.3
消息语义：c.f.，第4.1.3节
Contact Information: c.f., the "Author's Address" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: beep+xml
MIME子类型名称：beep+xml
Required parameters: none
所需参数：无
Optional parameters: charset (defaults to "UTF-8" [13])
可选参数：字符集（默认为“UTF-8”[13]）
Encoding considerations: This media type may contain binary content; accordingly, when used over a transport that does not permit binary transfer, an appropriate encoding must be applied
编码注意事项：此媒体类型可能包含二进制内容；因此，当在不允许二进制传输的传输上使用时，必须应用适当的编码
Security considerations: none, per se; however, any BEEP profile which uses this media type must describe its relevant security considerations
安全考虑：本身没有；但是，任何使用此媒体类型的BEEP配置文件都必须说明其相关的安全注意事项
Interoperability considerations: n/a
互操作性注意事项：不适用
Published specification: This media type is a proper subset of the the XML 1.0 specification [2]. Two restrictions are made.
已发布规范：此媒体类型是XML1.0规范的适当子集[2]。有两个限制。
First, no entity references other than the five predefined general entities references ("&", "<", ">", "'", and """) and numeric entity references may be present.
首先，除了五个预定义的通用实体引用（“&；”、“<；”、“>；”、“&apos；”和“"；”）和数字实体引用之外，不能存在任何实体引用。
Second, neither the "XML" declaration (e.g., <?xml version="1.0" ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be present. (Accordingly, if another character set other than UTF-8 is desired, then the "charset" parameter must be present.)
其次，“XML”声明（例如<？XML version=“1.0”？>）和“DOCTYPE”声明（例如<！DOCTYPE…>）都可能不存在。（因此，如果需要UTF-8以外的另一个字符集，则必须存在“charset”参数。）
All other XML 1.0 instructions (e.g., CDATA blocks, processing instructions, and so on) are allowed.
允许使用所有其他XML 1.0指令（例如CDATA块、处理指令等）。
Applications which use this media type: any BEEP profile wishing to make use of this XML 1.0 subset
使用此媒体类型的应用程序：任何希望使用此XML 1.0子集的BEEP配置文件
Additional Information: none
其他信息：无
Contact for further information: c.f., the "Author's Address" section of this memo
联系方式：c.f.，本备忘录“作者地址”部分
Intended usage: limited use
预期用途：有限用途
Author/Change controller: the IESG
作者/变更控制员：IESG
<!-- DTD for BEEP Channel Management, as of 2000-10-29
<!-- 自2000年10月29日起，用于BEEP信道管理的DTD
Refer to this DTD as:
将此DTD称为：
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN"
"http://xml.resource.org/profiles/BEEP/beep.dtd">
%BEEP;
-->
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN"
"http://xml.resource.org/profiles/BEEP/beep.dtd">
%BEEP;
-->
<!-- DTD data types:
<!-- DTD数据类型：
entity syntax/reference example
====== ================ =======
a channel number
CHAN 1..2147483647 1
entity syntax/reference example
====== ================ =======
a channel number
CHAN 1..2147483647 1
authoritative profile identification
URI c.f., [RFC-2396] http://invisible.net/
authoritative profile identification
URI c.f., [RFC-2396] http://invisible.net/
one or more feature tokens, separated by space FTRS NMTOKENS "magic"
一个或多个功能令牌，由空格FTRS NMTOKENS“magic”分隔
a language tag LANG c.f., [RFC-1766] "en", "en-US", etc.
语言标签LANG c.f.，[RFC-1766]“en”，“en-US”等。
zero or more language tags LOCS NMTOKENS "en-US"
零个或多个语言标记LOCS NMTOKENS“en US”
a 3-digit reply code XYZ [1-5][0-9][0-9] 500 -->
三位数回复代码XYZ[1-5][0-9][0-9]500-->
<!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS">
<!ENTITY % LANG "NMTOKEN">
<!ENTITY % LOCS "NMTOKEN">
<!ENTITY % XYZ "CDATA">
<!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS">
<!ENTITY % LANG "NMTOKEN">
<!ENTITY % LOCS "NMTOKEN">
<!ENTITY % XYZ "CDATA">
<!--
BEEP messages, exchanged as application/beep+xml
<!--
BEEP messages, exchanged as application/beep+xml
role MSG RPY ERR
======= === === ===
I and L greeting error
role MSG RPY ERR
======= === === ===
I and L greeting error
I or L start profile error
I或L启动配置文件错误
I or L close ok error -->
I或L关闭ok错误-->
<!ELEMENT greeting (profile)*>
<!ATTLIST greeting
features %FTRS; #IMPLIED
localize %LOCS; "i-default">
<!ELEMENT greeting (profile)*>
<!ATTLIST greeting
features %FTRS; #IMPLIED
localize %LOCS; "i-default">
<!ELEMENT start (profile)+>
<!ATTLIST start
number %CHAN; #REQUIRED
serverName CDATA #IMPLIED>
<!ELEMENT start (profile)+>
<!ATTLIST start
number %CHAN; #REQUIRED
serverName CDATA #IMPLIED>
<!-- profile element is empty if contained in a greeting -->
<!ELEMENT profile (#PCDATA)>
<!ATTLIST profile
uri %URI; #REQUIRED
encoding (none|base64) "none">
<!-- profile element is empty if contained in a greeting -->
<!ELEMENT profile (#PCDATA)>
<!ATTLIST profile
uri %URI; #REQUIRED
encoding (none|base64) "none">
<!ELEMENT close (#PCDATA)>
<!ATTLIST close
number %CHAN; "0"
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT close (#PCDATA)>
<!ATTLIST close
number %CHAN; "0"
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT ok EMPTY>
<!ELEMENT ok EMPTY>
<!ELEMENT error (#PCDATA)>
<!ATTLIST error
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT error (#PCDATA)>
<!ATTLIST error
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!-- DTD for the TLS Transport Security Profile, as of 2000-09-04
<!-- 自2000-09-04起，TLS传输安全配置文件的DTD
Refer to this DTD as:
将此DTD称为：
<!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN"
"http://xml.resource.org/profiles/TLS/tls.dtd">
%TLS;
-->
<!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN"
"http://xml.resource.org/profiles/TLS/tls.dtd">
%TLS;
-->
<!--
TLS messages, exchanged as application/beep+xml
<!--
TLS messages, exchanged as application/beep+xml
role MSG RPY ERR
====== === === ===
I or L ready proceed error
-->
role MSG RPY ERR
====== === === ===
I or L ready proceed error
-->
<!ELEMENT ready EMPTY>
<!ATTLIST ready
version CDATA "1">
<!ELEMENT ready EMPTY>
<!ATTLIST ready
version CDATA "1">
<!ELEMENT proceed EMPTY>
<!ELEMENT proceed EMPTY>
<!-- DTD for the SASL Family of Profiles, as of 2000-09-04
<!-- 自2000-09-04起，SASL系列型材的DTD
Refer to this DTD as:
将此DTD称为：
<!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN"
"http://xml.resource.org/profiles/sasl/sasl.dtd">
%SASL;
-->
<!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN"
"http://xml.resource.org/profiles/sasl/sasl.dtd">
%SASL;
-->
<!--
SASL messages, exchanged as application/beep+xml
<!--
SASL messages, exchanged as application/beep+xml
role MSG RPY ERR
====== === === ===
I or L blob blob error
-->
role MSG RPY ERR
====== === === ===
I or L blob blob error
-->
<!ELEMENT blob (#PCDATA)>
<!ATTLIST blob
xml:space (default|preserve)
"preserve"
status (abort|complete|continue)
"continue">
<!ELEMENT blob (#PCDATA)>
<!ATTLIST blob
xml:space (default|preserve)
"preserve"
status (abort|complete|continue)
"continue">
code meaning
==== =======
200 success
code meaning
==== =======
200 success
421 service not available
421服务不可用
450 requested action not taken (e.g., lock already in use)
450未采取请求的操作（例如，锁已在使用中）
451 requested action aborted (e.g., local error in processing)
451请求的操作已中止（例如，处理中的本地错误）
454 temporary authentication failure
454临时身份验证失败
500 general syntax error (e.g., poorly-formed XML)
500一般语法错误（例如，格式错误的XML）
501 syntax error in parameters (e.g., non-valid XML)
501参数中的语法错误（例如，无效XML）
504 parameter not implemented
504参数未实现
530 authentication required
530需要身份验证
534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.)
534身份验证机制不足（例如，太弱、序列用尽等）
535 authentication failure
535身份验证失败
537 action not authorized for user
537未授权用户执行的操作
538 authentication mechanism requires encryption
538身份验证机制需要加密
550 requested action not taken (e.g., no requested profiles are acceptable)
550未采取请求的行动（例如，不接受请求的配置文件）
553 parameter invalid
553参数无效
554 transaction failed (e.g., policy violation)
554事务失败（例如，违反策略）
The BEEP framing mechanism, per se, provides no protection against attack; however, judicious use of initial tuning profiles provides varying degrees of assurance:
蜂鸣音帧机制本身不提供攻击保护；但是，明智地使用初始调优配置文件可以提供不同程度的保证：
1. If one of the profiles from the SASL family is used, refer to [4]'s Section 9 for a discussion of security considerations.
1. 如果使用SASL系列中的一个配置文件，请参阅[4]的第9节，了解安全注意事项的讨论。
2. If the TLS transport security profile is used (or if a SASL security layer is negotiated), then:
2. 如果使用TLS传输安全配置文件（或如果协商SASL安全层），则：
1. A man-in-the-middle may remove the security-related profiles from the BEEP greeting or generate a negative reply to the "ready" element of the TLS transport security profile. A BEEP peer may be configurable to refuse to proceed without an acceptable level of privacy.
1. 中间的人可能会从哔哔声问候语中删除与安全相关的配置文件，或者对TLS传输安全配置文件的“就绪”元素生成否定回复。BEEP对等机可以配置为在没有可接受的隐私级别的情况下拒绝继续。
2. A man-in-the-middle may cause a down-negotiation to the weakest cipher suite available. A BEEP peer should be configurable to refuse weak cipher suites.
2. 中间的一个人可能会导致对可用的最脆弱的密码套件的向下协商。BEEP对等机应可配置为拒绝弱密码套件。
3. A man-in-the-middle may modify any protocol exchanges prior to a successful negotiation. Upon completing the negotiation, a BEEP peer must discard previously cached information about the BEEP session.
3. 中间人可以在成功协商之前修改任何协议交换。完成协商后，BEEP对等方必须放弃以前缓存的有关BEEP会话的信息。
As different TLS ciphersuites provide varying levels of security, administrators should carefully choose which ciphersuites are provisioned.
由于不同的TLS密码套件提供不同级别的安全性，管理员应仔细选择提供哪些密码套件。
As BEEP is peer-to-peer in nature, before performing any task associated with a message, each channel should apply the appropriate access control based on the authenticated identity and privacy level associated with the BEEP session.
由于BEEP本质上是点对点的，因此在执行与消息相关的任何任务之前，每个通道都应基于与BEEP会话相关的身份验证和隐私级别应用适当的访问控制。
References
工具书类
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[2] 万维网联盟，“可扩展标记语言（XML）1.0”，W3C XML，1998年2月<http://www.w3.org/TR/1998/REC-xml-19980210>.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks，T.，Allen，C.，Treese，W.，Karlton，P.，Freier，A.和P.Kocher，“TLS协议版本1.0”，RFC 2246，1999年1月。
[4] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[4] 迈尔斯，J.，“简单认证和安全层（SASL）”，RFC2222，1997年10月。
[5] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[5] Rose，M.“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] 《传输控制协议》，标准7，RFC 793，1981年9月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[8] Elz，R.和R.Bush，“序列号算术”，RFC 1982年，1996年8月。
[9] Alvestrand, H., "Tags for the Identification of Languages", RFC BCP 47, RFC 3066, January 2001.
[9] Alvestrand，H.，“语言识别标签”，RFC BCP 47，RFC 3066，2001年1月。
[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998.
[11] Newman，C.，“一次性密码SASL机制”，RFC 2444，1998年10月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[13] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[14] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[14] 林恩，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>
[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>
Author's Address
作者地址
Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US
美国加利福尼亚州佩塔卢马北麦克道尔大道1179号马歇尔T.罗斯隐形世界公司，邮编94954-6559
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
The author gratefully acknowledges the contributions of: David Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave Crocker provided helpful suggestions on the nature of segmentation in the framing mechanism.
作者衷心感谢以下人士的贡献：大卫·克拉克、戴夫·克罗克、史蒂夫·迪林、卫斯理·迈克尔·埃迪、休斯顿·富兰克林、马可·加泽塔、丹尼·古德曼、史蒂夫·哈里斯、罗伯特·赫里奥特、肯·赫希、格雷格·哈德森、本·劳里、卡尔·马拉默德、迈克尔·米林、基思·麦克洛格里、保罗·莫卡佩特里斯、RL‘鲍勃’摩根、弗兰克·莫顿、达伦·纽卡斯尔、，克里斯·纽曼、乔·图奇、保罗·维克西、加布·瓦乔布、丹尼尔·伍兹和詹姆斯·伍迪亚特。特别是，Dave Crocker就框架机制中分段的性质提供了有益的建议。
The IANA registers "beep" as a GSSAPI [14] service name, as specified in Section 4.1.
IANA将“beep”注册为GSSAPI[14]服务名称，如第4.1节所述。
The IANA maintains a list of:
IANA保存了一份清单，其中包括：
o standards-track BEEP profiles, c.f., Section 5.1; and,
o 标准轨道嘟嘟声剖面图，c.f.，第5.1节；和
o standards-track features for the channel management profile, c.f., Section 5.2.
o 信道管理配置文件的标准跟踪功能，c.f.，第5.2节。
For each list, the IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. As a courtesy to developers of non-standards track BEEP profiles and channel management features, the mailing list bxxpwg@invisible.net may be used to solicit commentary.
对于每一份清单，IESG负责在IANA作出分配之前指派一名指定专家审查规范。作为对非标准track BEEP配置文件和频道管理功能开发人员的礼遇，邮件列表bxxpwg@invisible.net可用于征求评论。
The IANA makes the registrations specified in Section 6.2 and Section 6.3. It is recommended that the IANA register these profiles using the IANA as a URI-prefix, and populate those URIs with the respective profile registrations.
IANA进行第6.2节和第6.3节规定的注册。建议IANA使用IANA作为URI前缀注册这些配置文件，并使用相应的配置文件注册填充这些URI。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。