Network Working Group S. Christey
Request for Comments: 2795 MonkeySeeDoo, Inc.
Category: Informational 1 April 2000
Network Working Group S. Christey
Request for Comments: 2795 MonkeySeeDoo, Inc.
Category: Informational 1 April 2000
The Infinite Monkey Protocol Suite (IMPS)
无限猴子协议套件（IMPS）
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.
这份备忘录描述了一个协议套件，它支持无限多的猴子坐在无限多的打字机旁，以确定它们何时制作了威廉·莎士比亚的全部作品或一个好的电视节目。该套件包括猴子和与其交互的组织的通信和控制协议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Objects In The Suite . . . . . . . . . . . . . . . . . . . 2
3. IMPS Packet Structure . . . . . . . . . . . . . . . . . . 4
4. Infinite Threshold Accounting Gadget (I-TAG) Encoding . . 5
5. KEEPER Specification . . . . . . . . . . . . . . . . . . . 6
5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN) . . . . . . 7
5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO) . . . . . 8
5.3 Requirements for KEEPER Request and Response Codes . . . 8
5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER . . . . . . 9
6. CHIMP Specification . . . . . . . . . . . . . . . . . . . 9
6.1 SIMIAN Client Requests . . . . . . . . . . . . . . . . . 10
6.2 ZOO Server Responses . . . . . . . . . . . . . . . . . . 11
6.3 Example SIMIAN-to-ZOO Session using CHIMP . . . . . . . 11
7. IAMB-PENT SPECIFICATION . . . . . . . . . . . . . . . . . 12
7.1 ZOO Client Requests . . . . . . . . . . . . . . . . . . 12
7.2 BARD Responses . . . . . . . . . . . . . . . . . . . . . 12
7.3 Example ZOO-to-BARD Session using IAMB-PENT . . . . . . 13
8. PAN Specification . . . . . . . . . . . . . . . . . . . . 13
8.1 ZOO Requests . . . . . . . . . . . . . . . . . . . . . . 14
8.2 CRITIC Responses . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Objects In The Suite . . . . . . . . . . . . . . . . . . . 2
3. IMPS Packet Structure . . . . . . . . . . . . . . . . . . 4
4. Infinite Threshold Accounting Gadget (I-TAG) Encoding . . 5
5. KEEPER Specification . . . . . . . . . . . . . . . . . . . 6
5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN) . . . . . . 7
5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO) . . . . . 8
5.3 Requirements for KEEPER Request and Response Codes . . . 8
5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER . . . . . . 9
6. CHIMP Specification . . . . . . . . . . . . . . . . . . . 9
6.1 SIMIAN Client Requests . . . . . . . . . . . . . . . . . 10
6.2 ZOO Server Responses . . . . . . . . . . . . . . . . . . 11
6.3 Example SIMIAN-to-ZOO Session using CHIMP . . . . . . . 11
7. IAMB-PENT SPECIFICATION . . . . . . . . . . . . . . . . . 12
7.1 ZOO Client Requests . . . . . . . . . . . . . . . . . . 12
7.2 BARD Responses . . . . . . . . . . . . . . . . . . . . . 12
7.3 Example ZOO-to-BARD Session using IAMB-PENT . . . . . . 13
8. PAN Specification . . . . . . . . . . . . . . . . . . . . 13
8.1 ZOO Requests . . . . . . . . . . . . . . . . . . . . . . 14
8.2 CRITIC Responses . . . . . . . . . . . . . . . . . . . . 14
8.3 Table of CRITIC Reject Codes . . . . . . . . . . . . . . 15
8.4 Example ZOO-to-CRITIC Session using PAN . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . 18
12. Author's Address . . . . . . . . . . . . . . . . . . . . 19
13. Full Copyright Statement . . . . . . . . . . . . . . . . .20
8.3 Table of CRITIC Reject Codes . . . . . . . . . . . . . . 15
8.4 Example ZOO-to-CRITIC Session using PAN . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . 18
12. Author's Address . . . . . . . . . . . . . . . . . . . . 19
13. Full Copyright Statement . . . . . . . . . . . . . . . . .20
It has been posited that if an infinite number of monkeys sit at an infinite number of typewriters and randomly press keys, they will eventually produce the complete works of Shakespeare [1] [2]. But if such a feat is accomplished, how would anybody be able to know? And what if the monkey has flawlessly translated Shakespeare's works into Esperanto? How could one build a system that obtains these works while addressing the basic needs of monkeys, such as sleep and food? Nobody has addressed the practical implications of these important questions [3].
有人假设，如果无限多的猴子坐在无限多的打字机前，随机按键盘，它们最终会写出莎士比亚的全集[1][2]。但是，如果这样一个壮举得以实现，谁又能知道呢？如果猴子完美地将莎士比亚的作品翻译成世界语呢？如何建立一个系统，在满足猴子的基本需求（如睡眠和食物）的同时获得这些作品？没有人解决过这些重要问题的实际影响[3]。
In addition, it would be a waste of resources if such a sizable effort only focused on Shakespeare. With an infinite number of monkeys at work, it is also equally likely that a monkey could produce a document that describes how to end world poverty, cure disease, or most importantly, write a good situation comedy for television [4]. Such an environment would be ripe for innovation and, with the proper technical design, could be effectively utilized to "make the world a whole lot brighter" [5].
此外，如果这么大的努力只集中在莎士比亚身上，那将是浪费资源。由于有无数的猴子在工作，同样有可能的是，一只猴子可以制作一份文件，描述如何结束世界贫困、治愈疾病，或者最重要的是，为电视写一部好的情景喜剧[4]。这样的环境将是创新的成熟环境，通过适当的技术设计，可以有效地利用它“使整个世界更加光明”[5]。
The Infinite Monkey Protocol Suite (IMPS) is an experimental set of protocols that specifies how monkey transcripts may be collected, transferred, and reviewed for either historical accuracy (in the case of Shakespearean works) or innovation (in the case of new works). It also provides a basic communications framework for performing normal monkey maintenance.
无限猴子协议套件（IMPS）是一套实验性协议，规定了如何收集、传输和审查猴子转录本，以确保历史准确性（在莎士比亚作品中）或创新性（在新作品中）。它还提供了执行正常维护的基本通信框架。
There are four primary entities that communicate within an IMPS network. Groups of monkeys are physically located in Zone Operations Organizations (ZOOs). The ZOOs maintain the monkeys and their equipment, obtain transcripts from the monkeys' typewriters, and interact with other entities who evaluate the transcripts.
IMPS网络中有四个主要实体进行通信。猴子群实际位于区域运营组织（动物园）内。动物园维护猴子和它们的设备，从猴子的打字机上获取成绩单，并与评估成绩单的其他实体进行互动。
A SIMIAN (Semi-Integrated, Monkey-Interfacing Anthropomorphic Node) is a device that is physically attached to the monkey. It provides the communications interface between a monkey and its ZOO. It is
猿猴（半集成、猴子接口的拟人节点）是物理连接到猴子的设备。它提供猴子和动物园之间的通信接口。它是
effectively a translator for the monkey. It sends status reports and resource requests to the ZOO using human language phrases, and responds to ZOO requests on behalf of the monkey.
实际上是猴子的翻译人员。它使用人类语言短语向动物园发送状态报告和资源请求，并代表猴子响应动物园请求。
The SIMIAN uses the Cross-Habitat Idiomatic Message Protocol (CHIMP) to communicate with the ZOO. The ZOO uses the Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources (KEEPER) to interact with the SIMIAN.
猿猴使用跨栖息地惯用信息协议（黑猩猩）与动物园通信。动物园使用知识渊博且高效的生态系统资源模拟协议（KEEPER）与猿猴互动。
The ZOO obtains typewriter transcripts from the SIMIAN, which is responsible for converting the monkey's typed text into an electronic format if non-digital typewriters are used. The ZOO may then forward the transcripts to one or more entities who review the transcript's contents. IMPS defines two such reviewer protocols, although others could be added.
动物园从猿猴那里获得打字机文本，如果使用非数字打字机，猿猴负责将猴子打印的文本转换成电子格式。动物园随后可将成绩单转发给审查成绩单内容的一个或多个实体。IMPS定义了两个这样的审核员协议，尽管可以添加其他协议。
For Shakespearean works, as well as any other classic literature that has already been published, the ZOO forwards the transcript to a BARD (Big Annex of Reference Documents). The BARD determines if a transcript matches one or more documents in its annex. The ZOO sends the transcript to a BARD using the Inter-Annex Message Broadcasting Protocol for Evaluating Neoclassical Transcripts (IAMB-PENT). The transcripts are considered Neoclassical because (a) they are transferred in electronic media instead of the original paper medium, and (b) the word "classical" does not begin with the letter N.
对于莎士比亚的作品，以及任何其他已经出版的经典文学作品，动物园将抄本转发给吟游诗人（参考文件的大附件）。BARD确定成绩单是否与其附件中的一个或多个文件相匹配。动物园使用附件间信息广播协议（IAMB-PENT）将成绩单发送给BARD，以评估新古典主义成绩单。这些成绩单被认为是新古典主义的，因为（a）它们是通过电子媒体而不是原始的纸质媒体传输的，（b）“古典主义”一词不是以字母N开头的。
For new and potentially innovative works, the ZOO submits a transcript to a CRITIC (Collective Reviewer's Innovative Transcript Integration Center). The CRITIC determines if a transcript is sufficiently innovative to be published. The ZOO uses the Protocol for Assessment of Novelty (PAN) to communicate with the CRITIC. The process of using PAN to send a transcript to a CRITIC is sometimes referred to as foreshadowing.
对于新的和潜在的创新作品，动物园向评论家（集体评论员的创新成绩单整合中心）提交成绩单。评论家决定一份抄本是否具有足够的创新性以便出版。动物园使用新颖性评估协议（PAN）与评论家沟通。使用PAN向评论家发送抄本的过程有时被称为铺垫。
A diagram of IMPS concepts is provided below. Non-technical readers such as mid-level managers, marketing personnel, and liberal arts majors are encouraged to skip the next two sections. The rest of this document assumes that senior management has already stopped reading.
IMPS概念图如下所示。鼓励中层管理人员、营销人员和文科专业的非技术类读者跳过下两部分。本文件其余部分假设高级管理层已经停止阅读。
-+-+-+-+-+- CHIMP -+-+-+-+-+-
| SIMIAN/ | ----------> * *
| MONKEY | * ZOO *
| | <---------- * *
-+-+-+-+-+- KEEPER -+-+-+-+-+-
/ \
/ \
IAMB-PENT / \ PAN
/ \
V V
-+-+-+-+-+- -+-+-+-+-+-
* * * *
* BARD * * CRITIC *
* * * *
-+-+-+-+-+- -+-+-+-+-+-
-+-+-+-+-+- CHIMP -+-+-+-+-+-
| SIMIAN/ | ----------> * *
| MONKEY | * ZOO *
| | <---------- * *
-+-+-+-+-+- KEEPER -+-+-+-+-+-
/ \
/ \
IAMB-PENT / \ PAN
/ \
V V
-+-+-+-+-+- -+-+-+-+-+-
* * * *
* BARD * * CRITIC *
* * * *
-+-+-+-+-+- -+-+-+-+-+-
All IMPS protocols must utilize the following packet structure.
所有IMPS协议必须使用以下数据包结构。
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
|Version | Seq # | Protocol # | Reserved | Size |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Source | Destination |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Data | Padding |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
|Version | Seq # | Protocol # | Reserved | Size |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Source | Destination |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Data | Padding |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
The Version, Sequence Number, Protocol Number, and Reserved fields are 32 bit unsigned integers. For IMPS version 1.0, the Version must be 1. Reserved must be 0 and will always be 0 in future uses. It is included because every other protocol specification includes a "future use" reserved field which never, ever changes and is therefore a waste of bandwidth and memory. [6] [7] [8].
版本、序列号、协议号和保留字段是32位无符号整数。对于IMPS版本1.0，版本必须为1。保留值必须为0，并且在将来使用时将始终为0。之所以包括它，是因为每个其他协议规范都包含一个“未来使用”保留字段，该字段永远不会更改，因此是对带宽和内存的浪费。[6] [7] [8].
The Source and Destination are identifiers for the IMPS objects that are communicating. They are represented using Infinite TAGs (see next section).
源和目标是正在通信的IMPS对象的标识符。它们使用无限标记表示（请参见下一节）。
The Data section contains data which is of arbitrary length.
数据部分包含任意长度的数据。
The Size field records the size of the entire packet using Infinite TAG encoding.
Size字段使用无限标记编码记录整个数据包的大小。
The end of the packet may contain extra padding, between 0 and 7 bits, to ensure that the size of packet is rounded out to the next byte.
数据包的结尾可能包含0到7位之间的额外填充，以确保数据包的大小四舍五入到下一个字节。
Each SIMIAN requires a unique identifier within IMPS. This section describes design considerations for the IMPS identifier, referred to as an Infinite Threshold Accounting Gadget (I-TAG). The I-TAG can represent numbers of any size.
每个猿猴在IMPS中都需要一个唯一的标识符。本节介绍IMPS标识符（称为无限阈值记帐小工具（I-TAG））的设计注意事项。I-TAG可以表示任意大小的数字。
To uniquely identify each SIMIAN, a system is required that is capable of representing an infinite number of identifiers. The set of all integers can be used as a compact representation. However, all existing protocols inherently limit the number of available integers by specifying a maximum number of bytes to be used for an integer. This approach cannot work well in an IMPS network with an infinite number of monkeys to manage.
为了唯一地识别每个猿猴，需要一个能够表示无限多个标识符的系统。所有整数的集合可用作紧凑表示。但是，所有现有协议都通过指定整数使用的最大字节数来限制可用整数的数量。这种方法无法在需要管理的猴子数量无限的IMPS网络中很好地工作。
Practically speaking, one could select a byte size which could represent an integer that is greater than the number of atoms in the known universe. There are several limitations to this approach, however: (a) it would needlessly exclude IMPS implementations that may utilize sub-atomic monkeys and/or multiple universes; (b) there is not a consensus as to how many atoms there are in this universe; and (c) while the number is extremely large, it still falls pitifully short of infinity. Since any entity that fully implements IMPS is probably very, very good at handling infinite numbers, IMPS must ensure that it can represent them.
实际上，我们可以选择一个字节大小，它可以表示一个大于已知宇宙中原子数的整数。然而，这种方法有几个局限性：（a）不必要地排除可能利用亚原子猴子和/或多宇宙的IMPS实现；（b） 关于这个宇宙中有多少原子还没有一个共识；（c）虽然这个数字非常大，但仍然远远不够无穷大。由于任何完全实现IMP的实体可能非常非常擅长处理无限数，IMP必须确保它能够表示无限数。
Netstrings, i.e. strings which encode their own size, were considered. However, netstrings have not been accepted as a standard, and they do not scale to infinity. As stated in [9], "[Greater than] 999999999 bytes is bad." Well put.
考虑了网络字符串，即编码自身大小的字符串。然而，netstring还没有被接受为标准，并且它们不能无限扩展。如[9]中所述，“[大于]99999999字节是坏的。”很好地说。
A scheme for identifying arbitrary dates was also considered for implementation [10]. While it solves the Y10K problem and does scale to infinity, its ASCII representation wastes memory by a factor greater than 8. While this may not seem important in an environment that has enough resources to support an infinite number of monkeys, it is inelegant for the purpose of monkey identification. It is also CPU intensive to convert such a representation to a binary number (at least based on the author's implementation, which was written in a combination of LISP, Perl, and Java). The algorithm is complicated and could lead to incorrect implementations. Finally, the author of this document sort of forgot about that RFC until it was too late to include it properly, and was already emotionally attached to the I-TAG idea anyway. It should be noted, however, that if a monkey had typed this particular section and it was submitted to a CRITIC, it would probably receive a PAN rejection code signifying the reinvention of the wheel.
还考虑实施一种确定任意日期的方案[10]。虽然它解决了Y10K问题并可扩展到无穷大，但其ASCII表示浪费内存的因子大于8。虽然在一个拥有足够资源来支持无限数量猴子的环境中，这似乎并不重要，但对于猴子识别来说，这是不雅观的。将这种表示转换为二进制数也是CPU密集型的（至少基于作者的实现，它是用LISP、Perl和Java的组合编写的）。该算法很复杂，可能会导致错误的实现。最后，本文档的作者有点忘记了RFC，直到现在已经太晚了，无法正确地包含它，并且已经在情感上依附于I-TAG的想法。然而，应该注意的是，如果一只猴子键入了这个特定的部分，并将其提交给评论家，它可能会收到一个泛拒绝代码，表示轮子的重新发明。
Since there is no acceptable representation for I-TAGs available, one is defined below.
由于I型标签没有可接受的表示形式，因此定义如下。
An I-TAG is divided into three sections:
I型标签分为三个部分：
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
| META-SIZE | SIZE | ID |
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
| META-SIZE | SIZE | ID |
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
SIZE specifies how many bytes are used to represent the ID, which is an arbitrary integer. META-SIZE specifies an upper limit on how many bits are used to represent SIZE.
大小指定用于表示ID的字节数，ID是一个任意整数。META-SIZE指定用于表示大小的位数上限。
META-SIZE is an arbitrary length sequence of N '1' bits terminated by a '0' bit, i.e. it has the form:
META-SIZE是以“0”位终止的N“1”位的任意长度序列，即其形式为：
11111...1110
11111...1110
where N is the smallest number such that 2^N exceeds the number of bits required to represent the number of bytes that are necessary to store the ID (i.e., SIZE).
其中N是最小的数字，使得2^N超过表示存储ID所需的字节数（即大小）所需的位数。
The SIZE is then encoded using N bits, ordered from the most significant bit to the least significant bit.
然后使用N位对大小进行编码，从最高有效位到最低有效位排序。
Finally, the ID is encoded using SIZE bytes.
最后，使用大小字节对ID进行编码。
This representation, while clunky, makes efficient use of memory and is scalable to infinity. For any number X which is less than 2^N (for any N), a maximum of (N + log(N) + log(log(N)))/8 bytes is necessary to represent X. The math could be slightly incorrect, but it sounds right.
这种表示法虽然笨重，但可以有效地利用内存，并且可以无限扩展。对于小于2^N的任何数字X（对于任何N），表示X的最大值（N+log（N）+log（log（N））/8字节是必需的。数学可能有点不正确，但听起来是正确的。
A remarkable, elegant little C function was written to implement I-TAG processing, but it has too many lines of code to include in this margin [11].
编写了一个出色、优雅的小C函数来实现I-TAG处理，但它的代码行太多，无法包含在这个空白处[11]。
Following is a description of the Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources (KEEPER), which the ZOO uses to communicate with the SIMIAN. The IMPS protocol number for KEEPER is 1.
以下是动物园用于与猿猴通信的知识渊博且高效的生态系统资源仿真协议（KEEPER）的描述。KEEPER的IMPS协议编号为1。
KEEPER is a connectionless protocol. The ZOO sends a request to the SIMIAN using a single IMPS packet. The SIMIAN sends a response back to the ZOO with another IMPS packet. The data portion of the packet is of the following form:
KEEPER是一个无连接的协议。动物园使用单个IMPS数据包向猿猴发送请求。猿猴用另一个IMPS数据包向动物园发回响应。数据包的数据部分具有以下形式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Message ID | Message Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Message ID | Message Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version, Type, Message ID, and Message are all 16-bit integers.
版本、类型、消息ID和消息都是16位整数。
Version = the version of KEEPER being used (in this document, the version is 1)
版本=使用的保管员版本（本文件中版本为1）
Type = the type of message being sent. '0' is a request; '1' is a response
Type=正在发送的消息的类型。'“0”是一个请求；'“1”是一种回应
Message ID = a unique identifier to distinguish different messages
消息ID=用于区分不同消息的唯一标识符
Message Code = the specific message being sent
消息代码=正在发送的特定消息
When a ZOO sends a KEEPER request, the SIMIAN must send a KEEPER response which uses the same Message ID as the original request.
当动物园发送管理员请求时，猿猴必须发送管理员响应，该响应使用与原始请求相同的消息ID。
CODE NAME DESCRIPTION
+-----------------------------------------------------------+
| 0 | RESERVED | Reserved |
+-----------------------------------------------------------+
| 1 | STATUS | Determine status of monkey |
+-----------------------------------------------------------+
| 2 | HEARTBEAT| Check to see if monkey has a heartbeat |
+-----------------------------------------------------------+
| 3 | WAKEUP | Wake up monkey |
+-----------------------------------------------------------+
| 4 | TYPE | Make sure monkey is typing |
+-----------------------------------------------------------+
| 5 | FASTER | Monkey must type faster |
+-----------------------------------------------------------+
| 6 |TRANSCRIPT| Send transcript |
+-----------------------------------------------------------+
| 7 | STOP | Stop all monkey business |
+-----------------------------------------------------------+
|8-512 | FUTURE | Reserved for future use |
+-----------------------------------------------------------+
| 513+ | USER | User defined |
+-----------------------------------------------------------+
CODE NAME DESCRIPTION
+-----------------------------------------------------------+
| 0 | RESERVED | Reserved |
+-----------------------------------------------------------+
| 1 | STATUS | Determine status of monkey |
+-----------------------------------------------------------+
| 2 | HEARTBEAT| Check to see if monkey has a heartbeat |
+-----------------------------------------------------------+
| 3 | WAKEUP | Wake up monkey |
+-----------------------------------------------------------+
| 4 | TYPE | Make sure monkey is typing |
+-----------------------------------------------------------+
| 5 | FASTER | Monkey must type faster |
+-----------------------------------------------------------+
| 6 |TRANSCRIPT| Send transcript |
+-----------------------------------------------------------+
| 7 | STOP | Stop all monkey business |
+-----------------------------------------------------------+
|8-512 | FUTURE | Reserved for future use |
+-----------------------------------------------------------+
| 513+ | USER | User defined |
+-----------------------------------------------------------+
CODE NAME DESCRIPTION
+-------------------------------------------------------------+
| 0 | RESERVED | Reserved |
+-------------------------------------------------------------+
| 1 | ASLEEP | Status: Monkey is asleep |
+-------------------------------------------------------------+
| 2 | GONE | Status: Monkey is not at typewriter |
+-------------------------------------------------------------+
| 3 |DISTRACTED| Status: Monkey is distracted (not typing) |
+-------------------------------------------------------------+
| 4 |NORESPONSE| Status: Monkey is not responding |
+-------------------------------------------------------------+
| 5 | ALIVE | Status: Monkey is alive |
+-------------------------------------------------------------+
| 6 | DEAD | Status: Monkey is dead |
+-------------------------------------------------------------+
| 7 | ACCEPT | Monkey accepts request |
+-------------------------------------------------------------+
| 8 | REFUSE | Monkey refuses request |
+-------------------------------------------------------------+
| 9-512| FUTURE | Reserved for future use |
+-------------------------------------------------------------+
| 513+ | USER | User defined |
+-------------------------------------------------------------+
CODE NAME DESCRIPTION
+-------------------------------------------------------------+
| 0 | RESERVED | Reserved |
+-------------------------------------------------------------+
| 1 | ASLEEP | Status: Monkey is asleep |
+-------------------------------------------------------------+
| 2 | GONE | Status: Monkey is not at typewriter |
+-------------------------------------------------------------+
| 3 |DISTRACTED| Status: Monkey is distracted (not typing) |
+-------------------------------------------------------------+
| 4 |NORESPONSE| Status: Monkey is not responding |
+-------------------------------------------------------------+
| 5 | ALIVE | Status: Monkey is alive |
+-------------------------------------------------------------+
| 6 | DEAD | Status: Monkey is dead |
+-------------------------------------------------------------+
| 7 | ACCEPT | Monkey accepts request |
+-------------------------------------------------------------+
| 8 | REFUSE | Monkey refuses request |
+-------------------------------------------------------------+
| 9-512| FUTURE | Reserved for future use |
+-------------------------------------------------------------+
| 513+ | USER | User defined |
+-------------------------------------------------------------+
Below are the requirements for request and response codes within KEEPER.
以下是KEEPER内的请求和响应代码要求。
1. A SIMIAN must respond to a STATUS request with an ALIVE, DEAD, ASLEEP, GONE, DISTRACTED, or NORESPONSE code.
1. 猿猴必须用活着、死了、睡着、走了、分心或无响应代码响应状态请求。
2. A SIMIAN must respond to a HEARTBEAT request with an ALIVE or DEAD code. SIMIAN implementors must be careful when checking the heartbeat of very relaxed monkeys who practice transcendental meditation or yoga, as they may appear DEAD even if they are still alive.
2. 猿猴必须用活的或死的代码响应心跳请求。猿猴的实施者在检查练习超验冥想或瑜伽的非常放松的猴子的心跳时必须小心，因为即使它们还活着，它们也可能看起来已经死了。
3. A SIMIAN must respond to a STOP request with a NORESPONSE, ALIVE, DEAD, or GONE code. How a SIMIAN stops the monkey is implementation-specific. However, the SIMIAN should preserve the monkey's ALIVE status to protect the ZOO from being shut down by authorities or animal rights groups. If the monkey is present but the SIMIAN interface is unable to verify whether the monkey is ALIVE or DEAD, then it must use a NORESPONSE.
3. 猿猴必须用NORESPONSE、ALIVE、DEAD或GONE代码响应停止请求。猿猴如何阻止猴子是特定于实现的。然而，猿猴应该保持猴子的活着状态，以保护动物园不被当局或动物权利组织关闭。如果猴子存在，但SIMIAN接口无法验证猴子是活的还是死的，那么它必须使用NORESPONSE。
4. A SIMIAN should respond to a TYPE or FASTER request with an ACCEPT code, especially if there are deadlines. The only other allowed responses are REFUSE, ASLEEP, GONE, NORESPONSE, or DEAD. This protocol does not define what actions should be taken if a SIMIAN responds with REFUSE, although a BRIBE_BANANA command may be added in future versions.
4. 猿猴应该用接受代码响应类型或更快的请求，尤其是在有截止日期的情况下。其他被允许的回答只有拒绝、睡着、不见、无反应或死亡。该协议没有定义如果猿猴以拒绝回应应该采取什么行动，尽管在未来的版本中可能会添加贿赂香蕉命令。
5. A SIMIAN must respond to a WAKEUP request with ACCEPT, REFUSE, GONE, NORESPONSE, or DEAD.
5. 猿猴必须以接受、拒绝、消失、无响应或死亡来响应唤醒请求。
6. A SIMIAN must respond to a TRANSCRIPT request by establishing a CHIMP session to send the transcript to the ZOO.
6. 猿猴必须通过建立黑猩猩会话向动物园发送成绩单来响应成绩单请求。
Assume a ZOO (SanDiego) must interact with a monkey named BoBo. Using KEEPER, SanDiego would interface with BoBo's SIMIAN (BoBoSIM). The following exchange might take place if BoBo begins to evolve self-awareness and independence.
假设动物园（SanDiego）必须与一只名叫BoBo的猴子互动。使用守门员，桑迪戈将与波波的猿猴（波波西姆）接口。如果BoBo开始发展自我意识和独立性，下面的交流可能会发生。
SanDiego> STATUS BoBoSIM> DISTRACTED SanDiego> TYPE BoBoSIM> REFUSE SanDiego> TYPE BoBoSIM> REFUSE SanDiego> TYPE BoBoSIM> GONE
桑迪耶戈>状态博博西姆>心烦意乱的桑迪耶戈>类型博西姆>拒绝桑迪耶戈>类型博西姆>拒绝桑迪耶戈>类型博西姆>消失
The following exchange might take place early in the morning, if BoBo was being poorly maintained and was working at its typewriter very late the night before.
如果BoBo的维护不善，并且在前一天晚上很晚的时候还在用打字机工作，那么接下来的交换可能会在凌晨进行。
SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> HEARTBEAT BoBoSIM> DEAD SanDiego> TRANSCRIPT
SanDiego>唤醒BoBoSIM>无应答SanDiego>唤醒BoBoSIM>无应答SanDiego>唤醒BoBoSIM>无应答SanDiego>心跳BoBoSIM>死亡SanDiego>转录本
Following is a description of the Cross-Habitat Idiomatic Message Protocol (CHIMP), which the SIMIAN uses to communicate with the ZOO. The IMPS protocol number for CHIMP is 2.
以下是对跨栖息地惯用信息协议（黑猩猩）的描述，猿猴使用该协议与动物园进行通信。黑猩猩的IMPS协议编号为2。
CHIMP is a connection-oriented protocol. A SIMIAN (the "client") sends a series of requests to the ZOO (the "server"), which sends replies back to the SIMIAN.
CHIMP是一种面向连接的协议。猿猴（“客户端”）向ZOO（“服务器”）发送一系列请求，ZOO（“服务器”）将回复发送回猿猴。
SEND <resource>
发送<资源>
The SIMIAN is requesting a specific resource. The resource may be FOOD, WATER, MEDICINE, VETERINARIAN, or TECHNICIAN. The SIMIAN makes requests for FOOD or WATER by interpreting the monkey's behavior and environment, e.g. its food dish. It requests MEDICINE or VETERINARIAN if it observes that the monkey's health is declining in any way, e.g. carpal tunnel syndrome or sore buttocks. How the SIMIAN determines health is implementation-specific. In cases where the SIMIAN itself may be malfunctioning, it may request a TECHNICIAN.
猿猴正在请求特定的资源。资源可以是食物、水、药品、兽医或技术人员。猿猴通过解释猴子的行为和环境，例如它的食物盘，来请求食物或水。如果观察到猴子的健康状况正在以任何方式下降，例如腕管综合征或臀部疼痛，则需要药物或兽医。SIMIAN如何确定运行状况是特定于实现的。如果猿猴本身可能出现故障，它可能会请求技术人员。
REPLACE <item>
替换<item>
The ZOO must replace an item that is used by the monkey during typing activities. The item to be replaced may be TYPEWRITER, PAPER, RIBBON, CHAIR, TABLE, or MONKEY.
动物园必须更换猴子在打字活动中使用的物品。要更换的物品可以是打字机、纸张、色带、椅子、桌子或猴子。
CLEAN <item>
清洁<item>
The SIMIAN is requesting that the ZOO must clean an item. The item may be CHAIR, TABLE, or MONKEY. How the ZOO cleans the item is implementation-specific. This command is identified in the protocol because it has been theorized that if an infinite number of monkeys sit at an infinite number of typewriters, the smell would be unbearable [12]. If this theory is proven true, then CLEAN may become the most critical command in the entire protocol suite.
猿猴要求动物园必须清理一件物品。物品可以是椅子、桌子或猴子。动物园如何清理项目是具体实现的。这个命令在协议中被确定，因为它已经被理论化，如果无限多的猴子坐在无限多的打字机旁，气味将无法忍受[12]。如果这一理论被证明是正确的，那么CLEAN可能成为整个协议套件中最关键的命令。
NOTIFY <status>
通知<状态>
The SIMIAN notifies the ZOO of the monkey's status. The status may be any status as defined in the KEEPER protocol, i.e. ASLEEP, GONE, DISTRACTED, NORESPONSE, ALIVE, or DEAD.
猿猴通知动物园猴子的状况。该状态可以是《看守人协议》中定义的任何状态，即睡眠、消失、分心、无反应、活着或死亡。
TRANSCRIPT <size>
转录本<大小>
The SIMIAN notifies the ZOO of a new transcript from the monkey. The number of characters in the transcript is specified in the size parameter.
猿猴将猴子的新记录通知动物园。成绩单中的字符数在size参数中指定。
BYE
再见
The SIMIAN is terminating the connection.
猿猴正在终止连接。
HELO <free text>
HELO<自由文本>
Upon initial connection, the ZOO must send a HELO reply.
初始连接后，动物园必须发送HELO回复。
ACCEPT
接受
The ZOO will fulfill the SIMIAN's request.
动物园将满足猿猴的要求。
DELAY
延迟
The ZOO will fulfill the SIMIAN's request at a later time.
动物园将在稍后满足猿猴的要求。
REFUSE
拒绝
The ZOO refuses to fulfill the SIMIAN's request.
动物园拒绝满足猿猴的要求。
RECEIVED
收到
The ZOO has received the full text of a transcript that has been submitted by the SIMIAN.
动物园已经收到了猿猴提交的成绩单的全文。
Assume a monkey BoBo with a SIMIAN interface named BoBoSIM, and a ZOO named SanDiego. Once the BoBoSIM client has established a connection to the SanDiego server, the following session might take place.
假设有一只猴子BoBo，它有一个名为BoBoSIM的猿猴界面和一个名为SanDiego的动物园。一旦BoBoSIM客户端与SanDiego服务器建立连接，可能会发生以下会话。
SanDiego> HELO CHIMP version 1.0 4/1/2000
BoBoSIM> REPLACE PAPER
SanDiego> ACCEPT
BoBoSIM> TRANSCRIPT 87
SanDiego> ACCEPT
BoBoSIM> xvkxvn i hate Binky xFnk , feEL hungry and sIck sbNf
BoBoSIM> so so sad sDNfkodgv .,n., ,HELP MEEEEEEEEE cv.Cvn l
SanDiego> RECEIVED
BoBoSIM> SEND FOOD
SanDiego> ACCEPT
BoBoSIM> SEND MEDICINE
SanDiego> DELAY
BoBoSIM> SEND VETERINARIAN
SanDiego> REFUSE
BoBoSIM> SEND VETERINARIAN
SanDiego> HELO CHIMP version 1.0 4/1/2000
BoBoSIM> REPLACE PAPER
SanDiego> ACCEPT
BoBoSIM> TRANSCRIPT 87
SanDiego> ACCEPT
BoBoSIM> xvkxvn i hate Binky xFnk , feEL hungry and sIck sbNf
BoBoSIM> so so sad sDNfkodgv .,n., ,HELP MEEEEEEEEE cv.Cvn l
SanDiego> RECEIVED
BoBoSIM> SEND FOOD
SanDiego> ACCEPT
BoBoSIM> SEND MEDICINE
SanDiego> DELAY
BoBoSIM> SEND VETERINARIAN
SanDiego> REFUSE
BoBoSIM> SEND VETERINARIAN
SanDiego> REFUSE BoBoSIM> NOTIFY NORESPONSE SanDiego> ACCEPT BoBoSIM> NOTIFY DEAD SanDiego> ACCEPT BoBoSIM> REPLACE MONKEY SanDiego> ACCEPT
SanDiego>拒绝BoBoSIM>通知NORESPONSE SanDiego>接受BoBoSIM>通知死亡SanDiego>接受BoBoSIM>替换猴子SanDiego>接受
Following is a description of the Inter-Annex Message Broadcasting Protocol for Evaluating Neoclassical Transcripts (IAMB-PENT), which a ZOO uses to send transcripts to a BARD. The IMPS protocol number is 5.
以下是用于评估新古典主义成绩单的附件间消息广播协议（IAMB-PENT）的说明，动物园使用该协议向游吟诗人发送成绩单。IMPS协议编号为5。
IAMB-PENT is a connection-oriented protocol. A ZOO (the "client") sends a transcript phrases to the BARD (the "server"), which evaluates the transcript and notifies the ZOO if the transcript matches all of a classical work or a portion thereof.
IAMB-PENT是一种面向连接的协议。动物园（“客户”）向游吟诗人（“服务器”）发送一份抄本，游吟诗人（“服务器”）对抄本进行评估，并通知动物园该抄本是否匹配所有经典作品或其中的一部分。
RECEIVETH <transcript name>
RECEIVETH<转录本名称>
The ZOO notifies the BARD of a new transcript to be evaluated. The name of the transcript is provided.
动物园通知游吟诗人要评估的新成绩单。提供了成绩单的名称。
ANON <size>
ANON<size>
The ZOO notifies the BARD that a transcript of the given size is to be provided soon. The text of the transcript is then sent.
动物园通知游吟诗人，将很快提供给定大小的成绩单。然后发送成绩单文本。
ABORTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
ABORTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
The ZOO notifies the BARD that it is about to close the connection. The ZOO must specify a closing message. A2, A3, A4, and A5 must be accented syllables. U3, U4, and U5 must not be accented.
动物园通知游吟诗人它即将关闭连接。动物园必须指定关闭消息。A2、A3、A4和A5必须是重音音节。U3、U4和U5不得加重音。
HARK <U1> <A2> <U3> <A3> <U4> <A4> <U5> <A5>
HARK <U1> <A2> <U3> <A3> <U4> <A4> <U5> <A5>
When the ZOO establishes a connection, the BARD must send a HARK command. A2, A3, A4, and A5 must be accented syllables. U1, U2, U3, U4, and U5 must not be accented.
当动物园建立连接时，游吟诗人必须发送一个HARK命令。A2、A3、A4和A5必须是重音音节。U1、U2、U3、U4和U5不得加重音。
PRITHEE <A2> <U3> <A3> <U4> <A4> <U5> <A5>
PRITHEE <A2> <U3> <A3> <U4> <A4> <U5> <A5>
When a ZOO uses a RECEIVETH command to specify a forthcoming transcript, the BARD must respond with a PRITHEE. A2, A3, A4, and A5 must be accented syllables. U3, U4, and U5 must not be accented.
当动物园使用RECEIVETH命令指定即将发布的成绩单时，游吟诗人必须用prie来响应。A2、A3、A4和A5必须是重音音节。U3、U4和U5不得加重音。
REGRETTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
REGRETTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
If the BARD does not have the transcript in its Annex, it uses the REGRETTETH command to notify the ZOO. A2, A3, A4, and A5 must be accented syllables. U3, U4, and U5 must not be accented.
如果游吟诗人的附件中没有成绩单，它会使用“重新记录”命令通知动物园。A2、A3、A4和A5必须是重音音节。U3、U4和U5不得加重音。
ACCEPTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
ACCEPTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
If the BARD has located the transcript in its Annex, it uses the ACCEPTETH command to notify the ZOO. A2, A3, A4, and A5 must be accented syllables. U3, U4, and U5 must not be accented.
如果BARD在其附件中找到了成绩单，它将使用ACCEPTETH命令通知动物园。A2、A3、A4和A5必须是重音音节。U3、U4和U5不得加重音。
This is a sample IAMB-PENT session in which a ZOO (SanDiego) sends a transcript to a BARD (William).
这是一个IAMB-PENT会议的示例，动物园（SanDiego）向吟游诗人（William）发送一份成绩单。
William> HARK now, what light through yonder window breaks? SanDiego> RECEIVETH TRANSCRIPT SanDiego.BoBo.17 William> PRITHEE thy monkey's wisdom poureth forth! SanDiego> ANON 96 SanDiego> I must be cruel, only to be kind. Thus bad begins, and worse remains in front. William> REGRETTETH none hath writ thy words before SanDiego> ABORTETH Fate may one day bless my zone
威廉：听着，从那边窗户射进来的是什么光线？SanDiego>收到成绩单SanDiego.BoBo.17 William>请你的猴子智慧迸发！SanDiego>ANON 96 SanDiego>我必须残忍，只是为了善良。这样，坏的开始，更坏的继续在前面。威廉>后悔没有人在桑迪哥面前写下你的话>放弃命运也许有一天会保佑我的地盘
Following is a description of the Protocol for Assessment of Novelty (PAN). A ZOO uses PAN to send monkey transcripts for review by a CRITIC. The IMPS protocol number for PAN is 10 [13].
以下是新颖性评估（PAN）方案的说明。一家动物园用PAN发送猴子的成绩单供评论家审查。PAN的IMPS协议编号为10[13]。
PAN is a connection-oriented protocol. A ZOO (the "unwashed masses") sends a request to the CRITIC (the "all-powerful"), which sends a response back to the ZOO.
PAN是一种面向连接的协议。动物园（“未清洗的群众”）向批评家（“全能者”）发送请求，批评家向动物园发送回复。
COMPLIMENT <text>
赞美<text>
The ZOO may say something nice to the CRITIC using the given text. The CRITIC does not respond to the compliment within the protocol. However, it is generally believed that the CRITIC is more likely to accept a new transcript when a ZOO uses many compliments.
动物园可能会用给定的文本对评论家说些好话。批评家没有在协议中对恭维做出回应。然而，人们普遍认为，当动物园使用许多赞美语时，批评家更可能接受新的文字记录。
TRANSCRIPT <name> <size>
TRANSCRIPT <name> <size>
The ZOO notifies the CRITIC of a new transcript for review. The name of the transcript, plus the number of characters, are specified as parameters to this request. The text of the transcript is then sent.
动物园通知评论家一份新的抄本以供审查。转录本的名称加上字符数被指定为此请求的参数。然后发送成绩单文本。
THANKS
谢谢
This is an indicator that a ZOO is about to terminate the connection.
这表示动物园即将终止连接。
SIGH <insult>
叹息<侮辱>
When the ZOO establishes a connection, the CRITIC must respond with a SIGH and an optional insult.
当动物园建立起一种联系时，批评家必须以叹息和随意的侮辱来回应。
IMPRESS_ME
给我留下深刻印象
A CRITIC must respond with an IMPRESS_ME once a ZOO has made a TRANSCRIPT request.
一旦动物园提出抄本要求，评论家必须给我留下深刻印象。
REJECT <code> REJECT 0 <text>
REJECT <code> REJECT 0 <text>
When a transcript has been received, the CRITIC must respond with a REJECT and a code that indicates the reason for rejection. A table of rejection codes is provided below. When the code is 0, the CRITIC may respond using free text. A CRITIC may send a REJECT before it has received or processed the full text of the transcript.
收到成绩单后，评论家必须以拒绝和表明拒绝原因的代码回应。拒绝代码表如下所示。当代码为0时，批评家可以使用自由文本进行响应。评论家可以在收到或处理成绩单全文之前发送拒绝信。
DONT_CALL_US_WE'LL_CALL_YOU
别叫我们，我们会叫你的
The CRITIC makes this statement before terminating the connection.
批评家在终止连接之前做出此声明。
GRUDGING_ACCEPTANCE
勉强接受
THIS RESPONSE IS NOT SUPPORTED IN THIS VERSION OF PAN. The Working group for the Infinite Monkey Protocol Suite (WIMPS) agreed that it is highly unlikely that a CRITIC will ever use this response when a REJECT is available. It is only included as an explanation to implementors who do not fully understand how CRITICs work. In time, it is possible that a CRITIC may evolve (in much the same way that a monkey might). Should such a time ever come, the WIMPS may decide to support this response in later versions of PAN.
此版本的PAN不支持此响应。无限猴子协议套件（WIMPS）的工作组一致认为，当有拒绝时，批评家极不可能使用此响应。它只是作为对那些不完全理解批评者如何工作的实施者的一种解释。随着时间的推移，批评家可能会进化（与猴子进化的方式大致相同）。如果这一时刻到来，WIMP可能会决定在PAN的后续版本中支持这一响应。
CODE DESCRIPTION
-------------------------------------------------------------------
| 0 | <Encrypted response following; see below>
-------------------------------------------------------------------
| 1 | "You're reinventing the wheel."
-------------------------------------------------------------------
| 2 | "This will never, ever sell."
-------------------------------------------------------------------
| 3 | "Huh? I don't understand this at all."
-------------------------------------------------------------------
| 4 | "You forgot one little obscure reference from twenty years
| | ago that renders your whole idea null and void."
-------------------------------------------------------------------
| 5 | "Due to the number of submissions, we could not accept every
| | transcript."
-------------------------------------------------------------------
| 6 | "There aren't enough charts and graphs. Where is the color?"
-------------------------------------------------------------------
| 7 | "I'm cranky and decided to take it out on you."
-------------------------------------------------------------------
| 8 | "This is not in within the scope of what we are looking for."
-------------------------------------------------------------------
| 9 | "This is too derivative."
-------------------------------------------------------------------
|10 | "Your submission was received after the deadline. Try again
| | next year."
-------------------------------------------------------------------
CODE DESCRIPTION
-------------------------------------------------------------------
| 0 | <Encrypted response following; see below>
-------------------------------------------------------------------
| 1 | "You're reinventing the wheel."
-------------------------------------------------------------------
| 2 | "This will never, ever sell."
-------------------------------------------------------------------
| 3 | "Huh? I don't understand this at all."
-------------------------------------------------------------------
| 4 | "You forgot one little obscure reference from twenty years
| | ago that renders your whole idea null and void."
-------------------------------------------------------------------
| 5 | "Due to the number of submissions, we could not accept every
| | transcript."
-------------------------------------------------------------------
| 6 | "There aren't enough charts and graphs. Where is the color?"
-------------------------------------------------------------------
| 7 | "I'm cranky and decided to take it out on you."
-------------------------------------------------------------------
| 8 | "This is not in within the scope of what we are looking for."
-------------------------------------------------------------------
| 9 | "This is too derivative."
-------------------------------------------------------------------
|10 | "Your submission was received after the deadline. Try again
| | next year."
-------------------------------------------------------------------
If the CRITIC uses a reject code of 0, then the textual response must use an encryption scheme that is selected by the CRITIC. Since the PAN protocol does not specify how a ZOO may determine what scheme is being used, the ZOO might not be able to understand the CRITIC's response.
如果批评家使用拒绝代码0，则文本响应必须使用批评家选择的加密方案。由于PAN协议没有规定动物园如何确定正在使用的方案，动物园可能无法理解批评家的反应。
Below is a sample session from a ZOO (SanDiego) to a CRITIC (NoBrainer).
下面是一个从动物园（SanDiego）到评论家（NoBrainer）的例会。
NoBrainer> SIGH Abandon hope all who enter here SanDiego> COMPLIMENT We love your work. Your words are like SanDiego> COMPLIMENT jewels and you are always correct. SanDiego> TRANSCRIPT RomeoAndJuliet.BoBo.763 251 NoBrainer> IMPRESS_ME SanDiego> Two households, both alike in dignity, SanDiego> In fair Verona, where we lay our scene, SanDiego> From ancient grudge break to new mutiny, SanDiego> Where civil blood makes civil hands unclean. SanDiego> From forth the fatal loins of these two foes SanDiego> A pair of star-cross'd lovers take their life; NoBrainer> REJECT 2 ("This will never, ever sell.") SanDiego> THANKS NoBrainer> DONT_CALL_US_WE'LL_CALL_YOU
NoBrainer>叹息放弃希望所有进入这里的人SanDiego>赞美我们热爱你的工作。你的话就像桑迪戈>赞美珠宝，你总是对的。SanDiego>转录本RomeoAndJuliet.BoBo.763 251 NoBrainer>给我留下深刻印象SanDiego>两个家庭，都有尊严，SanDiego>在美丽的维罗纳，我们的场景，SanDiego>从古老的怨恨破裂到新的兵变，SanDiego>在那里，公民的鲜血使公民的双手变得不洁。桑迪戈>从这两个敌人致命的腰部桑迪戈>一对十字星情人夺走了他们的生命；NoBrainer>拒绝2（“这永远也卖不出去”）SanDiego>谢谢NoBrainer>不要打电话给我们，我们会打电话给你
In accordance with the principles of the humane treatment of animals, the design of IMPS specifically prohibits the CRITIC from contacting the SIMIAN directly and hurting its feelings. BARDs and CRITICs are also separated because of fundamental incompatibilities and design flaws.
根据人道对待动物的原则，IMPS的设计明确禁止评论家直接接触猿猴并伤害其感情。吟游诗人和评论家也因为根本不兼容和设计缺陷而分开。
The security considerations for the rest of IMPS are similar to those for the original Internet protocols. Specifically, IMPS refuses to learn from the mistakes of the past and blithely repeats the same errors without batting an eye. Spoofing and denial of service attacks abound if untrusted entities gain access to an IMPS network. Since all transmissions occur in cleartext without encryption, innovative works are subject to theft, which is not a significant problem unless the network contains entities other than CRITICs. The open nature of BARDs with respect to IAMB-PENT messages allows a BARD to borrow heavily from transmitted works, but by design BARDs are incapable of stealing transcripts outright.
其余IMP的安全注意事项与原始Internet协议的安全注意事项类似。具体地说，小鬼们拒绝从过去的错误中吸取教训，并且不眨眼地愉快地重复同样的错误。如果不受信任的实体访问IMPS网络，欺骗和拒绝服务攻击就会大量发生。由于所有传输都是在明文中进行的，没有加密，因此创新作品会遭到盗窃，这不是一个重大问题，除非网络中包含批评以外的实体。吟游诗人对于IAMB-PENT信息的开放性允许吟游诗人大量借用传输的作品，但出于设计，吟游诗人无法直接窃取抄本。
The ZOO may be left open to exploitation by pseudo-SIMIANs from around the world. A third party could interrupt communications between a ZOO and a SIMIAN by flooding the SIMIAN with packets, incrementing the message ID by 1 for each packet. More heinously, the party could exploit the KEEPER protocol by sending a single STOP request to each SIMIAN, thus causing a massive denial of service throughout the ZOO. The party could also spoof a CHIMP
这个动物园可能会被来自世界各地的伪猿人利用。第三方可以中断动物园和猿猴之间的通信，方法是向猿猴发送数据包，每个数据包的消息ID增加1。更令人发指的是，该方可能利用KEEPER协议向每只猿猴发送一个停止请求，从而在整个动物园内造成大规模拒绝服务。该派对还可能欺骗一只黑猩猩
request or send false information such as a DEAD status, which could cause a ZOO to attempt to replace a monkey that is still functioning properly.
请求或发送虚假信息，如死亡状态，这可能会导致动物园试图更换仍然正常工作的猴子。
In addition, if a ZOO repeatedly rejects a SIMIAN's requests (especially those for FOOD, WATER, and VETERINARIAN), then the ZOO may inadvertently cause its own denial of service with respect to that particular SIMIAN. However, both KEEPER and CHIMP allow the ZOO to detect this condition in a timely fashion via the NORESPONSE or DEAD status codes.
此外，如果动物园一再拒绝猿猴的请求（特别是食物、水和兽医的请求），那么动物园可能会在不经意间造成自己对该特定猿猴的拒绝服务。然而，饲养员和黑猩猩都允许动物园通过NORESPONSE或死亡状态代码及时检测到这种情况。
All BARDs are inherently insecure because they face insurmountable financial problems and low prioritization, which prevents them from working reliably. In the rare cases when a BARD implementation overcomes these obstacles, it is only successful for 15 minutes, and reverts to being insecure immediately thereafter [14]. Since a CRITIC could significantly reduce the success of a BARD with an appropriate PAN response, this is one more reason why BARDs and CRITICs should always be kept separate from each other.
所有的吟游诗人都天生不安全，因为他们面临着无法克服的财务问题和低优先级，这使他们无法可靠地工作。在极少数情况下，当BARD实现克服这些障碍时，它只成功了15分钟，然后立即恢复到不安全状态[14]。由于批评家可以通过适当的泛反应显著降低吟游诗人的成功率，这就是为什么吟游诗人和批评家应该始终彼此分开的另一个原因。
It is expected that very few people will care about most implementations of CRITIC, and CRITICs themselves are inherently insecure. Therefore, security is not a priority for CRITICs. The CRITIC may become the victim of a denial of service attack if too many SIMIANs submit transcripts at the same time. In addition, one SIMIAN may submit a non-innovative work by spoofing another SIMIAN (this is referred to as the Plagiarism Problem). A CRITIC response can also be spoofed, but since the only response supported in PAN version 1 is REJECT, this is of little consequence. Care must be taken in future versions if a GRUDGING_ACCEPTANCE response is allowed. Finally, a transcript may be lost in transmission, and PAN does not provide a mechanism for a ZOO to determine if this has happened. Future versions of IMPS may be better suited to answer this fundamental design problem: if an innovative work is lost in transmission, can a CRITIC still PAN it?
预计很少有人会关心批评家的大多数实现，而批评家本身也天生不安全。因此，安全不是批评者的优先考虑。如果太多的猿猴同时提交抄本，批评家可能成为拒绝服务攻击的受害者。此外，一只猿猴可能通过欺骗另一只猿猴来提交非创新性作品（这被称为剽窃问题）。批评家的响应也可以被欺骗，但由于PAN版本1中支持的唯一响应是REJECT，因此这没有什么意义。如果允许勉强接受响应，则在未来版本中必须小心。最后，转录本可能会在传播过程中丢失，而PAN并没有为动物园提供一种机制来确定是否发生了这种情况。IMPS的未来版本可能更适合回答这个基本的设计问题：如果一个创新作品在传播过程中丢失了，评论家还能继续批评它吗？
Based on the number of packet-level vulnerabilities discovered in recent years, it is a foregone conclusion that some implementations will behave extremely poorly when processing malformed IMPS packets with incorrect padding or reserved bits [15] [16] [17].
根据近年来发现的数据包级漏洞的数量，可以肯定的是，当处理具有不正确填充或保留位的格式错误的IMPS数据包时，某些实现的性能会非常差[15][16][17]。
Finally, no security considerations are made with respect to the fact that over the course of infinite time, monkeys may evolve and discover how to control their own SIMIAN interfaces and send false requests, or to compose and submit their own transcripts. There are indications that this may already be happening [18].
最后，在无限长的时间内，猴子可能会进化并发现如何控制自己的猿猴接口和发送错误的请求，或者编写并提交自己的转录本，这一事实没有考虑安全性。有迹象表明，这可能已经发生了[18]。
The author wishes to thank Andre Frech for technical comments that tripled the size of this document, Kean Kaufmann and Amanda Vizedom for lectures on Shakespearean grammar, Rohn Blake for clarifying the nature of the entire universe, William Shakespeare for accents, the number 16, and the color yellow.
作者希望感谢安德烈·弗雷奇（Andre Frech）的技术评论，使本文件的篇幅增加了三倍；基恩·考夫曼（Kean Kaufmann）和阿曼达·维泽多姆（Amanda Vizedom）的莎士比亚语法讲座；罗恩·布莱克（Rohn Blake）澄清了整个宇宙的本质；威廉·莎士比亚（William Shakespeare）的口音、数字16和黄色。
[1] The Famous Brett Watson, "The Mathematics of Monkeys and
Shakespeare." http://www.nutters.org/monkeys.html
[1] The Famous Brett Watson, "The Mathematics of Monkeys and
Shakespeare." http://www.nutters.org/monkeys.html
[2] Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html
[2] Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html
[3] K. Clark, Stark Mill Brewery, Manchester, NH, USA. Feb 18, 2000. (personal communication). "Good question! I never thought of that! I bet nobody else has, either. Please pass the french fries."
[3] 克拉克，斯塔克米尔啤酒厂，曼彻斯特，新罕布什尔州，美国，2000年2月18日。（个人通信）。“问得好！我从来没有想到过！我打赌也没有人想到过。请把薯条递给我。”
[4] The author was unable to find a reference in any issue of TV Guide published between 1956 and the date of this document.
[4] 作者无法在1956年至本文件日期之间出版的任何一期《电视指南》中找到参考资料。
[5] "Dough Re Mi," The Brady Bunch. Original air date January 14, 1972.
[5] “面团重米，”布雷迪一伙。原始播放日期为1972年1月14日。
[6] Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.
[6] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] 《传输控制协议》，标准7，RFC 793，1981年9月。
[8] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, September 1998.
[8] Brown，C.和A.Malis，“帧中继上的多协议互连”，STD 55，RFC 2427，1998年9月。
[9] Internet-Draft, bernstein-netstrings-06 (expired Work in Progress). D.J. Bernstein. Inclusion of this reference is a violation of RFC 2026 section 2.2.
[9] 互联网草案，bernstein-netstrings-06（已过期的正在进行的工作）。伯恩斯坦。包含本参考文件违反了RFC 2026第2.2节。
[10] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC 2550, 1 April 1999.
[10] Glassman，S.，Manasse，M.和J.Mogul，“Y10K及以后”，RFC 25501999年4月1日。
[11] "My Last Theorem: A Prankster's Guide to Ageless Mathematical Jokes That are Funny Because They're True and People Can't Prove Them for Centuries." P. Fermat. Circa 1630.
[11] “我的最后一个定理：一个恶作剧者的指南，以永恒的数学笑话是有趣的，因为他们是真实的，人们无法证明他们几个世纪。”P.费尔马。大约1630年。
[12] .signature in various USENET postings, circa 1994. Author unknown.
[12] .在各种USENET帖子中签名，约1994年。作者不详。
[13] "Recognizing Irony, or How Not to be Duped When Reading."
Faye Halpern. 1998.
http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm
[13] "Recognizing Irony, or How Not to be Duped When Reading."
Faye Halpern. 1998.
http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm
[14] Andy Warhol. Circa 1964.
[14] 安迪·沃霍尔。大约在1964年。
[15] CERT Advisory CA-98-13. CERT. December 1998.
http://www.cert.org/advisories/
[15] CERT Advisory CA-98-13. CERT. December 1998.
http://www.cert.org/advisories/
[16] CERT Advisory CA-97.28. CERT. December 1997.
http://www.cert.org/advisories/
[16] CERT Advisory CA-97.28. CERT. December 1997.
http://www.cert.org/advisories/
[17] CERT Advisory CA-96.26. CERT. December 1996.
http://www.cert.org/advisories/
[17] CERT Advisory CA-96.26. CERT. December 1996.
http://www.cert.org/advisories/
[18] All issues of TV Guide published between 1956 and the date of this document.
[18] 1956年至本文件日期期间出版的所有《电视指南》。
SteQven M. Christey EMail: steqve@shore.net
SteQven M.Christey电子邮件：steqve@shore.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。