Network Working Group M. Rose
Request for Comments: 3340 Dover Beach Consulting, Inc.
Category: Standards Track G. Klyne
Clearswift Corporation
D. Crocker
Brandenburg InternetWorking
July 2002
Network Working Group M. Rose
Request for Comments: 3340 Dover Beach Consulting, Inc.
Category: Standards Track G. Klyne
Clearswift Corporation
D. Crocker
Brandenburg InternetWorking
July 2002
The Application Exchange 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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs.
本备忘录描述了应用程序交换（APEX）核心，这是一种用于应用程序层程序的可扩展异步消息中继服务。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Architecture at a Glance . . . . . . . . . . . . . . . . . 4
2. Service Principles . . . . . . . . . . . . . . . . . . . . 5
2.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . 5
2.2 Naming of Entities . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Comparing Endpoints . . . . . . . . . . . . . . . . . . . 7
3. Service Provisioning . . . . . . . . . . . . . . . . . . . 7
3.1 Connection Establishment . . . . . . . . . . . . . . . . . 7
3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 8
3.5 Relaying Integrity . . . . . . . . . . . . . . . . . . . . 8
3.6 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9
4. The APEX . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . 9
4.2 Profile Identification and Initialization . . . . . . . . 10
4.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Architecture at a Glance . . . . . . . . . . . . . . . . . 4
2. Service Principles . . . . . . . . . . . . . . . . . . . . 5
2.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . 5
2.2 Naming of Entities . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Comparing Endpoints . . . . . . . . . . . . . . . . . . . 7
3. Service Provisioning . . . . . . . . . . . . . . . . . . . 7
3.1 Connection Establishment . . . . . . . . . . . . . . . . . 7
3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 8
3.5 Relaying Integrity . . . . . . . . . . . . . . . . . . . . 8
3.6 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9
4. The APEX . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . 9
4.2 Profile Identification and Initialization . . . . . . . . 10
4.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Message Semantics . . . . . . . . . . . . . . . . . . . . 11
4.4.1 The Attach Operation . . . . . . . . . . . . . . . . . . . 11
4.4.2 The Bind Operation . . . . . . . . . . . . . . . . . . . . 13
4.4.3 The Terminate Operation . . . . . . . . . . . . . . . . . 14
4.4.4 The Data Operation . . . . . . . . . . . . . . . . . . . . 15
4.4.4.1 Relay Processing of Data . . . . . . . . . . . . . . . . . 17
4.4.4.2 Application Processing of Data . . . . . . . . . . . . . . 18
4.5 APEX Access Policies . . . . . . . . . . . . . . . . . . . 19
4.5.1 Access Policies in the Endpoint-Relay Mode . . . . . . . . 19
4.5.2 Access Policies in the Relay-Relay Mode . . . . . . . . . 20
5. APEX Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 The statusRequest Option . . . . . . . . . . . . . . . . . 22
6. APEX Services . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Use of the APEX Core DTD . . . . . . . . . . . . . . . . . 27
6.1.1 Transaction-Identifiers . . . . . . . . . . . . . . . . . 27
6.1.2 The Reply Element . . . . . . . . . . . . . . . . . . . . 28
6.2 The Report Service . . . . . . . . . . . . . . . . . . . . 28
7. Registration Templates . . . . . . . . . . . . . . . . . . 29
7.1 APEX Option Registration Template . . . . . . . . . . . . 29
7.2 APEX Service Registration Template . . . . . . . . . . . . 29
7.3 APEX Endpoint Application Registration Template . . . . . 30
8. Initial Registrations . . . . . . . . . . . . . . . . . . 30
8.1 Registration: The APEX Profile . . . . . . . . . . . . . . 30
8.2 Registration: The System (Well-Known) TCP port number for
apex-mesh . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Registration: The System (Well-Known) TCP port number for
apex-edge . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4 Registration: The statusRequest Option . . . . . . . . . . 31
8.5 Registration: The Report Service . . . . . . . . . . . . . 32
9. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1 The APEX Core DTD . . . . . . . . . . . . . . . . . . . . 32
9.2 The Report Service DTD . . . . . . . . . . . . . . . . . . 34
10. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . 36
References . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 40
4.4 Message Semantics . . . . . . . . . . . . . . . . . . . . 11
4.4.1 The Attach Operation . . . . . . . . . . . . . . . . . . . 11
4.4.2 The Bind Operation . . . . . . . . . . . . . . . . . . . . 13
4.4.3 The Terminate Operation . . . . . . . . . . . . . . . . . 14
4.4.4 The Data Operation . . . . . . . . . . . . . . . . . . . . 15
4.4.4.1 Relay Processing of Data . . . . . . . . . . . . . . . . . 17
4.4.4.2 Application Processing of Data . . . . . . . . . . . . . . 18
4.5 APEX Access Policies . . . . . . . . . . . . . . . . . . . 19
4.5.1 Access Policies in the Endpoint-Relay Mode . . . . . . . . 19
4.5.2 Access Policies in the Relay-Relay Mode . . . . . . . . . 20
5. APEX Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 The statusRequest Option . . . . . . . . . . . . . . . . . 22
6. APEX Services . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Use of the APEX Core DTD . . . . . . . . . . . . . . . . . 27
6.1.1 Transaction-Identifiers . . . . . . . . . . . . . . . . . 27
6.1.2 The Reply Element . . . . . . . . . . . . . . . . . . . . 28
6.2 The Report Service . . . . . . . . . . . . . . . . . . . . 28
7. Registration Templates . . . . . . . . . . . . . . . . . . 29
7.1 APEX Option Registration Template . . . . . . . . . . . . 29
7.2 APEX Service Registration Template . . . . . . . . . . . . 29
7.3 APEX Endpoint Application Registration Template . . . . . 30
8. Initial Registrations . . . . . . . . . . . . . . . . . . 30
8.1 Registration: The APEX Profile . . . . . . . . . . . . . . 30
8.2 Registration: The System (Well-Known) TCP port number for
apex-mesh . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Registration: The System (Well-Known) TCP port number for
apex-edge . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4 Registration: The statusRequest Option . . . . . . . . . . 31
8.5 Registration: The Report Service . . . . . . . . . . . . . 32
9. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1 The APEX Core DTD . . . . . . . . . . . . . . . . . . . . 32
9.2 The Report Service DTD . . . . . . . . . . . . . . . . . . 34
10. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . 36
References . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 40
Network applications can be broadly distinguished by five operational characteristics:
网络应用程序可通过五个操作特征进行广泛区分：
o server push or client pull;
o 服务器推送或客户端拉取；
o synchronous (interactive) or asynchronous (batch);
o 同步（交互）或异步（批处理）；
o time-assured or time-insensitive;
o 有时间保证或对时间不敏感；
o best-effort or reliable; and,
o 尽最大努力或可靠；和
o stateful or stateless.
o 有状态的或无状态的。
For example:
例如：
o the world-wide web is a pull, synchronous, time-insensitive, reliable, stateless service; whilst
o 万维网是一个拉式的、同步的、不区分时间的、可靠的、无状态的服务；同时
o Internet mail is a push, asynchronous, time-insensitive, best-effort (without DSN), stateless service.
o Internet邮件是一种推送、异步、不区分时间、尽力而为（无DSN）的无状态服务。
Messaging applications vary considerably in their operational requirements. For example, some messaging applications require assurance of timeliness and reliability, whilst others do not.
消息传递应用程序在其操作要求上有很大差异。例如，一些消息传递应用程序需要确保及时性和可靠性，而其他应用程序则不需要。
These features come at a cost, in terms of both infrastructural and configuration complexity. Accordingly, the underlying service must be extensible to support different requirements in a consistent manner.
这些功能在基础设施和配置复杂性方面都是有代价的。因此，基础服务必须是可扩展的，以一致的方式支持不同的需求。
This memo defines a core messaging service that supports a range of operational characteristics. The core service supports a variety of tailored services for both user-based and programmatic exchanges.
此备忘录定义了支持一系列操作特征的核心消息服务。核心服务支持各种定制服务，用于基于用户和编程的交换。
APEX provides an extensible, asynchronous message relaying service for application layer programs.
APEX为应用层程序提供了一个可扩展的异步消息中继服务。
APEX, at its core, provides a best-effort datagram service. Each datagram, simply termed "data", is originated and received by APEX "endpoints" -- applications that dynamically attach to the APEX "relaying mesh".
APEX的核心是提供尽力而为的数据报服务。每个数据报，简称为“数据”，都由APEX“端点”发起和接收，即动态连接到APEX“中继网格”的应用程序。
The data transmitted specifies:
传输的数据规定：
o an originating endpoint;
o 起始端点；
o an opaque content (via a URI-reference);
o 不透明内容（通过URI引用）；
o one or more recipient endpoints; and,
o 一个或多个接收方端点；和
o zero or more options.
o 零个或多个选项。
Options are used to alter the semantics of the service, which may occur on a per-recipient or per-data basis, and may be processed by either a single or multiple relays.
选项用于更改服务的语义，这可能发生在每个收件人或每个数据的基础上，并且可能由单个或多个中继处理。
Additional APEX services are provided on top of the relaying mesh; e.g., access control and presence information.
在中继网的顶部提供额外的APEX服务；e、 例如，访问控制和状态信息。
APEX is specified, in part, as a BEEP [1] "profile". Accordingly, many aspects of APEX (e.g., authentication) are provided within the BEEP core. Throughout this memo, the terms "peer", "initiator", "listener", "client", and "server" are used in the context of BEEP. In particular, Section 2.1 of the BEEP core memo discusses the roles that a BEEP peer may perform.
APEX部分指定为蜂鸣音[1]“轮廓”。因此，在BEEP核心中提供了APEX的许多方面（例如，认证）。在本备忘录中，术语“对等方”、“发起方”、“侦听器”、“客户端”和“服务器”用于BEEP上下文。特别是，BEEP核心备忘录的第2.1节讨论了BEEP对等方可能执行的角色。
When reading this memo, note that the terms "endpoint" and "relay" are specific to APEX, they do not exist in the context of BEEP.
阅读本备忘录时，请注意术语“端点”和“中继”是特定于APEX的，它们不存在于BEEP上下文中。
The APEX stack:
顶点堆栈：
+-------------+
| APEX | an APEX process is either:
| process |
+-------------+ - an application attached as an APEX
| | endpoint; or,
| APEX |
| | - an APEX relay
+-------------+
| | APEX services are realized as applications
| BEEP | having a special relationship with the APEX
| | relays in their administrative domain
+-------------+
| TCP |
+-------------+
| ... |
+-------------+
+-------------+
| APEX | an APEX process is either:
| process |
+-------------+ - an application attached as an APEX
| | endpoint; or,
| APEX |
| | - an APEX relay
+-------------+
| | APEX services are realized as applications
| BEEP | having a special relationship with the APEX
| | relays in their administrative domain
+-------------+
| TCP |
+-------------+
| ... |
+-------------+
The APEX entities:
APEX实体：
administrative domain #1 administrative domain #2
+----------------------------+ +----------------------------+
| +------+ | | +------+ |
| | | | | | | |
| | appl | | | | appl | |
| | | | | | | |
| +......+ +------+ | | +------+ +......+ |
| | | | | | | | | | | |
| |end- | |relay | | | |relay | |end- | |
| | point| | | | | | | | point| |
| +------+ +------+ | | +------+ +------+ |
| | | | | | | | | | | |
| | APEX | | APEX | | | | APEX | | APEX | |
| | | | | | | | | | | |
| +------+ +------+ | | +------+ +------+ |
| || || || | | || || || |
| ============= ================ ============= |
+----------------------------+ +----------------------------+
administrative domain #1 administrative domain #2
+----------------------------+ +----------------------------+
| +------+ | | +------+ |
| | | | | | | |
| | appl | | | | appl | |
| | | | | | | |
| +......+ +------+ | | +------+ +......+ |
| | | | | | | | | | | |
| |end- | |relay | | | |relay | |end- | |
| | point| | | | | | | | point| |
| +------+ +------+ | | +------+ +------+ |
| | | | | | | | | | | |
| | APEX | | APEX | | | | APEX | | APEX | |
| | | | | | | | | | | |
| +------+ +------+ | | +------+ +------+ |
| || || || | | || || || |
| ============= ================ ============= |
+----------------------------+ +----------------------------+
| <---- APEX relaying mesh ----> |
| <---- APEX relaying mesh ----> |
Note: relaying between administrative domains is configured using SRV RRs. Accordingly, the actual number of relays between two endpoints is not fixed.
注意：使用SRV RRs配置管理域之间的中继。因此，两个端点之间的继电器的实际数量不是固定的。
APEX is used in two modes:
APEX有两种使用模式：
endpoint-relay: in which the endpoint is always the BEEP initiator of the service, whilst relays are always the BEEP listeners. In this context, applications attach as endpoints, and then the transmission of data occurs.
端点中继：其中端点始终是服务的嘟嘟声启动器，而中继始终是嘟嘟声侦听器。在此上下文中，应用程序作为端点连接，然后进行数据传输。
relay-relay: in which relays typically, though not necessarily, reside in different administrative domains. In this context, applications bind as relays, and then the transmission of data occurs.
中继：中继通常（尽管不一定）驻留在不同的管理域中。在这种情况下，应用程序绑定为中继，然后进行数据传输。
In the endpoint-relay mode, an endpoint (BEEP initiator) may:
在端点中继模式下，端点（蜂鸣启动器）可以：
o attach as one or more endpoints;
o 附加为一个或多个端点；
o send data to other endpoints;
o 向其他端点发送数据；
o receive data from other endpoints; and,
o 从其他端点接收数据；和
o terminate any of its attachments.
o 终止其任何附件。
A relay (BEEP listener), in addition to servicing requests from a BEEP initiator, may:
中继（蜂鸣监听器）除了为来自蜂鸣启动器的请求提供服务外，还可以：
o terminate any of the endpoint's attachments;
o 终止端点的任何附件；
o deliver data from other endpoints; and,
o 从其他端点传递数据；和
o indicate the delivery status of data sent earlier by the endpoint.
o 指示端点先前发送的数据的传递状态。
In the relay-relay mode, a relay (BEEP listener or initiator) may:
在中继模式下，中继（蜂鸣监听器或启动器）可能：
o bind as one or more administrative domains;
o 绑定为一个或多个管理域；
o send data;
o 发送数据；
o receive data; and,
o 接收数据；和
o terminate any bindings.
o 终止任何绑定。
Endpoints are named using the following ABNF [2] syntax:
端点使用以下ABNF[2]语法命名：
;; Domain is defined in [3], either a FQDN or a literal
entity = local "@" Domain
;; Domain is defined in [3], either a FQDN or a literal
entity = local "@" Domain
local = address [ "/" subaddress ]
本地=地址[“/”子地址]
address = token
address = token
subaddress = token
subaddress = token
;; all non-control characters, excluding "/" and "@" delimiters
token = 1*(%x20-2E / %x30-3F / %x41-7E / UTF-8) ;; [4]
;; all non-control characters, excluding "/" and "@" delimiters
token = 1*(%x20-2E / %x30-3F / %x41-7E / UTF-8) ;; [4]
Two further conventions are applied when using this syntax:
使用此语法时还应用了两个约定：
the "apex=" convention: All endpoint identities having a local-part starting with "apex=" are reserved for use by APEX services registered with the IANA; and,
“apex=”约定：所有具有以“apex=”开头的本地部分的端点标识都保留供在IANA注册的apex服务使用；和
the "subaddress" convention: If the solidus character ("/", decimal code 47) occurs in the local-part, this identifies a subaddress of an endpoint identity (e.g., "fred/appl=wb@example.com" is a subaddress of the APEX endpoint "fred@example.com").
“子地址”约定：如果本地部分出现实线字符（“/”，十进制代码47），则表示端点标识的子地址（例如，“fred/appl”=wb@example.com“是顶点终结点的子地址”fred@example.com").
All subaddresses starting with "appl=" are reserved for use by APEX endpoint applications registered with the IANA.
所有以“appl=”开头的子地址都保留供在IANA注册的APEX端点应用程序使用。
Relays, although not named, serve of behalf of administrative domains, as identified by a FQDN or a domain-literal, e.g., "example.com" or "[10.0.0.1]".
中继，尽管未命名，但代表管理域，由FQDN或域文字标识，例如，“example.com”或“[10.0.0.1]”。
In APEX, "endpoints" and "relays" are the fundamental entities. APEX is carried over BEEP, which has the "peer" as its fundamental entity. The relationship between BEEP peer entities and APEX endpoint and relay entities are defined by APEX's Access Policies (Section 4.5).
在APEX中，“端点”和“中继”是基本实体。APEX由BEEP继承，BEEP以“对等体”为基本实体。BEEP对等实体与APEX端点和中继实体之间的关系由APEX的访问策略定义（第4.5节）。
Note that since the "local" part of an entity is a string of UTF-8 [4] octets, comparison operations on the "local" part use exact matching (i.e., are case-sensitive).
注意，由于实体的“本地”部分是UTF-8[4]八位字节的字符串，“本地”部分上的比较操作使用精确匹配（即区分大小写）。
Accordingly, "fred@example.com" and "Fred@example.com" refer to different endpoints. Of course, relays serving the "example.com" administrative domain may choose to treat the two endpoints identically for the purposes of routing and delivery.
因此，”fred@example.com“和”Fred@example.com“引用不同的端点。当然，服务于“example.com”管理域的中继器可以出于路由和传递的目的选择相同地处理两个端点。
Finally, note that if an APEX endpoint is represented using a transmission encoding, then, prior to comparison, the encoding is reversed. For example, if the URL encoding is used, then "apex:fred@example.com" is identical to "apex:f%72ed@example.com".
最后，请注意，如果使用传输编码表示顶点端点，则在比较之前，编码是反向的。例如，如果使用URL编码，则“apex:fred@example.com“与”顶点：f%相同72ed@example.com".
The SRV algorithm [5] is used to determine the IP/TCP addressing information assigned to the relays for an administrative domain identified by a FQDN:
SRV算法[5]用于确定分配给FQDN标识的管理域中继器的IP/TCP寻址信息：
service: "apex-edge" (for the endpoint-relay mode), or "apex-mesh" (for the relay-relay mode);
服务：“顶点边缘”（用于端点中继模式）或“顶点网格”（用于中继模式）；
protocol: "tcp"; and,
协议：“tcp”；和
domain: the administrative domain.
域：管理域。
If the administrative domain is identified by a domain-literal, then the IP address information is taken directly from the literal and the TCP port number used is assigned by the IANA for the registration in Section 8.2.
如果管理域由域文字标识，则IP地址信息直接取自文字，所使用的TCP端口号由IANA分配，用于第8.2节中的注册。
Authentication is a matter of provisioning for each BEEP peer (c.f., Section 4.5).
身份验证是为每个BEEP对等方提供的问题（c.f.，第4.5节）。
An APEX relay might be provisioned to allow a BEEP peer identity to coincide with a given endpoint identity. For example, a relay in the "example.com" administrative domain may be configured to allow a BEEP peer identified as "fred@example.com" to be authorized to attach as the APEX endpoint "fred@example.com".
An APEX relay might be provisioned to allow a BEEP peer identity to coincide with a given endpoint identity. For example, a relay in the "example.com" administrative domain may be configured to allow a BEEP peer identified as "fred@example.com" to be authorized to attach as the APEX endpoint "fred@example.com".translate error, please retry
Authorization is a matter of provisioning for each BEEP peer (c.f., Section 4.5).
授权是为每个BEEP对等机进行的配置（c.f.，第4.5节）。
Typically, a relay requires that its BEEP peer authenticate as a prelude to authorization, but an endpoint usually does not require the same of its BEEP peer.
通常，中继要求其BEEP对等方进行身份验证，作为授权的前奏，但端点通常不要求其BEEP对等方进行相同的身份验证。
Confidentiality is a matter of provisioning for each BEEP peer.
保密性是为每个BEEP对等方提供的一个问题。
Typically, any data considered sensitive by an originating endpoint will have its content encrypted for the intended recipient endpoint(s), rather than relying on hop-by-hop encryption. Similarly, an originating endpoint will sign the content if end-to-end authentication is desired.
通常，发起端点认为敏感的任何数据都将针对预期的接收方端点对其内容进行加密，而不是依赖逐跳加密。类似地，如果需要端到端身份验证，则发起端点将对内容进行签名。
Data are relayed according to SRV entries in the DNS. Accordingly, relaying integrity is a function of the DNS and the applications making use of the DNS. Additional assurance is provided if the BEEP initiator requires that the BEEP listener authenticate itself.
数据根据DNS中的SRV条目进行中继。因此，中继完整性是DNS和使用DNS的应用程序的功能。如果蜂鸣器启动器要求蜂鸣器侦听器进行自身身份验证，则会提供额外的保证。
Hop-by-hop protection of data transmitted through the relaying mesh (endpoint identities and content) is afforded at the BEEP level through the use of a transport security profile. Other traffic characteristics, e.g., volume and timing of transmissions, are not protected from third-party analysis.
通过使用传输安全配置文件，在BEEP级别对通过中继网传输的数据（端点标识和内容）提供逐跳保护。其他流量特性（例如，传输量和定时）不受第三方分析的保护。
Section 8.1 contains the BEEP profile registration for APEX.
第8.1节包含APEX的蜂鸣音配置文件注册。
Each BEEP payload exchanged via APEX consists of an XML document and possibly an arbitrary MIME content.
通过APEX交换的每个BEEP有效负载都由一个XML文档和可能的任意MIME内容组成。
If only an XML document is sent in the BEEP payload, then the mapping to a BEEP payload is straight-forward, e.g.,
如果在BEEP有效负载中仅发送XML文档，则到BEEP有效负载的映射是直接的，例如。，
C: MSG 1 2 . 111 39
C: Content-Type: application/beep+xml
C:
C: <terminate transID='1' />
C: END
C: MSG 1 2 . 111 39
C: Content-Type: application/beep+xml
C:
C: <terminate transID='1' />
C: END
Otherwise, if an arbitrary MIME content is present, it is indicated by a URI-reference [6] in the XML control document. The URI-reference may contain an absolute-URI (and possibly a fragment-identifier), or it may be a relative-URI consisting only of a fragment-identifier. Arbitrary MIME content is included in the BEEP payload by using a "multipart/related" [7], identified using a "cid" URL [8], and the XML control document occurs as the start of the "multipart/related", e.g.,
否则，如果存在任意MIME内容，它将由XML控制文档中的URI引用[6]指示。URI引用可能包含一个绝对URI（可能还有一个片段标识符），也可能是一个仅由片段标识符组成的相对URI。通过使用“多部分/相关”[7]将任意MIME内容包括在BEEP有效载荷中，使用“cid”URL[8]标识，并且XML控制文档作为“多部分/相关”的开始出现，例如。，
C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: </data>
C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: </data>
C: --boundary
C: Content-Type: image/gif
C: Content-Transfer-Encoding: binary
C: Content-ID: <2@example.com>
C:
C: ...
C: --boundary--
C: END
C: --boundary
C: Content-Type: image/gif
C: Content-Transfer-Encoding: binary
C: Content-ID: <2@example.com>
C:
C: ...
C: --boundary--
C: END
Because BEEP provides an 8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Further, note that MIME [9] requires that the value of the "Content-ID" header be globally unique.
由于BEEP提供8位宽的路径，因此不应使用“转换性”内容传输编码（例如，“base64”或“可打印引用”）。此外，请注意，MIME[9]要求“Content ID”头的值是全局唯一的。
If the arbitrary MIME content is itself an XML document, it may be contained within the control document directly as a "data-content" element, and identified using a URI-reference consisting of only a fragment-identifier, e.g.,
如果任意MIME内容本身是一个XML文档，则它可以作为“数据内容”元素直接包含在控制文档中，并使用仅包含片段标识符的URI引用进行标识，例如。，
C: MSG 1 1 . 42 295
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: <data-content Name='Content'>
C: <statusResponse transID='86'>
C: <destination identity='barney@example.com'>
C: <reply code='250' />
C: </destination>
C: </statusResponse>
C: </data-content>
C: </data>
C: END
C: MSG 1 1 . 42 295
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: <data-content Name='Content'>
C: <statusResponse transID='86'>
C: <destination identity='barney@example.com'>
C: <reply code='250' />
C: </destination>
C: </statusResponse>
C: </data-content>
C: </data>
C: END
The APEX is identified as
顶点被确定为
http://iana.org/beep/APEX
http://iana.org/beep/APEX
in the BEEP "profile" element during channel creation.
在频道创建过程中，在“配置文件”元素中。
No elements are required to be exchanged during channel creation; however, in the endpoint-relay mode, the BEEP initiator will typically include an "attach" element during channel creation, e.g.,
通道创建期间无需交换任何元素；然而，在端点中继模式下，蜂鸣音启动器通常会在通道创建期间包括一个“连接”元素，例如。，
<start number='1'>
<profile uri='http://iana.org/beep/APEX'>
<![CDATA[<attach endpoint='fred@example.com'
transID='1' />]]>
</profile>
</start>
<start number='1'>
<profile uri='http://iana.org/beep/APEX'>
<![CDATA[<attach endpoint='fred@example.com'
transID='1' />]]>
</profile>
</start>
Similarly, in the relay-relay mode, the BEEP initiator will typically include an "bind" element during channel creation, e.g.,
类似地，在中继模式下，蜂鸣音启动器通常在通道创建期间包括“绑定”元素，例如。，
<start number='1'>
<profile uri='http://iana.org/beep/APEX'>
<![CDATA[<bind relay='example.com'
transID='1' />]]>
</profile>
</start>
<start number='1'>
<profile uri='http://iana.org/beep/APEX'>
<![CDATA[<bind relay='example.com'
transID='1' />]]>
</profile>
</start>
Section 9.1 defines the BEEP payloads that are used in the APEX.
第9.1节定义了APEX中使用的BEEP有效载荷。
When an application wants to attach to the relaying mesh as a given endpoint, it sends an "attach" element to a relay, e.g.,
当应用程序希望作为给定端点连接到中继网格时，它会向中继发送“连接”元素，例如。，
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
or
或
+-------+ +-------+
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
| appl. | | relay |
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
| appl. | | relay |
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
C: <attach endpoint='wilma@example.com' transID='2' />
S: <ok />
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
C: <attach endpoint='wilma@example.com' transID='2' />
S: <ok />
or
或
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <error code='537'>access denied</error>
C: <attach endpoint='fred@example.com' transID='1' />
S: <error code='537'>access denied</error>
The "attach" element has an "endpoint" attribute, a "transID" attribute, and contains zero or more "option" elements:
“attach”元素具有“endpoint”属性、“transID”属性，并且包含零个或多个“option”元素：
o the "endpoint" attribute specifies the endpoint that the application wants to attach as;
o “endpoint”属性指定应用程序要附加为的端点；
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
o “transID”属性指定与此操作关联的事务标识符；和
o the "option" elements, if any, specify additional processing options (Section 5).
o “选项”元素（如果有）指定了其他处理选项（第5节）。
When a relay receives an "attach" element, it performs these steps:
当继电器接收到“连接”元件时，它将执行以下步骤：
1. If the transaction-identifier refers to a previous, non-terminated operation on this BEEP channel, an "error" element having code 555 is returned.
1. 如果事务标识符引用了此蜂鸣通道上先前的未终止操作，则返回代码为555的“错误”元素。
2. If the relay is in a different administrative domain than this endpoint, an "error" element having code 553 is returned.
2. 如果中继位于与此端点不同的管理域中，则返回代码为553的“error”元素。
3. If the application is not authorized to attach as this endpoint (c.f., Section 4.5.1), an "error" element having code 537 is returned.
3. 如果应用程序未被授权作为该端点连接（c.f.，第4.5.1节），则返回代码为537的“错误”元素。
4. If any options are present, they are processed.
4. 如果存在任何选项，将对其进行处理。
5. If another application has already attached as this endpoint, an "error" element having code 554 is returned.
5. 如果另一个应用程序已作为该端点连接，则返回代码为554的“error”元素。
6. Otherwise, the application is bound as this endpoint, and an "ok" element is returned.
6. 否则，应用程序被绑定为该端点，并返回一个“ok”元素。
When an application wants to identify itself as a relay, it sends a "bind" element to another relay, e.g.,
当应用程序想要将自己标识为中继时，它会向另一个中继发送一个“绑定”元素，例如。，
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <bind relay='example.com' transID='1' />
S: <ok />
C: <bind relay='example.com' transID='1' />
S: <ok />
or
或
+-------+ +-------+
| | -- bind -------> | |
| | | |
| | <--------- ok -- | |
| relay | | relay |
| #1 | -- bind -------> | #2 |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- bind -------> | |
| | | |
| | <--------- ok -- | |
| relay | | relay |
| #1 | -- bind -------> | #2 |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
C: <bind relay='example.com' transID='1' />
S: <ok />
C: <bind relay='rubble.com' transID='2' />
S: <ok />
C: <bind relay='example.com' transID='1' />
S: <ok />
C: <bind relay='rubble.com' transID='2' />
S: <ok />
or
或
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <------ error -- | #2 |
+-------+ +-------+
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <------ error -- | #2 |
+-------+ +-------+
C: <bind relay='example.com' transID='1' />
S: <error code='537'>access denied</error>
C: <bind relay='example.com' transID='1' />
S: <error code='537'>access denied</error>
The "bind" element has a "relay" attribute, a "transID" attribute, and contains zero or more "option" elements:
“bind”元素具有“relay”属性、“transID”属性，并且包含零个或多个“option”元素：
o the "relay" attribute specifies the administrative domain on whose behalf the application wants to serve;
o “中继”属性指定应用程序希望为其服务的管理域；
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
o “transID”属性指定与此操作关联的事务标识符；和
o the "option" elements, if any, specify additional processing options (Section 5).
o “选项”元素（如果有）指定了其他处理选项（第5节）。
When a relay receives an "bind" element, it performs these steps:
当继电器接收到“绑定”元素时，它将执行以下步骤：
1. If the transaction-identifier refers to a previous, non-terminated operation on this BEEP channel, an "error" element having code 555 is returned.
1. 如果事务标识符引用了此蜂鸣通道上先前的未终止操作，则返回代码为555的“错误”元素。
2. If the application is not authorized to bind on behalf of this administrative domain (c.f., Section 4.5.2), an "error" element having code 537 is returned.
2. 如果未授权应用程序代表该管理域绑定（c.f.，第4.5.2节），则返回代码为537的“错误”元素。
3. If any options are present, they are processed.
3. 如果存在任何选项，将对其进行处理。
4. Otherwise, the application is accepted as serving this administrative domain, and an "ok" element is returned.
4. 否则，应用程序将被接受为服务于此管理域，并返回“ok”元素。
When an application or relay wants to release an attachment or binding, it sends a "terminate" element, e.g.,
当应用程序或中继想要释放附件或绑定时，它会发送一个“终止”元素，例如。，
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <terminate transID='1' />
S: <ok />
C: <terminate transID='1' />
S: <ok />
or
或
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
C: <terminate transID='13' />
S: <error code='550'>unknown transaction-identifier</error>
C: <terminate transID='13' />
S: <error code='550'>unknown transaction-identifier</error>
or
或
+-------+ +-------+
| | <-- terminate -- | |
| appl. | | relay |
| | -- ok ---------> | |
+-------+ +-------+
+-------+ +-------+
| | <-- terminate -- | |
| appl. | | relay |
| | -- ok ---------> | |
+-------+ +-------+
C: <terminate transID='1' />
S: <ok />
C: <terminate transID='1' />
S: <ok />
The "terminate" element has a "transID" attribute, an optional "code" attribute, an optional "xml:lang" attribute, and may contain arbitrary textual content:
“terminate”元素有一个“transID”属性、一个可选的“code”属性、一个可选的“xml:lang”属性，并且可以包含任意文本内容：
o the "transID" attribute specifies the transaction-identifier associated with this operation;
o “transID”属性指定与此操作关联的事务标识符；
o the "code" attribute, if present, is a three-digit reply code meaningful to programs (c.f., Section 10);
o “代码”属性（如果存在）是对程序有意义的三位数回复代码（c.f.，第10节）；
o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and,
o “xml:lang”属性（如果存在）指定编写元素内容的语言；和
o the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users.
o 文本内容是一种诊断（可能是多行的），对实现者、管理员甚至用户都有意义。
When an application or relay receives a "terminate" element, it performs these steps:
当应用程序或继电器收到“终止”元素时，它将执行以下步骤：
1. If the value of the transaction-identifier is zero, then all associations established by this application over this BEEP session, either as an endpoint attachment or a relay binding, are terminated, and an "ok" element is returned.
1. 如果事务标识符的值为零，则终止此应用程序在此BEEP会话上建立的所有关联（作为端点附件或中继绑定），并返回“ok”元素。
2. Otherwise, if the transaction-identifier does not refer to a previous unterminated operation on this BEEP channel, an "error" element having code 550 is returned.
2. 否则，如果事务标识符未引用此蜂鸣声通道上先前未终止的操作，则返回代码为550的“error”元素。
3. Otherwise, the application is no longer bound as an endpoint or a relay, and an "ok" element is returned.
3. 否则，应用程序不再绑定为端点或中继，并返回“ok”元素。
When an application or relay wants to transmit data over the relaying mesh, it sends a "data" element, e.g.,
当应用程序或中继想要通过中继网传输数据时，它会发送一个“数据”元素，例如。，
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <ok />
or
或
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <------ error -- | |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <------ error -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <error code='537'>access denied</error>
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <error code='537'>access denied</error>
or
或
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
</data>
S: <ok />
The "data" element has a "content" attribute, and contains an "originator" element, one or more "recipient" elements, zero or more "option" elements, and, optionally, a "data-content" element:
“数据”元素具有“内容”属性，并包含一个“发起人”元素、一个或多个“收件人”元素、零个或多个“选项”元素，以及可选的“数据内容”元素：
o the "content" attribute is a URI-reference that specifies the contents of the data (c.f., Section 4.1);
o “内容”属性是指定数据内容的URI引用（c.f.，第4.1节）；
o the "originator" element refers to the endpoint sending the data;
o “发起人”元素是指发送数据的端点；
o each "recipient" element refers to an endpoint destination for the data;
o 每个“接收者”元素表示数据的端点目的地；
o the "option" elements, if any, specify additional processing options (Section 5), termed per-data options; and,
o “选项”元素（如有）规定了附加处理选项（第5节），称为每个数据选项；和
o the "data-content" element, if present, specifies a nested XML entity that is referenced using a URI fragment-identifier as the value of the "content" attribute.
o “datacontent”元素（如果存在）指定一个嵌套的XML实体，该实体使用URI片段标识符作为“content”属性的值进行引用。
The "originator" element has an "identity" attribute, and contains zero or more option elements:
“originator”元素具有“identity”属性，并且包含零个或多个选项元素：
o the "identity" attribute specifies the sending endpoint; and
o “identity”属性指定发送端点；和
o the "option" elements, if any, specify additional processing options for the originator, termed per-originator options.
o “选项”元素（如有）规定了发端人的其他处理选项，称为每个发端人选项。
Each "recipient" element has an "identity" attribute, and contains zero or more option elements:
每个“收件人”元素都有一个“标识”属性，并且包含零个或多个选项元素：
o the "identity" attribute specifies the destination endpoint; and
o “identity”属性指定目标端点；和
o the "option" elements, if any, specify additional processing options for this recipient, termed per-recipient options.
o “选项”元素（如果有）指定此收件人的其他处理选项，称为“每个收件人选项”。
When a relay receives a "data" element, it performs these steps:
当继电器接收到“数据”元素时，它将执行以下步骤：
1. If the BEEP client is not authorized to originate or relay data on behalf of the "originator" endpoint (c.f., Section 4.5), an "error" element having code 537 is returned.
1. 如果未授权BEEP客户端代表“发起人”端点发起或中继数据（c.f.，第4.5节），则返回代码为537的“错误”元素。
2. If any per-data options are present, they are processed.
2. 如果存在任何每个数据选项，则会对其进行处理。
3. An "ok" element is returned.
3. 返回一个“ok”元素。
4. If any per-originator options are present, they are processed.
4. 如果存在任何每个发起人选项，则会对其进行处理。
5. For each recipient:
5. 对于每个收件人：
1. If any per-recipient options are present, they are processed.
1. 如果存在任何每个收件人选项，则会对其进行处理。
2. If the recipient endpoint is not in the administrative domain associated with the relay, then an APEX session is established to a relay that accepts data for the recipient's administrative domain, and a new "data" element, containing that "recipient" element and all applicable options, is sent to that relay.
2. 如果收件人端点不在与该中继关联的管理域中，则将建立一个到中继的APEX会话，该中继接受收件人管理域的数据，并将包含该“收件人”元素和所有适用选项的新“数据”元素发送到该中继。
If an APEX session is established, the new "data" is sent, and the recipient's relay returns an "ok" element, then the recipient is considered to be successfully processed.
如果建立了APEX会话，则发送新的“数据”，并且接收方的中继返回“ok”元素，则认为接收方已成功处理。
3. Otherwise, if the recipient endpoint is in the same administrative domain as the relay, the APEX access service must check that the originator endpoint is allowed to communicate with the recipient endpoint (the access entries [10] whose "owner" is the recipient must contain a "core:data" token for the originator), and the recipient endpoint must be currently attached.
3. 否则，如果接收方端点与中继位于同一管理域中，APEX访问服务必须检查是否允许发起方端点与接收方端点通信（其“所有者”为接收方的访问条目[10]必须包含发起方的“核心：数据”令牌），并且当前必须连接收件人终结点。
If so, a new "data" element, containing only that "recipient" element, is sent to the corresponding application. If the recipient's endpoint returns an "ok" element, then the recipient is considered to be successfully processed.
如果是这样，一个新的“数据”元素（仅包含该“收件人”元素）将被发送到相应的应用程序。如果收件人的端点返回“ok”元素，则认为收件人已成功处理。
Providing that these semantics are preserved, a relay may choose to optimize its behavior by grouping multiple recipients in a single "data" element that is subsequently transmitted.
如果保留了这些语义，中继可以选择通过将多个接收者分组到随后传输的单个“数据”元素中来优化其行为。
Finally, note that a relay receiving a "data" element from an application may be configured to add administrative-specific options.
最后，请注意，从应用程序接收“数据”元素的中继可以配置为添加特定于管理的选项。
Regardless, all relays are expressly forbidden from modifying the content of the "data" element at any time.
无论如何，明确禁止所有继电器在任何时候修改“数据”元素的内容。
When an application receives a "data" element, it performs these steps:
当应用程序收到“数据”元素时，它将执行以下步骤：
1. If any per-data or per-originator options are present, they are not processed (but may be noted).
1. 如果存在任何“每数据”或“每发起人”选项，则不会对其进行处理（但可能会加以说明）。
2. For each recipient:
2. 对于每个收件人：
1. If any per-recipient options are present, they are not processed (but may be noted).
1. 如果存在任何每个收件人选项，则不会对其进行处理（但可能会注明）。
2. If the application is not attached as the recipient endpoint, then an error in processing has occurred.
2. 如果应用程序未作为收件人端点附加，则处理过程中发生错误。
3. Otherwise, the "data" element is further processed in an application-specific manner, and the recipient is considered to be successfully processed.
3. 否则，将以特定于应用程序的方式进一步处理“数据”元素，并且认为接收方已成功处理。
3. If no recipients could be successfully processed, an "error" element is returned; otherwise, an "ok" element is returned.
3. 如果无法成功处理任何收件人，则返回“error”元素；否则，将返回一个“ok”元素。
Access to APEX is provided by the juxtaposition of:
通过并置以下设备可进入APEX：
o authenticating as a BEEP peer;
o 验证为BEEP对等方；
o attaching as an APEX endpoint or binding as an APEX relay; and,
o 作为顶点端点连接或作为顶点中继绑定；和
o being listed as an actor by the APEX access service (c.f., [10]).
o 被APEX访问服务列为参与者（c.f.[10]）。
Each of these activities occurs according to the policies of the relevant administrative domain:
这些活动中的每一项都是根据相关管理领域的政策进行的：
o each administrative domain is responsible for keeping its own house in order through "local provisioning"; and,
o 每个管理域负责通过“本地资源调配”保持自己的内部秩序；和
o each administrative domain decides the level of trust to associate with other administrative domains.
o 每个管理域决定与其他管理域关联的信任级别。
o When an application wants to attach to the relaying mesh, local provisioning maps BEEP peer identities to allowed APEX endpoints (c.f., Step 3 of Section 4.4.1).
o 当应用程序想要连接到中继网格时，本地供应将BEEP对等身份映射到允许的顶点端点（c.f.，第4.4.1节的步骤3）。
Typically, the identity function is used, e.g., if an application authenticates itself as the BEEP peer named as "fred@example.com", it is allowed to attach as the APEX endpoint named as "fred@example.com".
通常使用标识功能，例如，如果应用程序将自己验证为名为“的BEEP对等方”fred@example.com，允许作为名为的顶点端点附加fred@example.com".
However, using the "subaddress" convention of Section 2.2, an application authorized to attach as a given APEX endpoint is also authorized to attach as any subaddress of that APEX endpoint, e.g., an application authorized to attach as the APEX endpoint "fred@example.com" is also authorized to attach as the APEX endpoint "fred/appl=wb@example.com".
但是，使用第2.2节的“子地址”约定，授权作为给定顶点端点附加的应用程序也被授权作为该顶点端点的任何子地址附加，例如，授权作为顶点端点附加的应用程序“fred@example.com“也被授权作为顶点端点连接”fred/appl=wb@example.com".
o When an application wants to send data, local provisioning maps attached endpoints to allowed originators (c.f., Step 1 of Section 4.4.4.1).
o 当应用程序想要发送数据时，本地供应将连接的端点映射到允许的发起人（c.f.，第4.4.4.1节的步骤1）。
Typically, the identity function is used, e.g., if an application attaches as the APEX endpoint named as "fred@example.com", it is allowed to send data originating from the same APEX endpoint. However, other policies are permissible, for example, the administrative domain may allow the application attached as the APEX endpoint named as "wilma@example.com" to send data originating as either "wilma@example.com" or "fred@example.com".
通常使用标识函数，例如，如果应用程序作为名为“的顶点端点连接”fred@example.com“，允许发送来自同一APEX端点的数据。但是，其他策略是允许的，例如，管理域可能允许将应用程序作为名为“”的APEX端点附加wilma@example.com“发送源于以下两种方式之一的数据”wilma@example.com“或”fred@example.com".
o Finally, when a relay is delivering to an endpoint within its own administrative domain, it consults the recipient's access entry looking for an entry having the originator as an actor (c.f., Step 5.3 of Section 4.4.4.1).
o 最后，当中继传送到其自身管理域内的端点时，它会咨询接收者的访问条目，以查找具有发起人作为参与者的条目（c.f.，第4.4.4.1节的步骤5.3）。
o When an application wants to bind as a relay on behalf of an administrative domain, local provisioning may map BEEP peer identities to allowed APEX relays (c.f., Step 3).
o 当应用程序希望代表管理域绑定为中继时，本地设置可能会将BEEP对等身份映射到允许的APEX中继（c.f.，步骤3）。
If so, then typically the identity function is used. e.g., if an application authenticates itself as the BEEP peer named as "example.com", it is allowed to bind as a relay on behalf of the administrative domain "example.com".
如果是，则通常使用标识函数。e、 例如，如果应用程序将自己验证为名为“example.com”的BEEP对等方，则允许它代表管理域“example.com”绑定为中继。
o When a relay is sending data, no access policies, per se, are applied.
o 当中继发送数据时，不会应用访问策略本身。
o When a relay is receiving data, local provisioning maps BEEP peer identities to allowed originators (c.f., Step 1 of Section 4.4.4.1).
o 当中继接收数据时，本地供应将BEEP对等身份映射到允许的发起人（c.f.，第4.4.4.1节的步骤1）。
Typically, the identity function is used, e.g., if a relay authenticates itself as being from the same administrative domain as the originator of the data, then the data is accepted.
通常，使用标识功能，例如，如果中继器将自身认证为来自与数据发起人相同的管理域，则数据被接受。
In addition, some relays may also be configured as "trusted" intermediaries, so that if a BEEP peer authenticates itself as being from such a relay, then the data is accepted.
此外，一些中继器还可以配置为“受信任”的中介体，因此，如果BEEP对等体将自己验证为来自这样的中继器，则数据被接受。
APEX, at its core, provides a best-effort datagram service. Options are used to alter the semantics of the core service.
APEX的核心是提供尽力而为的数据报服务。选项用于更改核心服务的语义。
The semantics of the APEX "option" element are context-specific. Accordingly, the specification of an APEX option must define:
APEX“option”元素的语义是特定于上下文的。因此，APEX选项的规范必须定义：
o the identity of the option;
o 期权的身份；
o the context in which the option may appear;
o 期权可能出现的上下文；
o what content, if any, is contained within the option; and,
o 选项中包含哪些内容（如有）；和
o the processing rules for the option.
o 选项的处理规则。
An option registration template (Section 7.1) organizes this information.
选项注册模板（第7.1节）组织此信息。
An "option" element is contained within either a "data", "originator", "recipient", or an "attach" element, all of which are termed the "containing" element. The "option" element has several attributes and contains arbitrary content:
“选项”元素包含在“数据”、“发起人”、“收件人”或“附加”元素中，所有这些元素都称为“包含”元素。“option”元素具有多个属性并包含任意内容：
o the "internal" and the "external" attributes, exactly one of which is present, uniquely identify the option;
o “内部”和“外部”属性（正好存在其中一个）唯一标识选项；
o the "targetHop" attribute specifies which relays should process the option;
o “targetop”属性指定哪些继电器应处理该选项；
o the "mustUnderstand" attribute specifies whether the option, if unrecognized, must cause an error in processing to occur;
o “mustUnderstand”属性指定该选项（如果无法识别）是否必须导致处理中出现错误；
o the "transID" attribute specifies a transaction-identifier for the option; and,
o “transID”属性指定选项的事务标识符；和
o the "localize" attribute, if present, specifies one or more language tokens, each identifying a desirable language tag to be used if textual diagnostics are returned to the originator.
o “localize”属性（如果存在）指定一个或多个语言标记，每个标记标识在将文本诊断返回给发起人时要使用的理想语言标记。
Note that if the containing element is an "attach", then the values of the "targetHop" and "transID" attributes are ignored.
请注意，如果包含的元素是“attach”，则“targetHop”和“transID”属性的值将被忽略。
The value of the "internal" attribute is the IANA-registered name for the option. If the "internal" attribute is not present, then the value of the "external" attribute is a URI or URI with a fragment-identifier. Note that a relative-URI value is not allowed.
“internal”属性的值是选项的IANA注册名称。如果“internal”属性不存在，“external”属性的值是一个URI或带有片段标识符的URI。请注意，不允许使用相对URI值。
The "targetHop" attribute specifies which relay(s) should process the option:
“targetHP”属性指定哪些继电器应处理选项：
this: the option applies to this relay, and must be removed prior to transmitting the containing element.
该选项：该选项适用于该继电器，必须在传输包含元件之前移除。
final: the option applies to this relay, only if the relay will transmit the containing element directly to the recipient.
最终：仅当中继将包含的元素直接传输给接收方时，该选项才适用于该中继。
all: the option applies to this relay and is retained for the next.
全部：该选项适用于该继电器，并保留用于下一个继电器。
Note that a final relay does not remove any options as it transmits the containing element directly to the recipient.
请注意，最终中继不会删除任何选项，因为它会将包含的元素直接发送给接收方。
The "mustUnderstand" attribute specifies whether the relay may ignore the option if it is unrecognized, and is consulted only if the "targetHop" attribute indicates that the option applies to that relay. If the option applies, and if the value of the "mustUnderstand" attribute is "true", and if the relay does not "understand" the option, then an error in processing has occurred.
“mustUnderstand”属性指定如果无法识别该选项，则中继是否可以忽略该选项，并且仅当“targetop”属性指示该选项适用于该中继时，才会参考该属性。如果该选项适用，并且如果“mustUnderstand”属性的值为“true”，并且如果中继未“理解”该选项，则处理中发生错误。
Section 8.4 contains the APEX option registration for the "statusRequest" option.
第8.4节包含“statusRequest”选项的APEX选项注册。
If this option is present, then each applicable relay sends a "statusResponse" message to the originator. This is done by issuing a data operation whose originator is the report service associated with the issuing relay, whose recipient is the endpoint address of the "statusRequest" originator, and whose content is a "statusResponse" element.
如果存在此选项，则每个适用的继电器将向发端人发送“statusResponse”消息。这是通过发出一个数据操作来完成的，该数据操作的发起人是与发出中继关联的报表服务，其接收方是“statusRequest”发起人的端点地址，其内容是“statusResponse”元素。
A "statusRequest" option MUST NOT be present in any data operation containing a "statusResponse" element. In general, applications should be careful to avoid potential looping behaviors if an option is received in error.
包含“statusResponse”元素的任何数据操作中都不得存在“statusRequest”选项。通常，应用程序应小心避免在错误接收选项时出现潜在的循环行为。
Consider these examples:
考虑这些例子：
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
C: <data content='#Content'>
<originator identity='apex=report@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
or
或
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='550'>unknown endpoint
identity</reply>
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
C: <data content='#Content'>
<originator identity='apex=report@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='550'>unknown endpoint
identity</reply>
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
or
或
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | #1 |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | #1 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| #2 | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| #2 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@example.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| relay | | relay |
| #1 | -- ok ---------> | #2 |
+-------+ +-------+
+-------+ +-------+
| | <------- data -- | |
| relay | | relay |
| #1 | -- ok ---------> | #2 |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@rubble.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@rubble.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
C: <data content='#Content'>
<originator identity='apex=report@rubble.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@rubble.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | #1 |
+-------+ +-------+
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | #1 |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=report@rubble.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@rubble.com'>
<reply code='250' />
</destination>
</statusResponse>
C: <data content='#Content'>
<originator identity='apex=report@rubble.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@rubble.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
</data-content>
</data>
S: <ok />
Note that a trace of a data's passage through the relaying mesh can be achieved by setting the "targetHop" attribute to "all".
请注意，通过将“targettop”属性设置为“all”，可以实现数据通过中继网格的轨迹。
APEX, at its core, provides a best-effort datagram service. Within an administrative domain, all relays must be able to handle messages for any endpoint within that administrative domain. APEX services are logically defined as endpoints but, given their ubiquitous semantics, they do not necessarily need to be associated with a single physical endpoint. As such, they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e.,
APEX的核心是提供尽力而为的数据报服务。在管理域内，所有中继必须能够处理该管理域内任何端点的消息。APEX服务在逻辑上被定义为端点，但鉴于其普遍存在的语义，它们不一定需要与单个物理端点关联。因此，它们可以与管理域内的每个中继共同驻留，即使它们在逻辑上被提供在中继网的顶部，即。，
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
也就是说，应用程序通过与“已知端点”（WKE）交换数据来与APEX服务通信。
For example, APEX applications communicate with the report service by exchanging data with the well-known endpoint "apex=report" in the corresponding administrative domain, e.g., "apex=report@example.com" is the endpoint associated with the report service in the "example.com" administrative domain.
例如，APEX应用程序通过与相应管理域（例如“APEX”）中的知名端点“APEX=report”交换数据来与报表服务通信=report@example.com是与“example.com”管理域中的报表服务关联的端点。
The specification of an APEX service must define:
APEX服务的规范必须定义：
o the WKE of the service;
o 服务的工作；
o the syntax and sequence of messages exchanged with the service;
o 与服务交换的消息的语法和顺序；
o what access control tokens are consulted by the service.
o 服务咨询哪些访问控制令牌。
A service registration template (Section 7.2) organizes this information.
服务注册模板（第7.2节）组织此信息。
Finally, note that within a single administrative domain, the relaying mesh makes use of the APEX access service in order to determine if an originator is allowed to transmit data to a recipient (c.f., Step 5.3 of Section 4.4.4.1).
最后，请注意，在单个管理域内，中继网利用APEX接入服务来确定是否允许发端人向接收方传输数据（c.f.，第4.4.4.1节的步骤5.3）。
The specification of an APEX service may use definitions found in the APEX core DTD (Section 9.1). For example, the reply operation (Section 6.1.2) is defined to provide a common format for responses.
APEX服务的规范可以使用APEX核心DTD（第9.1节）中的定义。例如，应答操作（第6.1.2节）被定义为提供应答的通用格式。
In using APEX's transaction-identifiers, note the following:
在使用APEX的事务标识符时，请注意以下事项：
o In the endpoint-relay and relay-relay modes, transaction-identifiers are meaningful only during the lifetime of a BEEP channel.
o 在端点中继和中继中继模式中，事务标识符仅在蜂鸣通道的生存期内有意义。
For example, when an application issues the attach operation, the associated transaction-identifier has meaning only within the context of the BEEP channel used for the attach operation. When the BEEP connection is released, the channel no longer exists and the application is no longer attached to the relaying mesh.
例如，当应用程序发出附加操作时，关联的事务标识符仅在用于附加操作的BEEP通道的上下文中具有意义。释放蜂鸣连接时，通道不再存在，应用程序不再连接到中继网。
o In contrast, when an application communicates with an APEX service, transaction-identifiers are often embedded in the data that is sent. This means that transaction-identifiers are potentially long-lived.
o 相反，当应用程序与APEX服务通信时，事务标识符通常嵌入在发送的数据中。这意味着事务标识符可能是长期存在的。
For example, an application may attach as an endpoint, send data (containing an embedded transaction-identifier) to a service, and, some time later, detach from the relaying mesh. Later on, a second application may attach as the same endpoint, and send data of its own (also containing embedded transaction-identifiers). Subsequently, the second application may receive data from the service responding to the first application's request and containing the transaction-identifier used by the first application.
例如，应用程序可以作为端点连接，将数据（包含嵌入式事务标识符）发送到服务，并在一段时间后从中继网格分离。稍后，第二个应用程序可以附加为相同的端点，并发送自己的数据（也包含嵌入式事务标识符）。随后，第二应用程序可以从服务接收响应于第一应用程序的请求并包含第一应用程序使用的事务标识符的数据。
To minimize the likelihood of ambiguities with long-lived transaction-identifiers, the values of transaction-identifiers generated by applications should appear to be unpredictable.
为了最大限度地减少长期事务标识符出现歧义的可能性，应用程序生成的事务标识符的值应该是不可预测的。
Many APEX services make use of a reply operation. Although each service defines the circumstances in which a "reply" element is sent, the syntax of the "reply" element is defined in Section 9.1.
许多APEX服务使用应答操作。尽管每个服务都定义了发送“reply”元素的环境，但“reply”元素的语法在第9.1节中有定义。
The "reply" element has a "code" attribute, a "transID" attribute, an optional "xml:lang" attribute, and may contain arbitrary textual content:
“reply”元素具有“code”属性、“transID”属性、可选的“xml:lang”属性，并且可以包含任意文本内容：
o the "code" element specifies a three-digit reply code (c.f., Section 10);
o “代码”元素指定一个三位数的回复代码（c.f.，第10节）；
o the "transID" attribute specifies the transaction-identifier corresponding to this reply;
o “transID”属性指定与此回复对应的事务标识符；
o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and,
o “xml:lang”属性（如果存在）指定编写元素内容的语言；和
o the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users.
o 文本内容是一种诊断（可能是多行的），对实现者、管理员甚至用户都有意义。
Section 8.5 contains the APEX service registration for the report service:
第8.5节包含报告服务的APEX服务注册：
o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=report".
o 在管理域中，使用众所周知的端点“apex=report”对服务进行寻址。
o Section 9.2 defines the syntax of the operations exchanged with the service.
o 第9.2节定义了与服务交换的操作的语法。
o A consumer of the service does not initiate communications with the service.
o 服务的使用者不会启动与服务的通信。
o The service initiates communications by sending data containing the "statusResponse" operation.
o 服务通过发送包含“statusResponse”操作的数据来启动通信。
If a relay processes a "statusRequest" option (Section 5.1), then it sends data to the originator containing a "statusResponse" element (Section 9.2).
如果中继器处理“statusRequest”选项（第5.1节），则它会将包含“statusResponse”元素的数据发送给发起人（第9.2节）。
The "statusResponse" element has a "transID" attribute and contains one or more "destination" elements:
“statusResponse”元素具有“transID”属性，并包含一个或多个“destination”元素：
o the "transID" attribute specifies the value contained in the "statusRequest" option; and,
o “transID”属性指定“statusRequest”选项中包含的值；和
o each "destination" element has an "identity" attribute and contains a "reply" element:
o 每个“目的地”元素都有一个“标识”属性，并包含一个“回复”元素：
* the "identity" attribute specifies the recipient endpoint that is being reported on; and,
* “identity”属性指定正在报告的收件人端点；和
* the "reply" element (Section 6.1.2) specifies the delivery status of that recipient.
* “回复”元素（第6.1.2节）指定收件人的交付状态。
When an APEX option is registered, the following information is supplied:
注册APEX选项时，将提供以下信息：
Option Identification: specify the NMTOKEN or the URI that authoritatively identifies this option.
选项标识：指定授权标识此选项的NMTOKEN或URI。
Present in: specify the APEX elements in which the option may appear.
出现在：指定选项可能出现的顶点元素。
Contains: specify the XML content that is contained within the "option" element.
包含：指定包含在“option”元素中的XML内容。
Processing Rules: specify the processing rules associated with the option.
处理规则：指定与选项关联的处理规则。
Contact Information: specify the postal and electronic contact information for the author of the profile.
联系信息：指定配置文件作者的邮政和电子联系信息。
When an APEX service is registered, the following information is supplied:
注册APEX服务时，将提供以下信息：
Well-Known Endpoint: specify the local-part of an endpoint identity, starting with "apex=".
已知端点：指定端点标识的本地部分，从“apex=”开始。
Syntax of Messages Exchanged: specify the elements exchanged with the service.
交换的消息语法：指定与服务交换的元素。
Sequence of Messages Exchanged: specify the order in which data is exchanged with the service.
交换的消息顺序：指定与服务交换数据的顺序。
Access Control Tokens: specify the token(s) used to control access to the service (c.f., [10]).
访问控制令牌：指定用于控制对服务的访问的令牌（c.f.，[10]）。
Contact Information: specify the postal and electronic contact information for the author of the profile.
联系信息：指定配置文件作者的邮政和电子联系信息。
Note that the endpoints "apex=all" and "apex=core" may not be assigned.
请注意，可能未指定端点“apex=all”和“apex=core”。
When an APEX endpoint application is registered, the following information is supplied:
注册APEX端点应用程序时，将提供以下信息：
Endpoint Application: specify the subaddress used for an endpoint application, starting with "appl=".
端点应用程序：指定用于端点应用程序的子地址，以“appl=”开头。
Application Definition: specify the syntax and semantics of the endpoint application identified by this registration.
应用程序定义：指定此注册标识的端点应用程序的语法和语义。
Contact Information: specify the postal and electronic contact information for the author of the profile.
联系信息：指定配置文件作者的邮政和电子联系信息。
Profile Identification: http://iana.org/beep/APEX
Profile Identification: http://iana.org/beep/APEX
Messages exchanged during Channel Creation: "attach", "bind"
通道创建期间交换的消息：“附加”、“绑定”
Messages starting one-to-one exchanges: "attach", "bind", "terminate", or "data"
开始一对一交换的消息：“附加”、“绑定”、“终止”或“数据”
Messages in positive replies: "ok"
正面回复中的消息：“确定”
Messages in negative replies: "error"
否定回复中的消息：“错误”
Messages in one-to-many exchanges: none
一对多交换中的消息：无
Message Syntax: c.f., Section 9.1
消息语法：c.f.，第9.1节
Message Semantics: c.f., Section 4.4
消息语义：c.f.，第4.4节
Contact Information: c.f., the "Authors' Addresses" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
Protocol Number: TCP
协议编号：TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1
消息格式、类型、操作码和序列：c.f.，第9.1节
Functions: c.f., Section 4.4
职能：c.f.，第4.4节
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: APEX relay-relay service
建议名称：APEX中继服务
Short name: apex-mesh
简称：顶点网格
Contact Information: c.f., the "Authors' Addresses" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
Protocol Number: TCP
协议编号：TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1
消息格式、类型、操作码和序列：c.f.，第9.1节
Functions: c.f., Section 4.4
职能：c.f.，第4.4节
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: APEX endpoint-relay service
建议名称：APEX端点中继服务
Short name: apex-edge
简称：apex edge
Contact Information: c.f., the "Authors' Addresses" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
Option Identification: statusRequest
选项标识：statusRequest
Present in: APEX's "data" and "recipient" elements
存在于：APEX的“数据”和“收件人”元素中
Contains: nothing
包含：无
Processing Rules: c.f., Section 5.1
处理规则：c.f.，第5.1节
Contact Information: c.f., the "Authors' Addresses" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
Well-Known Endpoint: apex=report
已知终点：apex=报告
Syntax of Messages Exchanged: c.f., Section 9.2
交换消息的语法：c.f.，第9.2节
Sequence of Messages Exchanged: c.f., Section 6.2
交换的信息顺序：c.f.，第6.2节
Access Control Tokens: none
访问控制令牌：无
Contact Information: c.f., the "Authors' Addresses" section of this memo
联系方式：c.f.，本备忘录的“作者地址”部分
<!-- DTD for the APEX core, as of 2001-07-09
<!-- 从2001年7月至2009年，顶点核心的DTD
Refer to this DTD as:
将此DTD称为：
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
-->
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
-->
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" "">
%BEEP;
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" "">
%BEEP;
<!-- DTD data types:
<!-- DTD数据类型：
entity syntax/reference example
====== ================ =======
APEX endpoint
ENDPOINT entity, fred@example.com
c.f., Section 2.2
entity syntax/reference example
====== ================ =======
APEX endpoint
ENDPOINT entity, fred@example.com
c.f., Section 2.2
domain, either a FQDN or a literal DOMAIN c.f., [RFC-2821] example.com or [10.0.0.1]
域，FQDN或文字域c.f.，[RFC-2821]example.com或[10.0.0.1]
seconds SECONDS 0..2147483647 600
秒0..2147483647 600
timestamp TIMESTAMP c.f., [12] 2000-05-15T13:02:00-08:00
时间戳时间戳c.f.，[12]2000-05-15T13:02:00-08:00
unique-identifier
唯一标识符
UNIQID 1..2147483647 42
UNIQID 1..2147483647 42
unique-identifier OR zero UNIZID 0..2147483647 0 -->
唯一标识符或零UNIZID 0..2147483647 0-->
<!ENTITY % ENDPOINT "CDATA">
<!ENTITY % DOMAIN "CDATA">
<!ENTITY % SECONDS "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % UNIQID "CDATA">
<!ENTITY % UNIZID "CDATA">
<!ENTITY % ENDPOINT "CDATA">
<!ENTITY % DOMAIN "CDATA">
<!ENTITY % SECONDS "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % UNIQID "CDATA">
<!ENTITY % UNIZID "CDATA">
<!--
APEX messages, exchanged as application/beep+xml
<!--
APEX messages, exchanged as application/beep+xml
role MSG RPY ERR
====== === === ===
I attach ok error
role MSG RPY ERR
====== === === ===
I attach ok error
I or L bind ok error
我或我绑定ok错误
I or L terminate ok error
我或我终止ok错误
I or L data ok error -->
I或L数据正常错误-->
<!ELEMENT attach (option*)>
<!ATTLIST attach
endpoint %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT attach (option*)>
<!ATTLIST attach
endpoint %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT bind (option*)>
<!ATTLIST bind
relay %DOMAIN; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT bind (option*)>
<!ATTLIST bind
relay %DOMAIN; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT terminate (#PCDATA)>
<!ATTLIST terminate
code %XYZ; "250"
xml:lang %LANG; #IMPLIED
transID %UNIZID; "0">
<!ELEMENT terminate (#PCDATA)>
<!ATTLIST terminate
code %XYZ; "250"
xml:lang %LANG; #IMPLIED
transID %UNIZID; "0">
<!ELEMENT data (originator,recipient+,option*,data-content?)>
<!ATTLIST data
content %URI; #REQUIRED>
<!ELEMENT data (originator,recipient+,option*,data-content?)>
<!ATTLIST data
content %URI; #REQUIRED>
<!ELEMENT originator (option*)>
<!ELEMENT originator (option*)>
<!ATTLIST originator
identity %ENDPOINT; #REQUIRED>
<!ATTLIST originator
identity %ENDPOINT; #REQUIRED>
<!ELEMENT recipient (option*)>
<!ATTLIST recipient
identity %ENDPOINT; #REQUIRED>
<!ELEMENT recipient (option*)>
<!ATTLIST recipient
identity %ENDPOINT; #REQUIRED>
<!ELEMENT data-content
ANY>
<!ATTLIST Name ID #REQUIRED>
<!ELEMENT data-content
ANY>
<!ATTLIST Name ID #REQUIRED>
<!ELEMENT ok EMPTY>
<!ELEMENT ok EMPTY>
<!ELEMENT reply (#PCDATA)>
<!ATTLIST reply
code %XYZ; #REQUIRED
transID %UNIQID; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT reply (#PCDATA)>
<!ATTLIST reply
code %XYZ; #REQUIRED
transID %UNIQID; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!-- either the "internal" or the "external" attribute is present in
an option -->
<!-- either the "internal" or the "external" attribute is present in
an option -->
<!ELEMENT option ANY> <!ATTLIST option internal NMTOKEN "" external %URI; "" targetHop (this|final|all) "final" mustUnderstand (true|false) "false" transID %UNIQID; #REQUIRED localize %LOCS; "i-default">
<!元素选项任意><！ATTLIST选项内部NMTOKEN“”外部%URI；“targetHop（this | final | all）“final”mustUnderstand（true | false）“false”transID%UNIQID#要求本地化%LOC；“i-default”>
<!-- DTD for the APEX report service, as of 2000-12-12
<!-- APEX报告服务的DTD，自2000年12月12日起
Refer to this DTD as:
将此DTD称为：
<!ENTITY % APEXREPORT PUBLIC "-//Blocks//DTD APEX REPORT//EN" "">
%APEXREPORT;
-->
<!ENTITY % APEXREPORT PUBLIC "-//Blocks//DTD APEX REPORT//EN" "">
%APEXREPORT;
-->
<!ENTITY % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" "">
%APEXCORE;
<!ENTITY % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" "">
%APEXCORE;
<!-- Synopsis of the APEX report service
<!-- APEX报告服务简介
service WKE: apex=report
服务WKE:apex=报告
message exchanges:
信息交换：
service initiates consumer replies
================= ================
statusResponse (nothing)
service initiates consumer replies
================= ================
statusResponse (nothing)
access control tokens: none -->
访问控制令牌：无-->
<!ELEMENT statusResponse
(destination+)>
<!ATTLIST statusResponse
transID %UNIQID; #REQUIRED>
<!ELEMENT statusResponse
(destination+)>
<!ATTLIST statusResponse
transID %UNIQID; #REQUIRED>
<!ELEMENT destination (reply)>
<!ATTLIST destination
identity %ENDPOINT; #REQUIRED>
<!ELEMENT destination (reply)>
<!ATTLIST destination
identity %ENDPOINT; #REQUIRED>
code meaning
==== =======
250 transaction successful
code meaning
==== =======
250 transaction successful
421 service not available
421服务不可用
450 requested action not taken
450.未采取请求采取的行动
451 requested action aborted
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
534身份验证机制不足
535 authentication failure
535身份验证失败
537 action not authorized for user
537未授权用户执行的操作
538 authentication mechanism requires encryption
538身份验证机制需要加密
550 requested action not taken
550请求采取的行动尚未采取
553 parameter invalid
553参数无效
554 transaction failed (e.g., policy violation)
554事务失败（例如，违反策略）
555 transaction already in progress
555交易已在进行中
Consult Section 3 and Section 4.5 for a discussion of security issues, e.g., relaying integrity.
有关安全问题的讨论，请参阅第3节和第4.5节，例如继电器完整性。
Although service provisioning is a policy matter, at a minimum, all APEX implementations must provide the following tuning profiles:
尽管服务供应是一个策略问题，但至少所有APEX实现必须提供以下调优配置文件：
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
Further, APEX endpoint implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [13] or S/MIME [14].
此外，APEX端点实现可以选择提供基于MIME的安全服务，提供消息完整性和机密性，例如OpenPGP[13]或S/MIME[14]。
Regardless, since APEX is a profile of the BEEP, consult [1]'s Section 9 for a discussion of BEEP-specific security issues.
无论如何，由于APEX是BEEP的一个概要文件，请参阅[1]的第9节，了解BEEP特定安全问题的讨论。
Finally, the statusRequest option (Section 5.1) may be used to expose private network topology. Accordingly, an administrator may wish to choose to disable this option except at the ingress/egress points for its administrative domain.
最后，statusRequest选项（第5.1节）可用于公开专用网络拓扑。因此，除了在其管理域的入口/出口点之外，管理员可能希望选择禁用该选项。
References
工具书类
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[1] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[3] 《简单邮件传输协议》，RFC 28212001年4月。
[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[4] “UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[7] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[7] Levinson，E.，“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[8] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[8] Levinson，E.，“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[9] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[10] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Access Service", RFC 3341, July 2002.
[10] Rose，M.，Klyne，G.和D.Crocker，“应用程序交换（APEX）访问服务”，RFC 33412002年7月。
[11] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Presence Service", Work in Progress.
[11] Rose，M.，Klyne，G.和D.Crocker，“应用程序交换（APEX）状态服务”，正在进行中。
[12] Newman, C. and G. Klyne, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[12] Newman，C.和G.Klyne，“互联网上的日期和时间：时间戳”，RFC 33392002年7月。
[13] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[13] Elkins，M.，Del Torto，D.，Levien，R.和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[14] Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
The authors gratefully acknowledge the contributions of: Jeffrey Altman, Harald Alvestrand, Eric Dixon, Ronan Klyne, Darren New, Chris Newman, Scott Pead, and Bob Wyman.
作者感谢杰弗里·奥尔特曼、哈拉尔·阿尔韦斯特朗、埃里克·迪克森、罗南·克莱恩、达伦·纽伊、克里斯·纽曼、斯科特·皮德和鲍勃·怀曼的贡献。
The IANA has registered "APEX" as a standards-track BEEP profile, as specified in Section 8.1.
IANA已将“APEX”注册为第8.1节规定的标准轨道蜂鸣音配置文件。
The IANA has registered "apex-mesh" as a TCP port number, as specified in Section 8.2.
IANA已将“apex mesh”注册为TCP端口号，如第8.2节所述。
The IANA has registered "apex-edge" as a TCP port number, as specified in Section 8.3.
IANA已将“apex edge”注册为TCP端口号，如第8.3节所述。
The IANA maintains a list of:
IANA保存了一份清单，其中包括：
o APEX options, c.f., Section 7.1;
o APEX期权，c.f.，第7.1节；
o APEX services, c.f., Section 7.2; and,
o APEX services，c.f.，第7.2节；和
o APEX endpoint applications, c.f., Section 7.3.
o APEX端点应用，c.f.，第7.3节。
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 APEX options and services, the mailing list apexwg@invisible.net may be used to solicit commentary.
对于每一份清单，IESG负责在IANA作出分配之前指派一名指定专家审查规范。作为对非标准track APEX选项和服务开发者的礼遇，邮件列表apexwg@invisible.net可用于征求评论。
The IANA makes the registrations specified in Section 8.4 and Section 8.5.
IANA进行第8.4节和第8.5节规定的注册。
Authors' Addresses
作者地址
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
马歇尔T.罗斯多佛海滩咨询公司POB 255268萨克拉门托，加利福尼亚州95865-5268美国
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
Graham Klyne Clearwift Corporation 1310水边阿灵顿商业园Theale，Reading RG7 4SA UK
Phone: +44 11 8903 8903
EMail: Graham.Klyne@MIMEsweeper.com
Phone: +44 11 8903 8903
EMail: Graham.Klyne@MIMEsweeper.com
David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US
David H.Crocker Brandenburg互联网络美国加利福尼亚州桑尼维尔市云杉大道675号，邮编94086
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。