Network Working Group M. Rose
Request for Comments: 3117 Dover Beach Consulting, Inc.
Category: Informational November 2001
Network Working Group M. Rose
Request for Comments: 3117 Dover Beach Consulting, Inc.
Category: Informational November 2001
On the Design of Application Protocols
应用协议的设计
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
本备忘录描述了块可扩展交换协议（BXXP）的设计原则。BXXP是面向连接的异步交互的通用应用程序协议框架。该框架允许在单个应用程序用户身份的上下文中进行同时和独立的交换，同时支持文本和二进制消息。
Table of Contents
目录
1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3
2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6
3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8
3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14
4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17
5.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 21
5.7 From Framework to Protocol . . . . . . . . . . . . . . . . . . 22
6. BXXP is now BEEP . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3
2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6
3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8
3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14
4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17
5.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 21
5.7 From Framework to Protocol . . . . . . . . . . . . . . . . . . 22
6. BXXP is now BEEP . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
SMTP [1] is close to being the perfect application protocol: it solves a large, important problem in a minimalist way. It's simple enough for an entry-level implementation to fit on one or two screens of code, and flexible enough to form the basis of very powerful product offerings in a robust and competitive market. Modulo a few oddities (e.g., SAML), the design is well conceived and the resulting specification is well-written and largely self-contained. There is very little about good application protocol design that you can't learn by reading the SMTP specification.
SMTP[1]几乎是完美的应用程序协议：它以最简单的方式解决了一个大而重要的问题。对于入门级实现来说，它非常简单，可以安装在一到两个代码屏幕上，并且非常灵活，可以在一个强大且竞争激烈的市场中形成非常强大的产品产品。除了一些奇怪之处（如SAML），设计构思良好，最终的规范编写良好，基本上是自包含的。关于良好的应用程序协议设计，您很少能从阅读SMTP规范中学到什么。
Unfortunately, there's one little problem: SMTP was originally published in 1981 and since that time, a lot of application protocols have been designed for the Internet, but there hasn't been a lot of reuse going on. You might expect this if the application protocols were all radically different, but this isn't the case: most are surprisingly similar in their functional behavior, even though the actual details vary considerably.
不幸的是，有一个小问题：SMTP最初是在1981年发布的，从那时起，许多应用程序协议都是为Internet设计的，但没有进行大量的重用。如果应用程序协议完全不同，您可能会想到这一点，但事实并非如此：大多数协议在功能行为上惊人地相似，尽管实际细节差异很大。
In late 1998, as Carl Malamud and I were sitting down to review the Blocks architecture, we realized that we needed to have a protocol for exchanging Blocks. The conventional wisdom is that when you need an application protocol, there are four ways to proceed:
1998年末，当Carl Malamud和我坐下来回顾块体系结构时，我们意识到我们需要一个交换块的协议。传统观点认为，当您需要应用程序协议时，有四种方法可以继续：
1. find an existing exchange protocol that (more or less) does what you want;
1. 查找（或多或少）满足您要求的现有交换协议；
2. define an exchange model on top of the world-wide web infrastructure that (more or less) does what you want;
2. 在万维网基础设施之上定义一个（或多或少）满足您需求的交换模型；
3. define an exchange model on top of the electronic mail infrastructure that (more or less) does what you want; or,
3. 在电子邮件基础设施之上定义一个（或多或少）满足您需求的交换模型；或
4. define a new protocol from scratch that does exactly what you want.
4. 从头定义一个新的协议，它完全满足您的需要。
An engineer can make reasoned arguments about the merits of each of the these approaches. Here's the process we followed...
工程师可以对每种方法的优点进行合理的论证。以下是我们遵循的流程。。。
The most appealing option is to find an existing protocol and use that. (In other words, we'd rather "buy" than "make".) So, we did a survey of many existing application protocols and found that none of them were a good match for the semantics of the protocol we needed.
最吸引人的选择是找到一个现有的协议并使用它。（换句话说，我们宁愿“购买”而不是“制造”。）因此，我们对许多现有的应用程序协议进行了调查，发现它们都不符合我们需要的协议的语义。
For example, most application protocols are oriented toward client/server behavior, and emphasize the client pulling data from the server; in contrast with Blocks, a client usually pulls data from
例如，大多数应用程序协议面向客户机/服务器行为，并强调客户机从服务器提取数据；与块相反，客户机通常从
the server, but it also may request the server to asynchronously push (new) data to it. Clearly, we could mutate a protocol such as FTP [2] or SMTP into what we wanted, but by the time we did all that, the base protocol and our protocol would have more differences than similarities. In other words, the cost of modifying an off-the-shelf implementation becomes comparable with starting from scratch.
服务器，但它也可以请求服务器异步推送（新）数据到它。显然，我们可以将FTP[2]或SMTP等协议变异为我们想要的协议，但当我们完成所有这些操作时，基本协议和我们的协议之间的差异将大于相似之处。换句话说，修改现成实现的成本与从头开始的成本相当。
Another approach is to use HTTP [3] as the exchange protocol and define the rules for data exchange over that. For example, IPP [4] (the Internet Printing Protocol) uses this approach. The basic idea is that HTTP defines the rules for exchanging data and then you define the data's syntax and semantics. Because you inherit the entire HTTP infrastructure (e.g., HTTP's authentication mechanisms, caching proxies, and so on), there's less for you to have to invent (and code!). Or, conversely, you might view the HTTP infrastructure as too helpful. As an added bonus, if you decide that your protocol runs over port 80, you may be able to sneak your traffic past older firewalls, at the cost of port 80 saturation.
另一种方法是使用HTTP[3]作为交换协议，并定义通过该协议进行数据交换的规则。例如，IPP[4]（互联网打印协议）使用这种方法。基本思想是HTTP定义交换数据的规则，然后定义数据的语法和语义。因为您继承了整个HTTP基础设施（例如HTTP的身份验证机制、缓存代理等），所以您不需要发明（和编写！）。或者，相反，您可能认为HTTP基础设施太有用了。作为一个额外的好处，如果您决定您的协议在端口80上运行，您可能能够偷偷地让您的流量通过旧的防火墙，代价是端口80饱和。
HTTP has many strengths: it's ubiquitous, it's familiar, and there are a lot of tools available for developing HTTP-based systems. Another good thing about HTTP is that it uses MIME [5] for encoding data.
HTTP有很多优点：它无处不在，非常熟悉，并且有很多工具可用于开发基于HTTP的系统。HTTP的另一个优点是它使用MIME[5]对数据进行编码。
Unfortunately for us, even with HTTP 1.1 [6], there still wasn't a good fit. As a consequence of the highly-desirable goal of maintaining compatibility with the original HTTP, HTTP's framing mechanism isn't flexible enough to support server-side asynchronous behavior and its authentication model isn't similar to other Internet applications.
不幸的是，即使使用HTTP1.1[6]，仍然没有很好的匹配。由于保持与原始HTTP的兼容性这一非常理想的目标，HTTP的框架机制不够灵活，无法支持服务器端异步行为，其身份验证模型与其他Internet应用程序不相似。
Mapping IPP onto HTTP 1.1 illustrates the former issue. For example, the IPP server is supposed to signal its client when a job completes. Since the HTTP client must originate all requests and since the decision to close a persistent connection in HTTP is unilateral, the best that the IPP specification can do is specify this functionality in a non-deterministic fashion.
将IPP映射到HTTP 1.1说明了前一个问题。例如，IPP服务器应该在作业完成时向其客户端发送信号。由于HTTP客户端必须发起所有请求，并且关闭HTTP中的持久连接的决定是单方面的，因此IPP规范所能做的最好的事情就是以非确定性的方式指定此功能。
Further, the IPP mapping onto HTTP shows that even subtle shifts in behavior have unintended consequences. For example, requests in IPP are typically much larger than those seen by many HTTP server implementations -- resulting in oddities in many HTTP servers (e.g., requests are sometimes silently truncated). The lesson is that HTTP's framing mechanism is very rigid with respect to its view of the request/response model.
此外，IPP映射到HTTP表明，即使是行为上的细微变化也会产生意想不到的后果。例如，IPP中的请求通常比许多HTTP服务器实现中看到的请求大得多——这导致许多HTTP服务器出现异常（例如，请求有时会被无声地截断）。教训是HTTP的框架机制对于其请求/响应模型的视图来说非常严格。
Lastly, given our belief that the port field of the TCP header isn't a constant 80, we were immune to the seductive allure of wanting to sneak our traffic past unwary site administrators.
最后，由于我们相信TCP报头的端口字段不是一个常数80，因此我们对想要将流量偷偷带过粗心的站点管理员的诱惑免疫。
The third choice, layering the protocol on top of email, was attractive. Unfortunately, the nature of our application includes a lot of interactivity with relatively small response times. So, this left us the final alternative: defining a protocol from scratch.
第三个选择是，在电子邮件之上分层协议，这很有吸引力。不幸的是，我们的应用程序的本质包括大量的交互，而响应时间相对较短。因此，这给我们留下了最后的选择：从头定义协议。
To begin, we figured that our requirements, while a little more stringent than most, could fit inside a framework suitable for a large number of future application protocols. The trick is to avoid the kitchen-sink approach. (Dave Clark has a saying: "One of the roles of architecture is to tell you what you can't do.")
首先，我们认为我们的要求虽然比大多数要求严格一点，但可以适合于大量未来应用程序协议的框架。诀窍是避免厨房水槽的做法。（戴夫·克拉克（Dave Clark）有句谚语：“建筑的作用之一就是告诉你你不能做什么。”）
2. You can Solve Any Problem...
2. 你可以解决任何问题。。。
...if you're willing to make the problem small enough.
…如果你愿意让问题变得足够小。
Our most important step is to limit the problem to application protocols that exhibit certain features:
我们最重要的步骤是将问题限制在具有某些功能的应用程序协议上：
o they are connection-oriented;
o 它们是面向连接的；
o they use requests and responses to exchange messages; and,
o 他们使用请求和响应来交换消息；和
o they allow for asynchronous message exchange.
o 它们允许异步消息交换。
Let's look at each, in turn.
让我们依次看看每一个。
First, we're only going to consider connection-oriented application protocols (e.g., those that work on top of TCP [7]). Another branch in the taxonomy, connectionless, consists of those that don't want the delay or overhead of establishing and maintaining a reliable stream. For example, most DNS [8] traffic is characterized by a single request and response, both of which fit within a single IP datagram. In this case, it makes sense to implement a basic reliability service above the transport layer in the application protocol itself.
首先，我们只考虑面向连接的应用协议（例如，那些在TCP（7）之上工作的协议）。分类法中的另一个分支，无连接，由那些不希望建立和维护可靠流的延迟或开销的分支组成。例如，大多数DNS[8]流量的特点是一个请求和响应，这两个请求和响应都适合于一个IP数据报。在这种情况下，在应用程序协议本身的传输层之上实现基本的可靠性服务是有意义的。
Second, we're only going to consider message-oriented application protocols. A "message" -- in our lexicon -- is simply structured data exchanged between loosely-coupled systems. Another branch in the taxonomy, tightly-coupled systems, uses remote procedure calls as the exchange paradigm. Unlike the connection-oriented/connectionless dichotomy, the issue of loosely- or tightly-coupled systems is similar to a continuous spectrum. Fortunately, the edges are fairly sharp.
第二，我们只考虑面向消息的应用协议。在我们的词典中，“消息”只是松散耦合系统之间交换的结构化数据。分类法中的另一个分支，紧耦合系统，使用远程过程调用作为交换范例。与面向连接/无连接的二分法不同，松耦合或紧耦合系统的问题类似于连续谱。幸运的是，边缘相当锋利。
For example, NFS [9] is a tightly-coupled system using RPCs. When running in a properly-configured LAN, a remote disk accessible via NFS is virtually indistinguishable from a local disk. To achieve this, tightly-coupled systems are highly concerned with issues of latency. Hence, most (but not all) tightly-coupled systems use connection-less RPC mechanisms; further, most tend to be implemented as operating system functions rather than user-level programs. (In some environments, the tightly-coupled systems are implemented as single-purpose servers, on hardware specifically optimized for that one function.)
例如，NFS[9]是一个使用RPC的紧密耦合系统。在正确配置的LAN中运行时，通过NFS访问的远程磁盘实际上与本地磁盘无法区分。为了实现这一点，紧耦合系统高度关注延迟问题。因此，大多数（但不是全部）紧耦合系统使用无连接RPC机制；此外，大多数都倾向于作为操作系统功能而不是用户级程序来实现。（在某些环境中，紧密耦合的系统被实现为单用途服务器，在专门针对该功能优化的硬件上。）
Finally, we're going to consider the needs of application protocols that exchange messages asynchronously. The classic client/server model is that the client sends a request and the server sends a
最后，我们将考虑应用协议异步交换消息的需求。经典的客户机/服务器模型是客户机发送请求，服务器发送请求
response. If you think of requests as "questions" and responses as "answers", then the server answers only those questions that it's asked and it never asks any questions of its own. We'll need to support a more general model, peer-to-peer. In this model, for a given transaction one peer might be the "client" and the other the "server", but for the next transaction, the two peers might switch roles.
回答如果您将请求视为“问题”，将响应视为“答案”，那么服务器只回答它所问的那些问题，而从不询问自己的任何问题。我们需要支持更通用的模型，即点对点。在此模型中，对于给定的事务，一个对等方可能是“客户机”，另一个是“服务器”，但对于下一个事务，两个对等方可能会切换角色。
It turns out that the client/server model is a proper subset of the peer-to-peer model: it's acceptable for a particular application protocol to dictate that the peer that establishes the connection always acts as the client (initiates requests), and that the peer that listens for incoming connections always acts as the server (issuing responses to requests).
事实证明，客户机/服务器模型是对等模型的一个适当子集：特定的应用程序协议规定建立连接的对等方始终充当客户机（发起请求），侦听传入连接的对等方始终充当服务器是可以接受的（对请求作出答复）。
There are quite a few existing application domains that don't fit our requirements, e.g., nameservice (via the DNS), fileservice (via NFS), multicast-enabled applications such as distributed video conferencing, and so on. However, there are a lot of application domains that do fit these requirements, e.g., electronic mail, file transfer, remote shell, and the world-wide web. So, the bet we are placing in going forward is that there will continue to be reasons for defining protocols that fit within our framework.
有相当多的现有应用程序域不符合我们的要求，例如名称服务（通过DNS）、文件服务（通过NFS）、支持多播的应用程序（如分布式视频会议）等等。然而，有许多应用领域确实符合这些要求，例如电子邮件、文件传输、远程shell和万维网。因此，我们下的赌注是继续有理由定义适合我们框架的协议。
The next step is to look at the tasks that an application protocol must perform and how it goes about performing them. Although an exhaustive exposition might identify a dozen (or so) areas, the ones we're interested in are:
下一步是查看应用程序协议必须执行的任务以及如何执行这些任务。尽管详尽的阐述可能会确定十几个（或更多）领域，但我们感兴趣的是：
o framing, which tells how the beginning and ending of each message is delimited;
o 框架，它告诉如何界定每条消息的开头和结尾；
o encoding, which tells how a message is represented when exchanged;
o 编码，它告诉消息在交换时是如何表示的；
o reporting, which tells how errors are described;
o 报告，说明如何描述错误；
o asynchrony, which tells how independent exchanges are handled;
o 异步，它告诉如何处理独立的交换；
o authentication, which tells how the peers at each end of the connection are identified and verified; and,
o 身份验证，它告诉如何识别和验证连接两端的对等方；和
o privacy, which tells how the exchanges are protected against third-party interception or modification.
o 隐私，它说明了如何保护交易所免受第三方拦截或修改。
A notable absence in this list is naming -- we'll explain why later on.
这个列表中一个值得注意的缺失是命名——稍后我们将解释原因。
There are three commonly used approaches to delimiting messages: octet-stuffing, octet-counting, and connection-blasting.
有三种常用的消息定界方法：八位字节填充、八位字节计数和连接爆破。
An example of a protocol that uses octet-stuffing is SMTP. Commands in SMTP are line-oriented (each command ends in a CR-LF pair). When an SMTP peer sends a message, it first transmits the "DATA" command, then it transmits the message, then it transmits a "." (dot) followed by a CR-LF. If the message contains any lines that begin with a dot, the sending SMTP peer sends two dots; similarly, when the other SMTP peer receives a line that begins with a dot, it discards the dot, and, if the line is empty, then it knows it's received the entire message. Octet-stuffing has the property that you don't need the entire message in front of you before you start sending it. Unfortunately, it's slow because both the sender and receiver must scan each line of the message to see if they need to transform it.
使用八位字节填充的协议的一个示例是SMTP。SMTP中的命令是面向行的（每个命令以CR-LF对结尾）。当SMTP对等方发送消息时，它首先传输“数据”命令，然后传输消息，然后传输“.”（点），然后传输CR-LF。如果邮件包含以点开头的任何行，则发送SMTP对等方将发送两个点；类似地，当另一个SMTP对等方收到以点开头的行时，它会丢弃该点，如果该行为空，则它知道它已收到整个邮件。八位字节填充的特性是，在开始发送消息之前，不需要将整个消息放在面前。不幸的是，它很慢，因为发送方和接收方都必须扫描消息的每一行，以查看是否需要转换它。
An example of a protocol that uses octet-counting is HTTP. Commands in HTTP consist of a request line followed by headers and a body. The headers contain an octet count indicating how large the body is. The properties of octet-counting are the inverse of octet-stuffing:
使用八位字节计数的协议的一个例子是HTTP。HTTP中的命令由请求行、标题和正文组成。标题包含一个八位字节计数，指示主体有多大。八位组计数的性质与八位组填充相反：
before you can start sending a message you need to know the length of the whole message, but you don't need to look at the content of the message once you start sending or receiving.
在开始发送消息之前，您需要知道整个消息的长度，但不需要在开始发送或接收消息后查看消息的内容。
An example of a protocol that uses connection-blasting is FTP. Commands in FTP are line-oriented, and when it's time to exchange a message, a new TCP connection is established to transmit the message. Both octet-counting and connection-blasting have the property that the messages can be arbitrary binary data; however, the drawback of the connection-blasting approach is that the peers need to communicate IP addresses and TCP port numbers, which may be "transparently" altered by NATS [10] and network bugs. In addition, if the messages being exchanged are small (say less than 32k), then the overhead of establishing a connection for each message contributes significant latency during data exchange.
使用连接爆破的协议的一个例子是FTP。FTP中的命令是面向行的，当需要交换消息时，会建立一个新的TCP连接来传输消息。八位组计数和连接爆破都具有消息可以是任意二进制数据的特性；然而，连接爆破方法的缺点是对等方需要通信IP地址和TCP端口号，这可能会被NAT[10]和网络错误“透明地”改变。此外，如果正在交换的消息很小（比如小于32k），那么为每个消息建立连接的开销会在数据交换期间造成显著的延迟。
There are many schemes used for encoding data (and many more encoding schemes have been proposed than are actually in use). Fortunately, only a few are burning brightly on the radar.
有许多用于编码数据的方案（已经提出的编码方案比实际使用的编码方案多得多）。幸运的是，只有少数几个在雷达上明亮地燃烧着。
The messages exchanged using SMTP are encoded using the 822-style [11]. The 822-style divides a message into textual headers and an unstructured body. Each header consists of a name and a value and is terminated with a CR-LF pair. An additional CR-LF separates the headers from the body.
使用SMTP交换的邮件使用822样式进行编码[11]。822样式将消息分为文本标题和非结构化正文。每个标头由一个名称和一个值组成，并以CR-LF对终止。另一个CR-LF将收割台与车身分开。
It is this structure that HTTP uses to indicate the length of the body for framing purposes. More formally, HTTP uses MIME, an application of the 822-style to encode both the data itself (the body) and information about the data (the headers). That is, although HTTP is commonly viewed as a retrieval mechanism for HTML [12], it is really a retrieval mechanism for objects encoded using MIME, most of which are either HTML pages or referenced objects such as GIFs.
HTTP正是使用这种结构来指示主体的长度，以便进行成帧。更正式地说，HTTP使用MIME，一种822样式的应用程序来编码数据本身（主体）和关于数据的信息（头）。也就是说，虽然HTTP通常被视为HTML的检索机制[12]，但它实际上是使用MIME编码的对象的检索机制，其中大多数是HTML页面或GIF等引用对象。
An application protocol needs a mechanism for conveying error information between peers. The first formal method for doing this was defined by SMTP's "theory of reply codes". The basic idea is that an error is identified by a three-digit string, with each position having a different significance:
应用程序协议需要一种在对等方之间传输错误信息的机制。SMTP的“回复代码理论”定义了第一种正式的方法。其基本思想是通过一个三位字符串来识别错误，每个位置具有不同的重要性：
the first digit: indicating success or failure, either permanent or transient;
第一位：表示成功或失败，永久或暂时；
the second digit: indicating the part of the system reporting the situation (e.g., the syntax analyzer); and,
第二位：表示报告情况的系统部分（例如语法分析器）；和
the third digit: identifying the actual situation.
第三位：识别实际情况。
Operational experience with SMTP suggests that the range of error conditions is larger than can be comfortably encoded using a three-digit string (i.e., you can report on only 10 different things going wrong for any given part of the system). So, [13] provides a convenient mechanism for extending the number of values that can occur in the second and third positions.
SMTP的操作经验表明，错误条件的范围大于使用三位数字符串轻松编码的范围（即，对于系统的任何给定部分，您只能报告10种不同的出错情况）。因此，[13]提供了一种方便的机制来扩展第二和第三位置上可能出现的值的数量。
Virtually all of the application protocols we've discussed thus far use the three-digit reply codes, although there is less coordination between the designers of different application protocols than most would care to admit. (A variation on the theory of reply codes is employed by IMAP [14] which provides the same information using a different syntax.)
到目前为止，我们讨论的几乎所有应用程序协议都使用三位数的应答码，尽管不同应用程序协议的设计者之间的协调程度比大多数人愿意承认的要低。（IMAP[14]采用了回复码理论的一种变体，它使用不同的语法提供相同的信息。）
In addition to conveying a reply code, most application protocols also send a textual diagnostic suitable for human, not machine, consumption. (More accurately, the textual diagnostic is suitable for people who can read a widely used variant of the English language.) Since reply codes reflect both positive and negative outcomes, there have been some innovative uses made for the text accompanying positive responses, e.g., prayer wheels [39]. Regardless, some of the more modern application protocols include a language localization parameter for the diagnostic text.
除了传送应答代码外，大多数应用程序协议还发送适合人类而非机器消费的文本诊断。（更准确地说，文本诊断法适用于能够阅读广泛使用的英语变体的人。）由于回复代码反映了积极和消极的结果，因此对伴随积极响应的文本进行了一些创新性的使用，例如祈祷轮[39]。无论如何，一些更现代的应用程序协议包括诊断文本的语言本地化参数。
Finally, since the introduction of reply codes in 1981, two unresolved criticisms have been raised:
最后，自1981年引入回复代码以来，提出了两项尚未解决的批评：
o a reply code is used both to signal the outcome of an operation and a change in the application protocol's state; and,
o 应答码用于表示操作的结果和应用协议状态的变化；和
o a reply code doesn't specify whether the associated textual diagnostic is destined for the end-user, administrator, or programmer.
o 回复代码不指定关联的文本诊断是否发送给最终用户、管理员或程序员。
Few application protocols today allow independent exchanges over the same connection. In fact, the more widely implemented approach is to allow pipelining, e.g., command pipelining [15] in SMTP or persistent connections in HTTP 1.1. Pipelining allows a client to make multiple requests of a server, but requires the requests to be processed serially. (Note that a protocol needs to explicitly provide support for pipelining, since, without explicit guidance, many implementors
现在很少有应用程序协议允许在同一连接上进行独立交换。事实上，更广泛实现的方法是允许管道，例如SMTP中的命令管道[15]或HTTP 1.1中的持久连接。管道允许客户端对服务器发出多个请求，但要求串行处理这些请求。（请注意，协议需要明确提供对管道的支持，因为在没有明确指导的情况下，许多实现者
produce systems that don't handle pipelining properly; typically, an error in a request causes subsequent requests in the pipeline to be discarded).
生产不能正确处理管道的系统；通常，请求中的错误会导致管道中的后续请求被丢弃）。
Pipelining is a powerful method for reducing network latency. For example, without persistent connections, HTTP's framing mechanism is really closer to connection-blasting than octet-counting, and it enjoys the same latency and efficiency problems.
流水线是减少网络延迟的一种有效方法。例如，在没有持久连接的情况下，HTTP的帧机制实际上比八位字节计数更接近于连接爆破，并且它也有相同的延迟和效率问题。
In addition to reducing network latency (the pipelining effect), asynchrony also reduces server latency by allowing multiple requests to be processed by multi-threaded implementations. Note that if you allow any form of asynchronous exchange, then support for parallelism is also required, because exchanges aren't necessarily occurring under the synchronous direction of a single peer.
除了减少网络延迟（管道效应），异步还通过允许多线程实现处理多个请求来减少服务器延迟。请注意，如果允许任何形式的异步交换，那么还需要支持并行性，因为交换不一定是在单个对等方的同步方向下进行的。
Unfortunately, when you allow parallelism, you also need a flow control mechanism to avoid starvation and deadlock. Otherwise, a single set of exchanges can monopolize the bandwidth provided by the transport layer. Further, if a peer is resource-starved, then it may not have enough buffers to receive a message and deadlock results.
不幸的是，当您允许并行时，您还需要一个流控制机制来避免饥饿和死锁。否则，一组交换机就可以垄断传输层提供的带宽。此外，如果对等方资源不足，那么它可能没有足够的缓冲区来接收消息和死锁结果。
Flow control is typically implemented at the transport layer. For example, TCP uses sequence numbers and a sliding window: each receiver manages a sliding window that indicates the number of data octets that may be transmitted before receiving further permission. However, it's now time for the second shoe to drop: segmentation. If you do flow control then you also need a segmentation mechanism to fragment messages into smaller pieces before sending and then re-assemble them as they're received.
流量控制通常在传输层实现。例如，TCP使用序列号和滑动窗口：每个接收器管理一个滑动窗口，该窗口指示在接收进一步许可之前可能传输的数据八位字节数。然而，现在是时候放下第二只鞋了：分割。如果您进行流控制，那么您还需要一种分段机制，在发送消息之前将消息分段为较小的片段，然后在接收消息时重新组装它们。
Both flow control and segmentation have an impact on how the protocol does framing. Before we defined framing as "how to tell the beginning and end of each message" -- in addition, we need to be able to identify independent messages, send messages only when flow control allows us to, and segment them if they're larger than the available window (or too large for comfort).
流控制和分段都会影响协议的成帧方式。在我们将框架定义为“如何告诉每条消息的开头和结尾”之前——此外，我们需要能够识别独立的消息，只在流量控制允许的情况下发送消息，如果消息大于可用窗口（或太大而不舒适），则对其进行分段。
Segmentation impacts framing in another way -- it relaxes the octet-counting requirement that you need to know the length of the whole message before sending it. With segmentation, you can start sending segments before the whole message is available. In HTTP 1.1 you can "chunk" (segment) data to get this advantage.
分段以另一种方式影响帧——它放松了八位字节计数要求，即在发送消息之前需要知道整个消息的长度。通过分段，您可以在整个消息可用之前开始发送分段。在HTTP1.1中，您可以“块”（段）数据来获得这一优势。
Perhaps for historical (or hysterical) reasons, most application protocols don't do authentication. That is, they don't authenticate the identity of the peers on the connection or the authenticity of the messages being exchanged. Or, if authentication is done, it is domain-specific for each protocol. For example, FTP and HTTP use entirely different models and mechanisms for authenticating the initiator of a connection. (Independent of mainstream HTTP, there is a little-used variant [16] that authenticates the messages it exchanges.)
也许出于历史（或歇斯底里的）原因，大多数应用程序协议都不进行身份验证。也就是说，它们不验证连接上对等方的身份或正在交换的消息的真实性。或者，如果完成了身份验证，则每个协议都是特定于域的。例如，FTP和HTTP使用完全不同的模型和机制来验证连接的发起方。（独立于主流HTTP，有一个很少使用的变体[16]对它交换的消息进行身份验证。）
A large part of the problem is that different security mechanisms optimize for strength, scalability, or ease of deployment. So, a few years ago, SASL [17] (the Simple Authentication and Security Layer) was developed to provide a framework for authenticating protocol peers. SASL let's you describe how an authentication mechanism works, e.g., an OTP [18] (One-Time Password) exchange. It's then up to each protocol designer to specify how SASL exchanges are generically conveyed by the protocol. For example, [19] explains how SASL works with SMTP.
问题的很大一部分在于，不同的安全机制针对强度、可伸缩性或部署的易用性进行了优化。因此，几年前，SASL[17]（简单身份验证和安全层）被开发出来，以提供一个对协议对等方进行身份验证的框架。SASL让我们来描述身份验证机制是如何工作的，例如OTP[18]（一次性密码）交换。然后由每个协议设计人员指定协议一般如何传递SASL交换。例如，[19]解释了SASL如何与SMTP一起工作。
A notable exception to the SASL bandwagon is HTTP, which defines its own authentication mechanisms [20]. There is little reason why SASL couldn't be introduced to HTTP, although to avoid certain race-conditions, the persistent connection mechanism of HTTP 1.1 must be used.
SASL潮流的一个显著例外是HTTP，它定义了自己的身份验证机制[20]。没有什么理由不能将SASL引入HTTP，尽管为了避免某些竞争条件，必须使用HTTP 1.1的持久连接机制。
SASL has an interesting feature in that in addition to explicit protocol exchanges to authenticate identity, it can also use implicit information provided from the layer below. For example, if the connection is running over IPsec [21], then the credentials of each peer are known and verified when the TCP connection is established.
SASL有一个有趣的特性，除了使用显式协议交换来验证身份之外，它还可以使用下面层提供的隐式信息。例如，如果连接通过IPsec[21]运行，则在建立TCP连接时，每个对等方的凭据都是已知的并经过验证的。
Finally, as its name implies, SASL can do more than authentication -- depending on which SASL mechanism is in use, message integrity or privacy services may also be provided.
最后，顾名思义，SASL可以做的不仅仅是身份验证——根据使用的SASL机制，还可以提供消息完整性或隐私服务。
HTTP is the first widely used protocol to make use of a transport security protocol to encrypt the data sent on the connection. The current version of this mechanism, TLS [22], is available to all application protocols, e.g., SMTP and ACAP [23] (the Application Configuration Access Protocol).
HTTP是第一个广泛使用的协议，它利用传输安全协议对连接上发送的数据进行加密。此机制的当前版本TLS[22]可用于所有应用程序协议，例如SMTP和ACAP[23]（应用程序配置访问协议）。
The key difference between the original mechanism and TLS, is one of provisioning not technology. In the original approach to provisioning, a world-wide web server listens on two ports (one for plaintext traffic and the other for secured traffic); in contrast, by today's conventions, a server implementing an application protocol that is specified as TLS-enabled (e.g., [24] and [25]) listens on a single port for plaintext traffic, and, once a connection is established, the use of TLS on that connection is negotiable.
原始机制和TLS之间的关键区别在于资源调配，而不是技术。在最初的资源调配方法中，万维网服务器侦听两个端口（一个用于明文通信，另一个用于安全通信）；相反，根据当今的惯例，实现指定为启用TLS（例如，[24]和[25]）的应用程序协议的服务器在单个端口上侦听明文通信量，并且，一旦建立连接，在该连接上使用TLS是可以协商的。
Finally, note that both SASL and TLS are about "transport security" not "object security". What this means is that they focus on providing security properties for the actual communication, they don't provide any security properties for the data exchanged independent of the communication.
最后，请注意，SASL和TLS都是关于“传输安全性”而不是“对象安全性”。这意味着它们专注于为实际通信提供安全属性，而不为独立于通信的数据交换提供任何安全属性。
Let's briefly compare the properties of the three main connection-oriented application protocols in use today:
让我们简要比较一下目前使用的三种主要面向连接的应用程序协议的特性：
Mechanism ESMTP FTP HTTP1.1
-------------- ----------- --------- -------------
Framing stuffing blasting counting
Mechanism ESMTP FTP HTTP1.1
-------------- ----------- --------- -------------
Framing stuffing blasting counting
Encoding 822-style binary MIME
编码822风格的二进制MIME
Reporting 3-digit 3-digit 3-digit
报告三位数三位数三位数三位数
Asynchrony pipelining none pipelining and chunking
异步流水无流水和分块
Authentication SASL user/pass user/pass
验证SASL用户/通过用户/通过
Privacy SASL or TLS none TLS (nee SSL)
隐私SASL或TLS无TLS（nee SSL）
Note that the username/password mechanisms used by FTP and HTTP are entirely different with one exception: both can be termed a "username/password" mechanism.
请注意，FTP和HTTP使用的用户名/密码机制完全不同，只有一个例外：两者都可以称为“用户名/密码”机制。
These three choices are broadly representative: as more protocols are considered, the patterns are reinforced. For example, POP [26] uses octet-stuffing, but IMAP uses octet-counting, and so on.
这三种选择具有广泛的代表性：随着更多协议的考虑，模式得到加强。例如，POP[26]使用八位字节填充，而IMAP使用八位字节计数，等等。
When we design an application protocol, there are a few properties that we should keep an eye on.
当我们设计应用程序协议时，有几个属性需要注意。
A well-designed protocol is scalable.
设计良好的协议是可伸缩的。
Because few application protocols support asynchrony, a common trick is for a program to open multiple simultaneous connections to a single destination. The theory is that this reduces latency and increases throughput. The reality is that both the transport layer and the server view each connection as an independent instance of the application protocol, and this causes problems.
因为很少有应用程序协议支持异步，所以一个常见的技巧是一个程序同时打开多个到单个目标的连接。理论上，这可以减少延迟并提高吞吐量。事实上，传输层和服务器都将每个连接视为应用程序协议的独立实例，这会导致问题。
In terms of the transport layer, TCP uses adaptive algorithms to efficiently transmit data as networks conditions change. But what TCP learns is limited to each connection. So, if you have multiple TCP connections, you have to go through the same learning process multiple times -- even if you're going to the same host. Not only does this introduce unnecessary traffic spikes into the network, because TCP uses a slow-start algorithm when establishing a connection, the program still sees additional latency. To deal with the fact that a lack of asynchrony in application protocols causes implementors to make sloppy use of the transport layer, network protocols are now provisioned with increasing sophistication, e.g., RED [27]. Further, suggestions are also being considered for modification of TCP implementations to reduce concurrent learning, e.g., [28].
在传输层，TCP使用自适应算法在网络条件变化时高效地传输数据。但是TCP学习的内容仅限于每个连接。因此，如果你有多个TCP连接，你必须多次经历相同的学习过程——即使你要去同一个主机。这不仅会在网络中引入不必要的流量峰值，因为TCP在建立连接时使用慢启动算法，程序还会看到额外的延迟。为了解决应用程序协议中缺乏异步性导致实现者草率地使用传输层这一事实，网络协议现在变得越来越复杂，例如RED[27]。此外，还考虑了修改TCP实现以减少并发学习的建议，例如[28]。
In terms of the server, each incoming connection must be dispatched and (probably) authenticated against the same resources. Consequently, server overhead increases based on the number of connections established, rather than the number of remote users. The same issues of fairness arise: it's much harder for servers to allocate resources on a per-user basis, when a user can cause an arbitrary number of connections to pound on the server.
就服务器而言，必须调度每个传入连接，并且（可能）针对相同的资源进行身份验证。因此，服务器开销的增加取决于建立的连接数量，而不是远程用户的数量。同样的公平性问题也出现了：当用户可以在服务器上造成任意数量的连接时，服务器很难按每个用户分配资源。
Another important aspect of scalability to consider is the relative numbers of clients and servers. (This is true even in the peer-to-peer model, where a peer can act both in the client and server role.) Typically, there are many more client peers than server peers. In this case, functional requirements should be shifted from the servers onto the clients. The reason is that a server is likely to be interacting with multiple clients and this functional shift makes it easier to scale.
可扩展性考虑的另一个重要方面是客户端和服务器的相对数量。（即使在对等模型中也是如此，在对等模型中，对等方可以同时扮演客户端和服务器角色。）通常，客户端对等方比服务器对等方多得多。在这种情况下，功能需求应该从服务器转移到客户端。原因是服务器可能与多个客户机交互，这种功能转换使其更易于扩展。
A well-designed protocol is efficient.
设计良好的协议是有效的。
For example, although a compelling argument can be made than octet-stuffing leads to more elegant implementations than octet-counting, experience shows that octet-counting consumes far fewer cycles.
例如，尽管可以提出一个令人信服的论点，即八位字节填充比八位字节计数带来更优雅的实现，但经验表明八位字节计数消耗的周期要少得多。
Regrettably, we sometimes have to compromise efficiency in order to satisfy other properties. For example, 822 (and MIME) use textual headers. We could certainly define a more efficient representation for the headers if we were willing to limit the header names and values that could be used. In this case, extensibility is viewed as more important than efficiency. Of course, if we were designing a network protocol instead of an application protocol, then we'd make the trade-offs using a razor with a different edge.
遗憾的是，为了满足其他性质，我们有时不得不牺牲效率。例如，822（和MIME）使用文本标题。如果我们愿意限制可以使用的头名称和值，我们当然可以为头定义更有效的表示。在这种情况下，可扩展性被认为比效率更重要。当然，如果我们设计的是一个网络协议而不是一个应用程序协议，那么我们将使用一个具有不同边缘的剃须刀进行权衡。
A well-designed protocol is simple.
设计良好的协议很简单。
Here's a good rule of thumb: a poorly-designed application protocol is one in which it is equally as "challenging" to do something basic as it is to do something complex. Easy things should be easy to do and hard things should be harder to do. The reason is simple: the pain should be proportional to the gain.
这里有一个很好的经验法则：一个设计糟糕的应用程序协议是这样一个协议，在这个协议中，做一些基本的事情和做一些复杂的事情一样具有“挑战性”。简单的事情应该容易做，困难的事情应该更难做。原因很简单：痛苦应该与收获成正比。
Another rule of thumb is that if an application protocol has two ways of doing the exact same thing, then there's a problem somewhere in the architecture underlying the design of the application protocol.
另一条经验法则是，如果一个应用程序协议有两种方法来做完全相同的事情，那么在应用程序协议设计的基础架构中的某个地方就存在问题。
Hopefully, simple doesn't mean simple-minded: something that's well-designed accommodates everything in the problem domain, even the troublesome things at the edges. What makes the design simple is that it does this in a consistent fashion. Typically, this leads to an elegant design.
希望简单并不意味着头脑简单：精心设计的东西可以容纳问题领域的一切，甚至是边缘的麻烦事。使设计简单的是，它以一致的方式实现了这一点。通常，这会导致优雅的设计。
A well-designed protocol is extensible.
设计良好的协议是可扩展的。
As clever as application protocol designers are, there are likely to be unforeseen problems that the application protocol will be asked to solve. So, it's important to provide the hooks that can be used to add functionality or customize behavior. This means that the protocol is evolutionary, and there must be a way for implementations reflecting different steps in the evolutionary path to negotiate which extensions will be used.
尽管应用程序协议设计者很聪明，但可能会有一些不可预见的问题需要应用程序协议来解决。因此，提供可用于添加功能或自定义行为的挂钩非常重要。这意味着协议是进化的，并且必须有一种方式来反映进化路径中的不同步骤，以协商将使用哪些扩展。
But, it's important to avoid falling into the extensibility trap: the hooks provided should not be targeted at half-baked future requirements. Above all, the hooks should be simple.
但是，避免落入可扩展性陷阱很重要：提供的钩子不应该针对不成熟的未来需求。最重要的是，挂钩应该简单。
Of course good design goes a long way towards minimizing the need for extensibility. For example, although SMTP initially didn't have an extension framework, it was only after ten years of experience that its excellent design was altered. In contrast, a poorly-designed protocol such as Telnet [29] can't function without being built around the notion of extensions.
当然，好的设计对于最小化对可扩展性的需求有很大的帮助。例如，虽然SMTP最初没有扩展框架，但经过十年的经验之后，它的优秀设计才得以改变。相比之下，设计拙劣的协议（如Telnet[29]）如果不围绕扩展的概念构建，就无法正常工作。
A well-designed protocol is robust.
设计良好的协议是健壮的。
Robustness and efficiency are often at odds. For example, although defaults are useful to reduce packet sizes and processing time, they tend to encourage implementation errors.
稳健性和效率往往不一致。例如，尽管默认值有助于减少数据包大小和处理时间，但它们往往会导致实现错误。
Counter-intuitively, Postel's robustness principle ("be conservative in what you send, liberal in what you accept") often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow the robustness principle, then errors in the new implementation will likely go undetected. The new implementation then sees some, but not widespread deployment. This process repeats for several new implementations. Eventually, the not-quite-correct implementations run into other implementations that are less liberal than the initial set of implementations. The reader should be able to figure out what happens next.
与直觉相反，Postel的健壮性原则（“发送内容要保守，接受内容要自由”）通常会导致部署问题。为什么？当一个新的实现最初部署时，很可能只会遇到现有实现的一个子集。如果这些实现遵循健壮性原则，那么新实现中的错误可能不会被检测到。然后，新的实现会看到一些部署，但不是广泛部署。这个过程在几个新的实现中重复。最终，不太正确的实现会运行到比初始实现集更不自由的其他实现中。读者应该能够弄清楚接下来会发生什么。
Accordingly, explicit consistency checks in a protocol are very useful, even if they impose implementation overhead.
因此，协议中的显式一致性检查非常有用，即使它们会增加实现开销。
Finally, we get to the money shot: here's what we did.
最后，我们来谈谈钱的问题：下面是我们所做的。
We defined an application protocol framework called BXXP (the Blocks eXtensible eXchange Protocol). The reason it's a "framework" instead of an application protocol is that we provide all the mechanisms discussed earlier without actually specifying the kind of messages that get exchanged. So, when someone else needs an application protocol that requires connection-oriented, asynchronous interactions, they can start with BXXP. It's then their responsibility to define the last 10% of the application protocol, the part that does, as we say, "the useful work".
我们定义了一个名为BXXP（块可扩展交换协议）的应用程序协议框架。它之所以是一个“框架”而不是一个应用程序协议，是因为我们提供了前面讨论的所有机制，而没有实际指定要交换的消息类型。因此，当其他人需要一个需要面向连接的异步交互的应用程序协议时，他们可以从BXXP开始。然后，他们负责定义应用程序协议的最后10%，正如我们所说的，“有用的工作”。
So, what does BXXP look like?
那么，BXXP看起来像什么？
Mechanism BXXP
-------------- ----------------------------------------
Framing counting, with a trailer
Mechanism BXXP
-------------- ----------------------------------------
Framing counting, with a trailer
Encoding MIME, defaulting to text/xml
编码MIME，默认为text/xml
Reporting 3-digit and localized textual diagnostic
报告3位数字和本地化文本诊断
Asynchrony channels
异步通道
Authentication SASL
认证SASL
Privacy SASL or TLS
隐私SASL或TLS
Framing in BXXP looks a lot like SMTP or HTTP: there's a command line that identifies the beginning of the frame, then there's a MIME object (headers and body). Unlike SMTP, BXXP uses octet-counting, but unlike HTTP, the command line is where you find the size of the payload. Finally, there's a trailer after the MIME object to aid in detecting framing errors.
BXXP中的帧看起来很像SMTP或HTTP：有一个命令行标识帧的开头，然后是一个MIME对象（头和正文）。与SMTP不同，BXXP使用八位字节计数，但与HTTP不同，命令行是查找有效负载大小的地方。最后，MIME对象后面还有一个预告片，用于帮助检测帧错误。
Actually, the command line for BXXP has a lot of information, it tells you:
实际上，BXXP的命令行有很多信息，它告诉您：
o what kind of message is in this frame;
o 在这个框架中有什么样的信息；
o whether there's more to the message than just what's in this frame (a continuation flag);
o 消息是否不仅仅是这个帧中的内容（延续标志）；
o how to distinguish the message contained in this frame from other messages (a message number);
o 如何区分此帧中包含的消息与其他消息（消息编号）；
o where the payload occurs in the sliding window (a sequence number) along with how many octets are in the payload of this frame; and,
o 其中，有效载荷出现在滑动窗口中（序列号），以及该帧的有效载荷中有多少个八位组；和
o which part of the application should get the message (a channel number).
o 应用程序的哪个部分应该获得消息（通道号）。
(The command line is textual and ends in a CR-LF pair, and the arguments are separated by a space.)
（命令行是文本的，以CR-LF对结尾，参数之间用空格分隔。）
Since you need to know all this stuff to process a frame, we put it all in one easy to parse location. You could probably devise a more efficient encoding, but the command line is a very small part of the frame, so you wouldn't get much bounce from optimizing it. Further, because framing is at the heart of BXXP, the frame format has several consistency checks that catch the majority of programming errors. (The combination of a sequence number, an octet count, and a trailer allows for very robust error detection.)
因为处理一个框架需要了解所有这些内容，所以我们将它们放在一个易于解析的位置。您可能会设计出一种更有效的编码，但命令行只占帧的一小部分，因此您不会从优化它中获得太多反弹。此外，由于帧是BXXP的核心，因此帧格式具有多个一致性检查，用于捕获大多数编程错误。（序列号、八位字节计数和尾部的组合允许非常稳健的错误检测。）
Another trick is in the headers: because the command line contains all the framing information, the headers may contain minimal MIME information (such as Content-Type). Usually, however, the headers are empty. That's because the BXXP default payload is XML [30]. (Actually, a "Content-Type: text/xml" with binary transfer encoding).
另一个技巧是在标题中：因为命令行包含所有的框架信息，所以标题可能包含最少的MIME信息（例如内容类型）。然而，通常情况下，标题是空的。这是因为BXXP默认负载是XML[30]。（实际上，是一个带有二进制传输编码的“内容类型：text/xml”）。
We chose XML as the default because it provides a simple mechanism for nested, textual representations. (Alas, the 822-style encoding doesn't easily support nesting.) By design, XML's nature isn't optimized for compact representations. That's okay because we're focusing on loosely-coupled systems and besides there are efficient XML parsers available. Further, there's a fair amount of anecdotal experience -- and we'll stress the word "anecdotal" -- that if you have any kind of compression (either at the link-layer or during encryption), then XML encodings squeeze down nicely.
我们选择XML作为默认值，因为它为嵌套的文本表示提供了一种简单的机制。（唉，822样式的编码不容易支持嵌套。）从设计上看，XML的本质并没有针对紧凑表示进行优化。这没关系，因为我们关注的是松散耦合的系统，而且还有高效的XML解析器可用。此外，有相当多的轶事经验——我们将强调“轶事”一词——如果您有任何类型的压缩（无论是在链接层还是在加密过程中），那么XML编码会很好地压缩。
Even so, use of XML is probably the most controversial part of BXXP. After all, there are more efficient representations around. We agree, but the real issue isn't efficiency, it's ease of use: there are a lot of people who grok the XML thing and there are a lot of XML tools out there. The pain of recreating this social infrastructure far outweighs any benefits of devising a new representation. So, if the "make" option is too expensive, is there something else we can "buy" besides XML? Well, there's ASN.1/BER (just kidding).
即便如此，XML的使用可能是BXXP中最有争议的部分。毕竟，周围有更有效的表示。我们同意，但真正的问题不是效率，而是易用性：有很多人喜欢XML，而且有很多XML工具。重建这一社会基础设施的痛苦远远超过设计新代表的好处。那么，如果“make”选项太贵，那么除了XML之外，我们还可以“购买”其他东西吗？嗯，有ASN.1/BER（只是开玩笑）。
In the early days of the SNMP [31], which does use ASN.1, the same issues arose. In the end, the working group agreed that the use of ASN.1 for SNMP was axiomatic, but not because anyone thought that ASN.1 was the most efficient, or the easiest to explain, or even well liked. ASN.1 was given axiomatic status because the working group decided it was not going to spend the next three years explaining an alternative encoding scheme to the developer community.
在使用ASN.1的SNMP[31]的早期，也出现了同样的问题。最后，工作组一致认为，将ASN.1用于SNMP是不言自明的，但这并不是因为有人认为ASN.1是最有效的、最容易解释的，甚至是最受欢迎的。ASN.1被赋予了不言自明的地位，因为工作组决定在未来三年内不会向开发人员社区解释替代编码方案。
So -- and we apologize for appealing to dogma -- use of XML as the favored encoding scheme in BXXP is axiomatic.
因此——我们为诉诸教条而道歉——在BXXP中使用XML作为受欢迎的编码方案是不言自明的。
We use 3-digit error codes, with a localized textual diagnostic. (Each peer specifies a preferred ordering of languages.)
我们使用3位错误代码，带有本地化的文本诊断。（每个对等方指定语言的首选顺序。）
In addition, the reply to a message is flagged as either positive or negative. This makes it easy to signal success or failure and allow the receiving peer some freedom in the amount of parsing it wants to do on failure.
此外，对消息的答复被标记为肯定或否定。这使得发送成功或失败的信号变得容易，并允许接收对等方在失败时可以自由地进行解析。
Despite the lessons of SMTP and HTTP, there isn't a lot of field experience to rely on when designing the asynchrony features of BXXP. (Actually, there were several efforts in 1998 related to application layer framing, e.g., [32], but none appear to have achieved orbit.)
尽管有SMTP和HTTP的经验教训，但在设计BXXP的异步特性时，没有太多的现场经验可依赖。（事实上，1998年有几项与应用层框架相关的工作，例如[32]，但似乎都没有达到轨道。）
So, here's what we did: frames are exchanged in the context of a "channel". Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged over a channel.
因此，我们所做的是：在“通道”的上下文中交换帧。每个通道都有一个关联的“概要文件”，它定义了通过通道交换的消息的语法和语义。
Channels provide both an extensibility mechanism for BXXP and the basis for parallelism. Remember the last parameter in the command line of a BXXP frame? The "part of the application" that gets the message is identified by a channel number.
通道既为BXXP提供了扩展机制，也为并行性提供了基础。还记得BXXP帧命令行中的最后一个参数吗？获取消息的“应用程序部分”由通道号标识。
A profile is defined according to a "Profile Registration" template. The template defines how the profile is identified (using a URI [33]), what kind of messages get exchanged, along with the syntax and semantics of those messages. When you create a channel, you identify a profile and maybe piggyback your first message. If the channel is successfully created, you get back a positive response; otherwise, you get back a negative response explaining why.
配置文件是根据“配置文件注册”模板定义的。模板定义了如何识别概要文件（使用URI[33]）、交换什么类型的消息以及这些消息的语法和语义。当您创建一个频道时，您可以识别一个配置文件，并可能携带您的第一条消息。如果频道成功创建，您将得到积极响应；否则，你会得到解释原因的否定回答。
Perhaps the easiest way to see how channels provide an extensibility mechanism is to consider what happens when a session is established. Each BXXP peer immediately sends a greeting on channel zero
也许最简单的方法是了解通道如何提供可扩展性机制，以考虑会话建立时会发生什么。每个BXXP对等机立即在通道0上发送问候语
identifying the profiles that each support. (Channel 0 is used for channel management -- it's automatically created when a session is opened.) If you want transport security, the very first thing you do is to create a channel that negotiates transport security, and, once the channel is created, you tell it to do its thing. Next, if you want to authenticate, you create a channel that performs user authentication, and, once the channel is created, you tell it to get busy. At this point, you create one or more channels for data exchange. This process is called "tuning"; once you've tuned the session, you start using the data exchange channels to do "the useful work".
确定每个支持的配置文件。（通道0用于通道管理——它是在会话打开时自动创建的。）如果需要传输安全性，首先要创建一个协商传输安全性的通道，一旦创建了通道，就告诉它做它自己的事情。接下来，如果要进行身份验证，请创建一个执行用户身份验证的通道，一旦创建了该通道，就告诉它开始忙碌。此时，您将创建一个或多个用于数据交换的通道。这个过程叫做“调优”；一旦您调整了会话，您就可以开始使用数据交换通道来完成“有用的工作”。
The first channel that's successfully started has a trick associated with it: when you ask to start the channel, you're allowed to specify a "service name" that goes with it. This allows a server with multiple configurations to select one based on the client's suggestion. (A useful analogy is HTTP 1.1's "Host:" header.) If the server accepts the "service name", then this configuration is used for the rest of the session.
成功启动的第一个频道有一个技巧：当您请求启动频道时，允许您指定一个与之配套的“服务名称”。这允许具有多个配置的服务器根据客户端的建议选择一个配置。（一个有用的类比是HTTP 1.1的“主机：”头。）如果服务器接受“服务名称”，则此配置将用于会话的其余部分。
To allow parallelism, BXXP allows you to use multiple channels simultaneously. Each channel processes messages serially, but there are no constraints on the processing order for different channels. So, in a multi-threaded implementation, each channel maps to its own thread.
为了允许并行性，BXXP允许您同时使用多个通道。每个通道串行处理消息，但对不同通道的处理顺序没有限制。因此，在多线程实现中，每个通道都映射到自己的线程。
This is the most general case, of course. For one reason or another, an implementor may not be able to support this. So, BXXP allows for both positive and negative replies when a message is sent. So, if you want the classic client/server model, the client program should simply reject any new message sent by the server. This effectively throttles any asynchronous messages from the server.
当然，这是最普遍的情况。出于这样或那样的原因，实现者可能无法支持这一点。因此，BXXP在发送消息时允许正面和负面回复。因此，如果您想要经典的客户机/服务器模型，客户机程序应该简单地拒绝服务器发送的任何新消息。这将有效地限制来自服务器的任何异步消息。
Of course, we now need to provide mechanisms for segmentation and flow control. For the former, we just put a "continuation" or "more to come" flag in the command line for the frame. For the latter, we introduced the notion of a "transport mapping".
当然，我们现在需要提供分割和流控制机制。对于前者，我们只是在框架的命令行中放置一个“continuation”或“moreto-come”标志。对于后者，我们引入了“传输映射”的概念。
What this means is that BXXP doesn't directly define how it sits of top of TCP. Instead, it lists a bunch of requirements for how a transport service needs to support a BXXP session. Then, in a separate document, we defined how you can use TCP to meet these requirements.
这意味着BXXP并没有直接定义它如何位于TCP之上。相反，它列出了传输服务如何支持BXXP会话的一系列要求。然后，在一个单独的文档中，我们定义了如何使用TCP来满足这些需求。
This second document pretty much says "use TCP directly", except that it introduces a flow control mechanism for multiplexing channels over a single TCP connection. The mechanism we use is the same one used
第二个文档几乎说的是“直接使用TCP”，只是它引入了一种流控制机制，用于通过单个TCP连接多路复用通道。我们使用的机制与使用的机制相同
by TCP (sequence numbers and a sliding window). It's proven, and can be trivially implemented by a minimal implementation of BXXP.
通过TCP（序列号和滑动窗口）。它已经被证明，并且可以通过BXXP的最小实现来实现。
The introduction of flow control is a burden from an implementation perspective -- although TCP's mechanism is conceptually simple, an implementor must take great care. For example, issues such as priorities, queue management, and the like should be addressed. Regardless, we feel that the benefits of allowing parallelism for intra-application streams is worth it. (Besides, our belief is that few application implementors will actually code the BXXP framework directly -- rather, we expect them to use third-party packages that implement BXXP.)
从实现的角度来看，流控制的引入是一个负担——尽管TCP的机制在概念上很简单，但实现者必须非常小心。例如，应该解决诸如优先级、队列管理等问题。无论如何，我们认为允许应用程序内流并行的好处是值得的。（此外，我们相信很少有应用程序实现者会直接编写BXXP框架——相反，我们希望他们使用实现BXXP的第三方软件包。）
We use SASL. If you successfully authenticate using a channel, then there is a single user identity for each peer on that session (i.e., authentication is per-session, not per-channel). This design decision mandates that each session correspond to a single user regardless of how many channels are open on that session. One reason why this is important is that it allows service provisioning, such as quality of service (e.g., as in [34]) to be done on a per-user granularity.
我们使用SASL。如果使用通道成功进行身份验证，则该会话上的每个对等方都有一个用户标识（即，身份验证是每个会话，而不是每个通道）。此设计决策要求每个会话对应于单个用户，而不管该会话上打开了多少通道。这一点很重要的一个原因是，它允许按照每个用户的粒度进行服务提供，例如服务质量（如[34]）。
We use SASL and TLS. If you successfully complete a transport security negotiation using a channel, then all traffic on that session is secured (i.e., confidentiality is per-session, not per-channel, just like authentication).
我们使用SASL和TLS。如果使用通道成功完成传输安全协商，则该会话上的所有通信都是安全的（即，机密性是每个会话，而不是每个通道，就像身份验证一样）。
We defined a BXXP profile that's used to start the TLS engine.
我们定义了用于启动TLS引擎的BXXP配置文件。
We purposefully excluded two things that are common to most application protocols: naming and authorization.
我们故意排除了大多数应用程序协议所共有的两件事：命名和授权。
Naming was excluded from the framework because, outside of URIs, there isn't a commonly accepted framework for naming things. To our view, this remains a domain-specific problem for each application protocol. Maybe URIs are appropriate in the context of a particularly problem domain, maybe not. So, when an application protocol designer defines their own profile to do "the useful work", they'll have to deal with naming issues themselves. BXXP provides a mechanism for identifying profiles and binding them to channels. It's up to you to define the profile and use the channel.
命名被排除在框架之外，因为在URI之外，没有一个通用的命名框架。在我们看来，对于每个应用程序协议，这仍然是一个特定于域的问题。也许URI在特定问题域的上下文中是合适的，也许不是。因此，当应用程序协议设计者定义自己的概要文件来完成“有用的工作”时，他们必须自己处理命名问题。BXXP提供了一种识别配置文件并将其绑定到通道的机制。由您定义配置文件并使用频道。
Similarly, authorization was explicitly excluded from the framework. Every approach to authorization we've seen uses names to identify principals (i.e., targets and subjects), so if a framework doesn't include naming, it can't very well include authorization.
同样，授权也被明确排除在框架之外。我们见过的每种授权方法都使用名称来标识主体（即目标和主题），因此，如果框架不包含命名，它就不能很好地包含授权。
Of course, application protocols do have to deal with naming and authorization -- those are two of the issues addressed by the applications protocol designer when defining a profile for use with BXXP.
当然，应用程序协议必须处理命名和授权——这是应用程序协议设计器在定义用于BXXP的概要文件时要解决的两个问题。
So, how do you go about using BXXP? To begin, call it "BEEP", not "BXXP" (we'll explain why momentarily).
那么，如何使用BXXP呢？首先，把它叫做“嘟嘟声”，而不是“BXXP”（我们会马上解释原因）。
First, get the BEEP core specification [35] and read it. Next, define your own profile. Finally, get one of the open source SDKs (in C, Java, or Tcl) and start coding.
首先，获取BEEP核心规范[35]并阅读它。接下来，定义您自己的配置文件。最后，获取一个开源SDK（在C、Java或Tcl中）并开始编码。
The BEEP specification defines several profiles itself: a channel management profile, a family of profiles for SASL, and a transport security profile. In addition, there's a second specification [36] that explains how a BEEP session maps onto a single TCP connection.
BEEP规范本身定义了几个配置文件：一个通道管理配置文件、一系列SASL配置文件和一个传输安全配置文件。此外，还有第二个规范[36]，解释了BEEP会话如何映射到单个TCP连接。
For a complete example of an application protocol defined using BEEP, look at reliable syslog [37]. This document exemplifies the formula:
有关使用BEEP定义的应用程序协议的完整示例，请参阅reliable syslog[37]。本文件举例说明了以下公式：
application protocol = BEEP + 1 or more profiles + authorization policies + provisioning rules (e.g., use of SRV RRs [38])
应用程序协议=哔哔声+1个或多个配置文件+授权策略+设置规则（例如，使用SRV RRs[38]）
We started work on BXXP in the fall of 1998. The IETF formed a working group on BXXP in the summer of 2000. Although the working group made some enhancements to BXXP, three are the most notable:
我们于1998年秋天开始研究BXXP。IETF于2000年夏天成立了BXXP工作组。尽管工作组对BXXP进行了一些改进，但其中三项最为显著：
o The payload default is "application/octet-stream". This is primarily for wire-efficiency -- if you care about wire-efficiency, then you probably wouldn't be using "text/xml"...
o 有效负载默认值为“应用程序/八位字节流”。这主要是为了电线效率——如果您关心电线效率，那么您可能不会使用“text/xml”。。。
o One-to-many exchanges are supported (the client sends one message and the server sends back many replies).
o 支持一对多交换（客户端发送一条消息，服务器返回多条回复）。
o BXXP is now called BEEP (more comic possibilities).
o BXXP现在被称为BEEP（更滑稽的可能性）。
Consult Section [35]'s Section 8 for a discussion of BEEP-related security issues.
有关BEEP相关安全问题的讨论，请参阅第[35]节的第8节。
References
工具书类
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[2] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[3] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[3] Berners Lee，T.，Fielding，R.和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[4] Herriot, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[4] Herriot，R.，“因特网打印协议/1.0：编码和传输”，RFC2565，1999年4月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[6] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] 《传输控制协议》，标准7，RFC 793，1981年9月。
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[8] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[9] Microsystems, Sun., "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[9] Microsystems，Sun.，“NFS：网络文件系统协议规范”，RFC 1094，1989年3月。
[10] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[10] Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[11] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[12] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[12] Berners Lee，T.和D.Connolly，“超文本标记语言-2.0”，RFC 18661995年11月。
[13] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[13] 弗里德，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[14] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, December 1994.
[14] 迈尔斯，J.，“IMAP4认证机制”，RFC 17311994年12月。
[15] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[15] 弗里德，N.，“用于命令管道的SMTP服务扩展”，RFC 2197，1997年9月。
[16] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[16] Rescorla，E.和A.Schiffman，“安全超文本传输协议”，RFC 2660，1999年8月。
[17] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[17] 迈尔斯，J.，“简单认证和安全层（SASL）”，RFC2222，1997年10月。
[18] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998.
[18] Newman，C.，“一次性密码SASL机制”，RFC 2444，1998年10月。
[19] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[19] 迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[20] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[20] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[21] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[21] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[22] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[23] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[23] Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[24] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[24] Hoffman，P.，“TLS上安全SMTP的SMTP服务扩展”，RFC 2487，1999年1月。
[25] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[25] Newman，C.“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年6月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[26] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[27] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[27] Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[28] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[28] Touch，J.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
[29] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[29] Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[30] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[30] 万维网联盟，“可扩展标记语言（XML）1.0”，W3C XML，1998年2月<http://www.w3.org/TR/1998/REC-xml-19980210>.
[31] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[31] Case，J.，Fedor，M.，Schoffstall，M.和C.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月。
[32] World Wide Web Consortium, "SMUX Protocol Specification", Working Draft, July 1998, <http://www.w3.org/TR/1998/WD-mux-19980710>.
[32] 万维网联盟，“SMUX协议规范”，工作草案，1998年7月<http://www.w3.org/TR/1998/WD-mux-19980710>.
[33] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[33] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[34] Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, April 1999.
[34] Waitzman，D.，“具有服务质量的鸟类携带者IP”，RFC 2549，1999年4月。
[35] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[35] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[36] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[36] Rose，M.“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[37] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.
[37] New，D.和M.Rose，“syslog的可靠交付”，RFC3195，2001年11月。
[38] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[38] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[39] <http://mappa.mundi.net/cartography/Wheel/>
[39] <http://mappa.mundi.net/cartography/Wheel/>
Author's Address
作者地址
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
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编辑功能的资金目前由互联网协会提供。